Guia - Fundamentos - ITIL 2011 - Andres PDF

Guía de Fundamentos ITSM basada en ITIL®
Fundamentos de ITSM basados en

ITIL®
Incluye actualización a 2011 Edition
Autor:
Ernesto Vilches
Experto ITIL
Ernesto Vilches ITIL® is a trade mark registered of Cabinet Office 1


Índice
1. Advertencia Legal .................................................................................. 17

2. Gestión de Servicios y su Ciclo de Vida .................................................. 19
2.1. Resumen de la Historia de ITIL® ....................................................................... 19
2.2. ITIL ® y los Modelos de Gestión de TI ................................................................ 21
2.2.1. Otros Fabricantes ........................................................................................................ 23
2.2.2. Otros Sistemas de Gestión ......................................................................................... 24
2.2.3. Gestión de Servicios TI ............................................................................................... 25
2.2.3.1. Los retos de la organización ............................................................................................ 25
2.2.3.2. ¿Cuáles son las Necesidades de los clientes? .................................................................... 25
2.2.3.3. ¿Qué quieren los clientes de los servicios TI? ................................................................... 25
2.2.3.4. Necesitamos el Compromiso de la Dirección .................................................................... 26
2.2.3.5. ¿Por qué falla la implementación? .................................................................................. 26
2.2.3.6. Los Problemas del Soporte ............................................................................................. 27
2.2.3.7. Qué espera el Cliente ..................................................................................................... 28
2.2.3.8. ¿Por qué implementar Gestión de Servicios? ................................................................... 28
2.2.3.9. Gestión de Servicio ........................................................................................................ 28
2.2.4. ITIL ® es un éxito ¿Por qué? ...................................................................................... 29
2.2.4.1. Dominio público ............................................................................................................ 29
2.2.4.2. Mejores prácticas .......................................................................................................... 29
2.2.5. Los Recelos de la Organizaciones para implementar ITIL® ..................................... 29
2.2.6. El mundo ITSM ........................................................................................................... 32
2.3. Breve Historia de ITIL ......................................................................................... 33
2.3.2. Gestión de Relaciones con el Cliente ......................................................................... 35
2.3.3. Las capas tectónicas de la Gestión de Servicios de TI .............................................. 35
2.3.4. ITIL® v2 versus ITIL® v3 ......................................................................................... 36
2.3.4.1. Qué es ITIL® ? ............................................................................................................... 36
2.3.4.2. Estructura de ITIL® ........................................................................................................ 36
2.3.5. The ITIL® Esquema de las Acreditaciones ............................................................ 37
2.4. Gestión de Servicios como Práctica ................................................................... 41
2.4.1. ¿Qué es un Servicio? .................................................................................................. 41
2.4.2. ¿Qué es Gestión de Servicios? .................................................................................. 41
2.5. El Ciclo de Vida del Servicio ............................................................................... 42
2.5.1. ¿Qué es el Ciclo de Vida del Servicio? ....................................................................... 42
2.5.1.1. Consiste en 5 fases que son: ........................................................................................... 42
2.5.2. El Ciclo de Vida de los Servicios basado en la arquitectura de ITIL® ....................... 44
2.5.3. ITIL ® Librería ............................................................................................................. 44
2.5.4. ITIL ® – Los Procesos en el Ciclo de Vida de los Servicios. .................................... 45
2.5.5. ITIL® v3, qué se conserva de la v2 y que se actualiza en 2011 Edition. ................... 46
2.5.6. ITIL ®– Conceptos básicos y definiciones .................................................................. 47
3. Estrategia del Servicio ........................................................................... 50
3.1. Fundamentos de la Estrategia de los Servicios .................................................. 50
3.2. Conceptos Genéricos y Definiciones .................................................................. 52
3.2.1. Valor de un servicio: Utilidad y Garantía ..................................................................... 52
3.3. Estrategia del Servicio en el Ciclo de Vida del Servicio ...................................... 54
3.3.1. Propósito ..................................................................................................................... 54
3.3.2. Misión .......................................................................................................................... 55
3.3.2.1. La Estrategia del Servicio tiene que responder a preguntas como: ..................................... 55
3.3.3. Objetivos ..................................................................................................................... 55
3.4. Conceptos Genéricos y Definiciones .................................................................. 56
3.4.1. Recursos y Capacidades ............................................................................................ 56
3.4.2. Los Activos del Servicio como la base de la creación del valor ................................. 56
3.4.3. Creación de Valor ....................................................................................................... 57
3.4.4. Red de Valor ............................................................................................................... 57
3.4.5. Modelo de Servicios .................................................................................................... 58
3.4.6. Modelo de Kano .......................................................................................................... 59
3.5. Modelos de Organización ................................................................................... 60
3.5.1. Proveedor Externo de servicios .................................................................................. 60
3.5.2. Ciclo de creación de valor ........................................................................................... 60

3.5.3. Otros modelos ............................................................................................................. 60
3.5.4. Tipos de Proveedores de Servicios ............................................................................ 62
3.5.5. Situaciones de externalización ................................................................................... 62
3.5.6. Outsourcing Structures (Roles .................................................................................... 63
3.6. Los Procesos de la Fase de la Estrategia de Servicios ...................................... 64
3.7. Gestión de la Estrategia ..................................................................................... 66
3.7.1. Generación de Estrategias.......................................................................................... 66
3.7.2. Ámbito ......................................................................................................................... 66
3.7.3. Valor ............................................................................................................................ 66
3.7.4. Políticas ....................................................................................................................... 67
3.7.5. Misión .......................................................................................................................... 67
3.7.6. Actividad 1 – Definir el Mercado ................................................................................. 68
3.7.7. Actividad 2 – Desarrollar las Ofertas .......................................................................... 70
3.7.8. Actividad 3 – Desarrollar los Activos Estratégicos ...................................................... 70
3.7.9. Actividad 4 – Prepararse para la implementación ...................................................... 71
3.7.10. Prueba Patrón ............................................................................................................. 73
3.7.11. Entradas Actividad 4 Prepararse para la implementación .......................................... 74
3.7.12. Salidas......................................................................................................................... 74
3.7.13. Relaciones con otros procesos ................................................................................... 74
3.7.14. Disparadores ............................................................................................................... 76
3.7.15. Desafíos ...................................................................................................................... 76
3.7.16. Riesgos ....................................................................................................................... 76
3.7.17. Retorno de la Inversión ............................................................................................... 76
3.7.18. Automatización del Servicio ........................................................................................ 76
3.7.19. Detalles de Paquetes en la estrategia ........................................................................ 77
3.7.20. Paquete de Servicios (SP) .......................................................................................... 77
3.7.21. Cuadro Integral de Mando (Balanced Scorecard) (Kaplan & Norton) ........................ 77
3.7.22. Interlocutores con Proveedores de Servicios (SPI) .................................................... 78
3.7.23. Factores Críticos de Éxito y Análisis competitivo ....................................................... 79
3.7.24. Herramientas para la Estrategia del Servicio.............................................................. 80
3.7.25. Sistema de planificación y monitorización de bucle cerrado para la estrategia. ........ 80
3.7.26. Indicadores Clave (KGI – KPI) .................................................................................... 80
3.8. Gestión Financiera de Servicios de TI ................................................................ 82
3.8.1. Objetivos ..................................................................................................................... 82
3.8.2. Valor para el Negocio .................................................................................................. 82
3.8.3. Valoración del Servicio ................................................................................................ 82
3.8.4. Actividades Principales ............................................................................................... 83
3.8.5. Presupuesto ................................................................................................................ 84
3.8.6. Contabilidad ................................................................................................................ 84
3.8.7. Costes ......................................................................................................................... 84
3.8.8. Los costes pueden ser ................................................................................................ 85
3.8.9. Centros de coste ......................................................................................................... 85
3.8.10. Cobros ......................................................................................................................... 85
3.8.11. Tipos de cobros ........................................................................................................... 85
3.8.12. Relaciones principales con otros Procesos ................................................................ 86
3.8.13. Entradas ...................................................................................................................... 86
3.8.14. Salidas......................................................................................................................... 86
3.8.15. Potencial del servicio: Componente de valor añadido, basado en la percepción de
valor del servicio o en el Utilidad y Garantía esperadas del uso del servicio. ............................ 87
3.8.16. ROI (retorno de la inversión ........................................................................................ 87
3.8.16.1. Caso de Negocio: ........................................................................................................... 87
3.8.16.2. ROI - Pre-Programa: ....................................................................................................... 87
3.8.16.3. ROI - Post-Programa:...................................................................................................... 87
3.8.17. Análisis de Inversiones en Servicios ........................................................................... 88
3.8.18. Análisis de Impacto en el Negocio (BIA) ..................................................................... 88
3.8.19. Optimización de Costes del Servicio .......................................................................... 88
3.8.20. Dinámica de Costes Variables (VCD) ......................................................................... 88
3.8.21. Desafíos ...................................................................................................................... 89
3.8.22. Riesgos ....................................................................................................................... 89
3.8.23. Resumen de Gestión Financiera de los Servicios de TI ............................................. 90
3.9. Gestión de la Demanda (Demand Management) ................................................ 92
3.9.1. Objetivos: .................................................................................................................... 92
3.9.2. Ámbito ......................................................................................................................... 92
3.9.3. Valor ............................................................................................................................ 92

3.9.4. Disparadores ............................................................................................................... 93
3.9.5. Entradas ...................................................................................................................... 93
3.9.6. Salidas......................................................................................................................... 93
3.9.7. Gestión de la Demanda basada en actividades ......................................................... 93
3.9.8. Relaciones con otros Procesos .................................................................................. 94
3.9.9. Modelado de la Demanda ........................................................................................... 95
3.9.10. Rol en Gestión de la Demanda ................................................................................... 95
3.9.11. Desafíos ...................................................................................................................... 95
3.9.12. Riesgos ....................................................................................................................... 95
3.10. Gestión de la Cartera de Servicios (SPM) .......................................................... 96
3.10.1. Gestión del Portafolio de Servicios (SPM) .................................................................. 96
3.10.2. Catálogo de Servicios ................................................................................................. 98
3.10.3. Canal de Entrada ( Service Pipeline ) ......................................................................... 98
3.10.4. Servicios Retirados ..................................................................................................... 98
3.10.5. Objetivos de la Gestión de Cartera ............................................................................. 98
3.10.6. Valor al Negocio .......................................................................................................... 99
3.10.7. Ámbito ......................................................................................................................... 99
3.10.8. Políticas y principios .................................................................................................. 100
3.10.9. Propietario del Proceso ............................................................................................. 100
3.10.10. El desarrollo de una organización ............................................................................. 100
3.10.11. Modelos de fases organizacionales .......................................................................... 101
3.10.12. De grupo de trabajo a departamento ........................................................................ 101
3.10.13. Disparadores ............................................................................................................. 101
3.10.14. Entradas .................................................................................................................... 102
3.10.15. Salidas....................................................................................................................... 102
3.10.16. Desafíos y riesgos ..................................................................................................... 102
3.10.17. Gestión de la Información por el Gestor de la Cartera de Servicios ........................ 102
3.10.18. Relaciones con otros Procesos ................................................................................ 103
3.11. Gestión de Relaciones con el Negocio ............................................................. 104
3.11.1. Propósito ................................................................................................................... 104
3.11.2. Conceptos Básicos ................................................................................................... 104
3.11.3. Ámbito ....................................................................................................................... 104
3.11.4. BRM vs SLM ............................................................................................................. 105
3.11.5. Valor .......................................................................................................................... 105
3.11.6. Políticas y Principios ................................................................................................. 105
3.11.7. Disparadores ............................................................................................................. 106
3.11.8. Entradas .................................................................................................................... 106
3.11.9. Salidas....................................................................................................................... 106
3.11.10. Desafíos .................................................................................................................... 106
3.11.11. Riesgos ..................................................................................................................... 107
3.12. Estrategia del Servicio - Interfaz con otras fases del Ciclo de Vida ................... 108
3.12.1. Edward Deming (PDCA) ........................................................................................... 108
3.12.2. Estrategia del Servicio & Ciclo de Deming ............................................................... 109
3.12.3. Riesgos ..................................................................................................................... 110
4. Diseño del Servicio .............................................................................. 112
4.1. Diseño del Servicio en el Ciclo de Vida ............................................................ 112
4.1.1. Sobre la Definición: ................................................................................................... 112
4.1.2. Objetivos ................................................................................................................... 113
4.1.3. La Clave: ................................................................................................................... 113
4.1.4. Valor para el Negocio ................................................................................................ 114
4.2. Conceptos Genéricos y Definiciones ................................................................ 116
4.2.1. Proveedor de Servicios (SP) ..................................................................................... 116
4.2.2. Suministrador (Supplier). .......................................................................................... 116
4.2.3. Acuerdo de Nivel de Servicio (SLA) .......................................................................... 116
4.2.4. Contrato (Contract) (UC) ........................................................................................... 116
4.2.5. Acuerdo de Nivel Operacional (OLA) ........................................................................ 116
4.2.6. Paquete de Diseño del Servicio - (SDP) ................................................................... 116
4.3. Claves Principales y Modelos ........................................................................... 118
4.3.1. Importancia de las 4 Ps ............................................................................................. 118
4.3.2. Grupos Estratégicos .................................................................................................. 119
4.3.3. Propósito del Diseño del Servicio ............................................................................. 120
4.3.4. Los 5 aspectos importantes del Diseño del Servicio ................................................ 120
4.4. El Diseño de Soluciones del Servicio................................................................ 122

4.4.1. Requisitos del Negocio ............................................................................................. 122
4.4.2. Composición de un Servicio en Dominios ................................................................ 123
4.4.3. Identificando los requerimientos de un Servicio ....................................................... 124
4.4.4. Identificando influencias externos en el Servicio ...................................................... 124
4.5. El diseño de la Cartera de Servicios (Service Portfolio) .................................... 126
4.5.1. Cartera de Servicios-(Service Portfolio) (SPM) ........................................................ 126
4.5.2. Service Portafolio en el SKMS: ................................................................................. 126
4.6. El Diseño de la Arquitectura ............................................................................. 128
4.7. Diseño de los Procesos .................................................................................... 130
4.7.1. Modelo del Proceso: .................................................................................................. 130
4.7.2. El Propietario del Proceso (Process Owner) ............................................................ 131
4.7.3. Medición de las Salidas (Outputs) ............................................................................ 131
4.8. Diseño de las Métricas (KPIs)........................................................................... 132
4.8.1. Mejora Continua del Servicio (CSI): .......................................................................... 132
4.8.2. Marcadores Equilibrados (Kaplan y Norton): ............................................................ 133
4.8.3. Métricas y Medidas ................................................................................................... 133
4.8.4. Opciones de Externalización – Modelos de Entrega ................................................ 134
4.9. Diseño del Servicio – Interfaz con otras fases en el Ciclo de Vida .................... 136
4.9.1. Modelos de Diseño del Servicio y sus limitaciones .................................................. 136
4.9.2. Restricciones del Diseño del Servicio ....................................................................... 137
4.10. Procesos y otras actividades ............................................................................ 138
4.11. Gestor de la Coordinación del Diseño .............................................................. 140
4.11.1. Objetivos ................................................................................................................... 140
4.11.2. Ámbito ....................................................................................................................... 140
4.11.3. Valor .......................................................................................................................... 140
4.11.4. Rol de Coordinación del Diseño ............................................................................... 141
4.12. El Catálogo de Servicios................................................................................... 142
4.12.1. Service Catalogue Management (SCM) ................................................................... 142
4.12.2. Objetivos ................................................................................................................... 142
4.12.3. Ámbito ....................................................................................................................... 142
4.12.4. Valor .......................................................................................................................... 142
4.12.5. Catálogo de Servicios de Negocio y Técnico ........................................................... 143
4.12.6. Entradas .................................................................................................................... 144
4.12.7. Salidas....................................................................................................................... 144
4.12.8. Sugerencias de Métricas (KPIs) ............................................................................... 144
4.12.9. Implementación ......................................................................................................... 144
4.12.10. Factores Críticos de Éxito (CSF) .............................................................................. 144
4.12.11. Propietario, actividades, métodos y técnicas ............................................................ 144
4.12.12. Desafíos .................................................................................................................... 145
4.12.13. Riesgos ..................................................................................................................... 145
4.13. Gestión del Nivel de Servicio (SLM) ................................................................. 146
4.13.1. Meta .......................................................................................................................... 146
4.13.2. Objetivos ................................................................................................................... 146
4.13.3. Ámbito ....................................................................................................................... 146
4.13.5. Actividades, Métodos y Técnicas .............................................................................. 147
4.14. Qué es un Acuerdo de Nivel de Servicio (SLA) ................................................ 152
4.14.1. Posibles Opciones de SLA:....................................................................................... 152
4.15. Contenido indicativo de un SLA ........................................................................ 154
4.16. Acuerdo de Nivel Operacional (OLA) - Ejemplo ................................................ 158
4.16.1. Estructura de soporte de los SLAs ........................................................................... 159
4.17. Plantilla para confeccionar un (OLA) y/o (SLA) ................................................. 160
4.17.1. Resumen de Gestión de Nivel de Servicios.............................................................. 166
4.18. Gestión de la Capacidad .................................................................................. 170
4.18.1. Meta .......................................................................................................................... 170
4.18.2. Objetivos ................................................................................................................... 170
4.18.3. Ámbito ....................................................................................................................... 170
4.18.5. Actividades, métodos y técnicas ............................................................................... 171
4.18.6. Subprocesos ............................................................................................................. 171
4.18.7. Ciclo del Modelado .................................................................................................... 172
4.18.8. Actividades Iterativas ................................................................................................ 172

4.18.9. Dimensionado de Aplicaciones ................................................................................. 172
4.18.10. Modelado................................................................................................................... 173
4.18.11. Entradas al Plan de Capacidad ................................................................................ 173
4.18.12. Actividades de soporte de la Gestión de la Capacidad ............................................ 173
4.18.13. Disparadores ............................................................................................................. 174
4.18.14. Entradas .................................................................................................................... 174
4.18.15. Salidas....................................................................................................................... 174
4.18.16. Métricas KPIs ............................................................................................................ 174
4.18.17. Implementación ......................................................................................................... 174
4.18.18. Factores Críticos de Éxito ......................................................................................... 174
4.18.19. Desafíos y riesgos ..................................................................................................... 175
4.18.20. Relación Principal con otros Procesos ..................................................................... 175
4.18.21. Resumen de Gestión de la Capacidad ..................................................................... 176
4.19. Gestión de la Disponibilidad ............................................................................. 180
4.19.1. Meta .......................................................................................................................... 180
4.19.2. Objetivos ................................................................................................................... 180
4.19.3. Ámbito ....................................................................................................................... 180
4.19.5. Valor para el negocio ................................................................................................ 181
4.19.6. Proceso de Gestión de la Disponibilidad .................................................................. 181
4.19.7. Gráfico de Tiempos Medios ...................................................................................... 182
4.19.8. Tiempos Medios ........................................................................................................ 182
4.19.9. Principios Rectores de la Disponibilidad ................................................................... 182
4.19.10. Análisis de Fallos del Servicio (SFA) ........................................................................ 183
4.19.11. Análisis del Árbol de Fallos ....................................................................................... 183
4.19.12. Disparadores ............................................................................................................. 184
4.19.13. Entradas .................................................................................................................... 184
4.19.14. Salidas....................................................................................................................... 184
4.19.15. Métricas (KPI) ........................................................................................................... 184
4.19.16. Implementación ......................................................................................................... 184
4.19.18. Riesgos ..................................................................................................................... 185
4.19.19. Mala gestión de AM tendremos posibles Problemas ................................................ 185
4.19.21. Resumen de Gestión de la Disponibilidad ................................................................ 186
4.20. Gestión de Continuidad de los Servicios de TI (ITSCM) ................................... 190
4.20.1. Meta .......................................................................................................................... 190
4.20.2. Objetivos ................................................................................................................... 190
4.20.3. Alcance...................................................................................................................... 191
4.20.4. Ámbito ....................................................................................................................... 191
4.20.6. Organización y Planificación ..................................................................................... 191
4.20.8. El proceso consta de cuatro fases ............................................................................ 193
4.20.8.1. Iniciación ................................................................................................................... 193
4.20.8.2. Requisitos y estrategia .............................................................................................. 193
4.20.8.3. Implementación ......................................................................................................... 194
4.20.8.4. Operación continuada ............................................................................................... 194
4.20.9. Pruebas Extensivas .................................................................................................. 194
4.20.10. Gestión de la Información ......................................................................................... 194
4.20.11. Disparadores ............................................................................................................. 194
4.20.12. Relación con otros Procesos .................................................................................... 195
4.20.13. Entradas .................................................................................................................... 195
4.20.14. Salidas....................................................................................................................... 195
4.20.15. Métricas (KPIs) .......................................................................................................... 195
4.20.16. Posibles problemas ................................................................................................... 196
4.20.17. Riesgos ..................................................................................................................... 196
4.20.18. Gestión del riesgo ..................................................................................................... 196
4.20.19. Resumen de Gestión de la Continuidad ................................................................... 197
4.21. Sistema de Gestión de Seguridad de la Información ........................................ 201
4.21.1. Meta .......................................................................................................................... 201
4.21.2. Objetivos ................................................................................................................... 201
4.21.3. Ámbito ....................................................................................................................... 201
4.21.4. Valor .......................................................................................................................... 202

4.21.6. Marco de Trabajo de Seguridad ............................................................................... 202
4.21.7. Directivas de Seguridad para la Información ............................................................ 203
4.21.8. Marco de Gestión de Seguridad ............................................................................... 203
4.21.9. ISO 27000 (Marco para la Gestión de Seguridad) ................................................... 203
4.21.10. Gestión de la Seguridad de TI basada en la ISO 27001 .......................................... 203
4.21.11. Gobierno de Seguridad ............................................................................................. 204
4.21.12. Control del Riesgo ..................................................................................................... 205
4.21.13. Métricas ..................................................................................................................... 205
4.21.14. Entradas .................................................................................................................... 205
4.21.15. Salidas....................................................................................................................... 206
4.21.16. Posibles Problemas .................................................................................................. 206
4.21.17. Éxito .......................................................................................................................... 206
4.21.18. Desafíos .................................................................................................................... 206
4.21.19. Las 10 Leyes Inmutables de la Seguridad ................................................................ 207
4.22. Gestión de Suministradores o Proveedores...................................................... 209
4.22.1. Meta .......................................................................................................................... 209
4.22.2. Objetivos ................................................................................................................... 209
4.22.3. Ámbito ....................................................................................................................... 209
4.22.5. Conceptos Básicos y Definiciones ............................................................................ 210
4.22.6. Actividades ................................................................................................................ 210
4.22.7. Disparadores ............................................................................................................. 211
4.22.8. Entradas .................................................................................................................... 211
4.22.9. Salidas....................................................................................................................... 212
4.22.10. Métricas ..................................................................................................................... 212
4.22.11. Desafíos .................................................................................................................... 212
4.22.13. Éxito .......................................................................................................................... 213
4.22.14. Riesgos ..................................................................................................................... 213
4.22.15. Roles de Gestión de Suministradores ...................................................................... 213
4.22.17. Relaciones complejas ............................................................................................... 214
4.23. Actividades dentro del Diseño del Servicio ....................................................... 215
4.23.1. Desarrollo de Requisitos: .......................................................................................... 215
4.23.2. Investigación de requisitos ........................................................................................ 215
4.23.3. Problemas en el desarrollo de requisitos .................................................................. 216
4.23.4. Documentación de requisitos .................................................................................... 216
4.23.5. Gestión de la Información y de los Datos ................................................................. 216
4.23.6. Clasificación de los datos.......................................................................................... 217
4.23.7. Gestión de Aplicaciones ............................................................................................ 217
4.23.8. Desarrollo Rápido de Aplicaciones (RAD) ................................................................ 217
4.24. Organización – Roles y Responsabilidades ...................................................... 219
4.24.1. RACI (Responsible-Accountable-Consulted-Informed) ............................................ 219
4.24.2. Aptitudes ................................................................................................................... 220
4.24.4. Roles más destacados a incluir en una matriz RACI ................................................ 220
4.25. Métodos, técnicas y herramientas .................................................................... 223
4.25.1. Métricas (KPIs) .......................................................................................................... 223
4.25.2. Desafíos .................................................................................................................... 223
4.25.3. Riesgos ..................................................................................................................... 223
4.26. El Gran Cuadro ................................................................................................ 224
5. Transición del Servicio ......................................................................... 225
5.1. Transición del Servicio en el Ciclo de Vida de los Servicios ............................. 225
5.1.1. Meta .......................................................................................................................... 225
5.1.2. Objetivos ................................................................................................................... 225
5.1.4. Ámbito ....................................................................................................................... 226
5.1.5. Actividades ................................................................................................................ 227
5.1.6. Disparadores ............................................................................................................. 228
5.1.7. Entradas .................................................................................................................... 228
5.1.8. Salidas....................................................................................................................... 228

5.1.9. Métricas ..................................................................................................................... 228
5.1.10. Políticas para la Transición de Servicios en una organización................................. 228
5.1.11. Línea de Referencia (Baseline) (BL) ......................................................................... 229
5.1.12. Criterio de Aceptación del Servicio (SAC) ................................................................ 229
5.2. Procesos y otras Actividades ............................................................................ 231
5.3. Planificación y Soporte de la Transición ........................................................... 233
5.3.1. Ámbito ....................................................................................................................... 233
5.3.2. Disparadores ............................................................................................................. 233
5.3.3. Roles ......................................................................................................................... 234
5.3.4. Desafíos y Factores Críticos de Éxito ....................................................................... 234
5.3.5. Riesgos ..................................................................................................................... 234
5.4. Gestión de Cambios ......................................................................................... 235
5.4.1. Objetivos: .................................................................................................................. 235
5.4.2. Hay dos autoridades en la Gestión de Cambio: ....................................................... 235
5.4.3. Actividades más importantes .................................................................................... 235
5.4.4. Actividades más específicas de Gestión de Cambios .............................................. 235
5.4.6. Políticas ..................................................................................................................... 236
5.4.7. Diseño y planificación ............................................................................................... 236
5.4.8. Conceptos Genéricos y Definiciones ........................................................................ 237
5.4.9. Las 7 Rs de la Gestión de Cambios ......................................................................... 237
5.4.10. Tipos de Cambio ....................................................................................................... 238
5.4.11. Prioridades en los Cambios ...................................................................................... 238
5.4.12. Cambio de Emergencia............................................................................................. 238
5.4.14. Diagrama de Rummler – Brache (Calles de piscina) ................................................ 239
5.4.15. Relación de Gestión de Cambios con la CMDB y CMS ........................................... 240
5.4.16. Gestión de Programas / Proyectos ........................................................................... 240
5.4.17. Interacción de Gestión de Cambios con Configuración, Capacidad y Entregas ...... 241
5.4.18. Modelo de Autorización de Cambios ........................................................................ 241
5.4.19. El Comité de Asesoramientos de Cambios CAB ...................................................... 242
5.4.20. Actividades del CAB .................................................................................................. 242
5.4.21. Agenda del CAB ........................................................................................................ 242
5.4.22. Disparadores del proceso de Gestión de Cambios .................................................. 243
5.4.23. Entradas .................................................................................................................... 243
5.4.24. Salidas....................................................................................................................... 243
5.4.25. Métricas – KPIs ......................................................................................................... 244
5.4.26. Factores Críticos de Éxito. ........................................................................................ 244
5.4.27. Riesgos ..................................................................................................................... 245
5.4.28. Desafíos .................................................................................................................... 245
5.4.29. Beneficios .................................................................................................................. 245
5.4.30. Costes y posibles Problemas .................................................................................... 245
5.4.31. Construcción, pruebas e implementación de los Cambios ....................................... 246
5.4.32. Actividades del Rol del Gestor del Cambio............................................................... 246
5.4.33. Actividades del rol del Comité de Asesoramiento de Cambios ................................ 247
5.4.34. Informes de Gestión .................................................................................................. 247
5.4.35. Mejores Prácticas ...................................................................................................... 247
5.5. Gestión de Entregas y Despliegues .................................................................. 249
5.5.1. Objetivos ................................................................................................................... 249
5.5.3. Conceptos Genéricos y Definiciones ........................................................................ 250
5.5.4. Big Bang vs. Fases ................................................................................................... 250
5.5.5. Automático vs. Manual .............................................................................................. 251
5.5.6. Prueba de las Entregas & Paquetes de Entrega ...................................................... 251
5.5.7. Actividades ................................................................................................................ 251
5.5.8. El Modelo en V de los Servicios ............................................................................... 252
5.5.9. Acrónimos usados en el gráfico del MODELO EN V ................................................ 253
5.5.10. Detalles de las Actividades ...................................................................................... 253
5.5.11. Relaciones entre Gestión de Cambios y Gestión de Entregas ................................. 256
5.5.12. Entradas .................................................................................................................... 256
5.5.13. Salidas....................................................................................................................... 257
5.5.14. Diseño, Construcción y Configuración ...................................................................... 257
5.5.14.1. Entradas:..................................................................................................................... 257
5.5.14.2. Salidas: ....................................................................................................................... 257

5.5.15. Aceptación de la Entrega .......................................................................................... 257
5.5.15.1. Entradas: .................................................................................................................... 257
5.5.15.2. Salidas: ....................................................................................................................... 258
5.5.16. Planificación del paso a Producción ......................................................................... 258
5.5.16.1. Ampliar los planes de entrega con:................................................................................ 258
5.5.17. Cuadro de Difusiones ................................................................................................ 259
5.5.18. Métricas ..................................................................................................................... 259
5.5.21. Riesgos ..................................................................................................................... 260
5.5.22. Roles en la Gestión de Entregas .............................................................................. 260
5.5.22.1. Lógicas: ..................................................................................................................... 261
5.5.22.2. Físicas: ...................................................................................................................... 261
5.5.23. Definitiva Media Library (DML) ................................................................................. 262
5.5.24. Relaciones entre la DML y la CMDB-CMS ............................................................... 262
5.6. Gestión de los Interesados (Interesados Management) .................................... 265
5.7. Service Asset & Configuration Management (SACM) ....................................... 267
5.7.1. Objetivos ................................................................................................................... 267
5.7.2. Ámbito ....................................................................................................................... 267
5.7.4. Definiciones y Conceptos Genéricos ........................................................................ 267
5.7.4.1. CMDB: ....................................................................................................................... 267
5.7.4.2. CMS: 4 capas ............................................................................................................ 267
5.7.5. Actividades ................................................................................................................ 268
5.7.6. Políticas ..................................................................................................................... 269
5.7.7. CIs en la CMDB ........................................................................................................ 269
5.7.7.1. El Modelo Lógico y Único .......................................................................................... 269
5.7.7.2. Categorías de CIs ..................................................................................................... 269
5.7.8. Interrelaciones de CIs por sus atributos ................................................................... 270
5.7.9. Estado de un CI ........................................................................................................ 271
5.7.10. Alcance y Detalles de los CIs.................................................................................... 271
5.7.11. Ejemplos de Atributos en la CMDB ........................................................................... 272
5.7.12. Actividades ................................................................................................................ 273
5.7.12.1. Dirección y Planificación. ........................................................................................... 273
5.7.12.2. Identificación de la configuración ................................................................................ 273
5.7.13. Control de configuración ........................................................................................... 274
5.7.13.1. Seguimiento y reporte del estado de la configuración .............................................. 274
5.7.14. Verificación y auditoria .............................................................................................. 274
5.7.15. Métricas ..................................................................................................................... 274
5.7.18. Riesgos ..................................................................................................................... 275
5.7.20. Roles ......................................................................................................................... 276
5.8. Procesos de Evaluación del Cambio ................................................................ 279
5.8.1. Objetivos ................................................................................................................... 279
5.8.2. Ámbito ....................................................................................................................... 279
5.8.4. Políticas ..................................................................................................................... 280
5.8.5. Actividades ................................................................................................................ 280
5.8.6. Planificación de la evaluación ................................................................................... 280
5.8.6.1. Evaluación del rendimiento previsto. ........................................................................ 280
5.8.6.2. Evaluación del rendimiento real. ............................................................................... 280
5.8.7. Entradas .................................................................................................................... 281
5.8.8. Salidas....................................................................................................................... 281
5.8.9. Métricas ..................................................................................................................... 282
5.8.11. Desafíos .................................................................................................................... 282
5.8.12. Riesgos ..................................................................................................................... 282
5.8.13. Relaciones con otros procesos ................................................................................. 283
5.9. Proceso de Validación y Pruebas del Servicio .................................................. 285
5.9.1. Ámbito ....................................................................................................................... 285

5.9.2. Objetivos ................................................................................................................... 285
5.9.4. El Modelo de Servicio ............................................................................................... 286
5.9.4.1. Políticas ..................................................................................................................... 287
5.9.5. Tipos de Pruebas ...................................................................................................... 287
5.9.6. Actividades ................................................................................................................ 287
5.9.7. Dirección de validación y pruebas ............................................................................ 288
5.9.8. Planificación y diseño ................................................................................................ 288
5.9.9. Verificación del diseño y el plan de pruebas............................................................. 288
5.9.10. Preparación del entorno de pruebas ......................................................................... 288
5.9.11. Realización de pruebas ............................................................................................. 288
5.9.12. Evaluación de criterios de salida e informes............................................................. 288
5.9.13. Limpieza y cierre ....................................................................................................... 288
5.9.14. Interfaces................................................................................................................... 289
5.9.15. Entradas .................................................................................................................... 289
5.9.16. Salidas....................................................................................................................... 289
5.9.17. Métricas (KPIs) .......................................................................................................... 290
5.9.17.1. Desde la perspectiva del cliente: .............................................................................. 290
5.9.17.2. Desde la perspectiva del Proveedor de Servicios. ................................................... 290
5.9.20. Riesgos ..................................................................................................................... 291
5.10. Sistema de Gestión del Conocimiento del Servicio (SKMS) ............................. 293
5.10.1. Objetivos ................................................................................................................... 293
5.10.2. Ámbito ....................................................................................................................... 293
5.10.4. Actividades ................................................................................................................ 294
5.10.5. Disparadores ............................................................................................................. 296
5.10.6. Entradas .................................................................................................................... 296
5.10.7. Salidas....................................................................................................................... 296
5.10.8. Desafíos .................................................................................................................... 296
5.10.9. Riesgos ..................................................................................................................... 297
5.10.10. Métricas ..................................................................................................................... 297
5.10.11. KPIs de la contribución del suministrador de TI........................................................ 297
5.10.12. KPIs relevantes para el cliente ................................................................................. 297
5.10.13. KPIs relevantes para el Proveedor de Servicios....................................................... 297
5.10.14. El sistema de 4 capas de la SKMS ........................................................................... 298
6. Operaciones del Servicio ..................................................................... 299
6.1. Operaciones del Servicio en el Ciclo de Vida de los Servicios .......................... 299
6.1.1. Meta .......................................................................................................................... 299
6.1.2. Objetivos ................................................................................................................... 299
6.1.3. Ámbito ....................................................................................................................... 300
6.1.5. Servicios de TI vs. Componentes de Tecnología ..................................................... 300
6.1.5.1. TI Servicios .................................................................................................................. 300
6.1.5.2. Componentes de la Tecnología ..................................................................................... 300
6.1.6. Principios de Operación del Servicio ........................................................................ 302
6.1.7. Estabilidad vs. Responsabilidad ............................................................................... 302
6.1.8. Calidad vs Coste ....................................................................................................... 303
6.1.9. Reactiva vs Reactiva ................................................................................................. 303
6.1.10. Tecnología y Arquitectura ......................................................................................... 303
6.1.11. Licencias de software ................................................................................................ 304
6.1.12. Roles en Operación del Servicio ............................................................................... 304
6.2. Procesos y actividades ..................................................................................... 305
6.3. Gestión de Eventos .......................................................................................... 306
6.3.1. Definiciones y conceptos Genéricos ......................................................................... 306
6.3.2. Tipos de Eventos ...................................................................................................... 306
6.3.3. Ámbito ....................................................................................................................... 307
6.3.5. Actividades, métodos y técnicas. .............................................................................. 307
6.3.6. Clasificación de Eventos ........................................................................................... 308
6.3.7. Disparadores ............................................................................................................. 309
6.3.8. Entradas .................................................................................................................... 309

6.3.9. Salidas....................................................................................................................... 309
6.3.11. Desafíos .................................................................................................................... 310
6.3.12. Riesgos ..................................................................................................................... 310
6.3.14. Roles de Gestor de Eventos ..................................................................................... 310
6.3.15. Relaciones del Gestor de Eventos en las Fases del Ciclo de Vida de los Servicios 311
6.3.16. Interfaces u otros disparadores ................................................................................ 311
6.3.17. Métricas ..................................................................................................................... 311
6.3.18. Riesgos ..................................................................................................................... 311
6.4. Gestión de Peticiones de Servicio .................................................................... 313
6.4.1. Objetivos ................................................................................................................... 313
6.4.2. Ámbito ....................................................................................................................... 313
6.4.3. Valor .......................................................................................................................... 313
6.4.4. Actividades ................................................................................................................ 314
6.4.6. Entradas .................................................................................................................... 315
6.4.7. Salidas....................................................................................................................... 315
6.4.8. Gestión de la Información en Gestión de Peticiones ................................................ 315
6.4.9. Roles ......................................................................................................................... 315
6.4.10. Interfaces o disparadores.......................................................................................... 316
6.4.11. Métricas o KPIs ......................................................................................................... 316
6.4.12. Relaciones con otros procesos ................................................................................. 316
6.4.15. Desafíos .................................................................................................................... 317
6.4.16. Riesgos ..................................................................................................................... 317
6.4.17. Roles en la Comunicación ........................................................................................ 317
6.5. Gestión de Incidentes ....................................................................................... 319
6.5.1. Propósito ................................................................................................................... 319
6.5.2. Objetivos ................................................................................................................... 319
6.5.3. Definiciones y Conceptos Genéricos ........................................................................ 319
6.5.4. Ámbito ....................................................................................................................... 320
6.5.6. Clasificación de los Incidentes .................................................................................. 320
6.5.7. Actividades ................................................................................................................ 321
6.5.8. Ciclo de Vida del Incidente........................................................................................ 321
6.5.9. Escalado de los Incidentes ....................................................................................... 321
6.5.9.1. Funcional .................................................................................................................... 321
6.5.9.2. Jerárquico ................................................................................................................... 321
6.5.11. Métricas ..................................................................................................................... 322
6.5.13. Desafíos y Riesgos ................................................................................................... 323
6.6. Gestión de Problemas ...................................................................................... 325
6.6.1. Objetivos ................................................................................................................... 325
6.6.2. Ámbito ....................................................................................................................... 325
6.6.3. Valor .......................................................................................................................... 325
6.6.4. Actividades ................................................................................................................ 326
6.6.6. Conceptos básicos .................................................................................................... 326
6.6.7. Métodos y técnicas ................................................................................................... 327
6.6.7.1. Gestión Reactiva (Control del Problema) ....................................................................... 327
6.6.7.2. Gestión reactiva (Control del Error (KE)) ........................................................................ 327
6.6.7.3. Gestión Proactiva de Problemas.................................................................................... 328
6.6.8. Análisis de tendencias .............................................................................................. 328
6.6.9. Relación con Procesos de Incidentes y del Cambio ................................................. 329
6.6.11. Interrelaciones con otros Procesos ........................................................................... 330
6.6.12. Entradas y Salidas con otros Procesos .................................................................... 330
6.6.13. Interfaces o disparadores.......................................................................................... 331
6.6.13.1. Estrategia del Servicio .................................................................................................. 331
6.6.13.2. Diseño del Servicio ....................................................................................................... 331
6.6.13.3. Transición del Servicio .................................................................................................. 331

6.6.13.4. Mejora Continua del Servicio ........................................................................................ 331
6.6.14. Entradas .................................................................................................................... 331
6.6.15. Salidas....................................................................................................................... 331
6.6.16. Mejores prácticas ...................................................................................................... 332
6.6.17. Principio de Pareto .................................................................................................... 332
6.6.18. Desafíos .................................................................................................................... 332
6.6.19. Riesgos ..................................................................................................................... 332
6.6.20. Beneficios .................................................................................................................. 333
6.6.21. Métricas ..................................................................................................................... 333
6.7. Gestión de Accesos.......................................................................................... 335
6.7.1. Objetivos ................................................................................................................... 335
6.7.2. Ámbito ....................................................................................................................... 335
6.7.4. Disparadores ............................................................................................................. 335
6.7.6. Actividades ................................................................................................................ 336
6.7.7. Roles en la Gestión de Accesos ............................................................................... 336
6.7.7.1. Gestión de Accesos ...................................................................................................... 336
6.7.7.2. Centro de Servicio al Usuario ........................................................................................ 336
6.7.8. Métricas ..................................................................................................................... 337
6.7.9. Entradas .................................................................................................................... 337
6.7.10. Salidas....................................................................................................................... 337
6.7.11. Desafíos .................................................................................................................... 337
6.7.12. Riesgos ..................................................................................................................... 337
6.8. Monitorización y Control de Operaciones ......................................................... 339
6.8.2. Actividades ................................................................................................................ 339
6.8.2.1. Monitorización interna: ................................................................................................ 339
6.8.2.2. Monitorización externa: ............................................................................................... 339
6.8.2.3. Sistema de ciclo abierto: .............................................................................................. 339
6.8.2.4. Sistema de ciclo cerrado. .............................................................................................. 339
6.8.3. Herramientas ............................................................................................................. 339
6.8.4. Métricas ..................................................................................................................... 340
6.9. Funciones ......................................................................................................... 341
6.10. Función Gestión Técnica .................................................................................. 343
6.10.1. Actividades ................................................................................................................ 343
6.10.2. Roles en la Gestión Técnica ..................................................................................... 343
6.10.2.1. Gestión de Mainframes ............................................................................................. 343
6.10.2.2. Gestión de Servidores y soporte ............................................................................... 343
6.10.2.3. Gestión de Redes ..................................................................................................... 344
6.10.2.4. Almacenamiento y Archivo........................................................................................ 344
6.10.2.5. Gestión de Bases de Datos ...................................................................................... 344
6.10.2.6. Gestión de Servicio de Directorios ............................................................................ 344
6.10.2.7. Soporte de Puestos de Trabajo ................................................................................ 345
6.10.2.8. Gestión de Middleware ............................................................................................. 345
6.10.2.9. Gestión de Internet .................................................................................................... 345
6.10.3. Actividades operacionales ........................................................................................ 346
6.10.4. Mejora de actividades operacionales ........................................................................ 346
6.10.5. Gestor Técnico .......................................................................................................... 346
6.10.5.1. Juega dos roles ............................................................................................................ 346
6.10.5.2. Objetivos del Gestor Técnico ........................................................................................ 346
6.10.5.3. Actividades más importantes: ....................................................................................... 347
6.11. Gestión de Aplicaciones ................................................................................... 349
6.11.1. Ciclo de vida de Gestión de Aplicaciones ................................................................. 349
6.11.2. Objetivos ................................................................................................................... 349
6.11.3. Rol de los equipos en el Ciclo Vida de Gestión de Aplicaciones.............................. 350
6.11.4. Herramientas CASE .................................................................................................. 350
6.12. Función Gestión de Operaciones de TI ............................................................ 351
6.12.1. Objetivos ................................................................................................................... 351
6.12.2. Ámbito ....................................................................................................................... 351
6.12.3. Actividades ................................................................................................................ 351

6.12.3.1. Control de Operaciones de TI ........................................................................................ 352
6.12.3.2. Gestión de Instalaciones: .............................................................................................. 352
6.12.4. Funciones – Solapamiento en la Organización ........................................................ 352
6.13. Tecnología y Arquitectura ................................................................................. 355
6.13.1. Requerimientos para integrar la Tecnología en la Gestión de Servicios .................. 355
6.13.2. Tecnologías propias o de terceros ............................................................................ 355
6.13.2.1. Auto Ayuda ................................................................................................................ 355
6.13.2.2. Flujos de Trabajo y motores de procesos ................................................................. 355
6.13.2.3. CMS Integrada .......................................................................................................... 355
6.13.2.4. Descubrimiento / Despliegue / Tecnología Licenciada ............................................. 355
6.13.3. Automatización de Servicios ..................................................................................... 356
6.13.4. Desafíos en Operación del Servicio .......................................................................... 356
6.13.5. Factores Críticos de Éxito en Operaciones de Servicio ........................................... 357
6.13.6. Riesgos en Operaciones de Servicio ........................................................................ 357
6.14. Centro de Servicio al Usuario ........................................................................... 359
6.14.2. Objetivos ................................................................................................................... 359
6.14.4. Actividades ................................................................................................................ 360
6.14.5. Puntos a tener en cuenta .......................................................................................... 360
6.14.6. Beneficios .................................................................................................................. 360
6.14.7. Desafíos y Riesgos ................................................................................................... 361
6.14.8. Estructura organizativa ............................................................................................. 361
6.14.9. Tecnologías más usuales ......................................................................................... 361
6.14.10. Tipos de Mesa ........................................................................................................... 362
6.14.11. Centro de Servicio al Usuario Local. ......................................................................... 362
6.14.12. Centro de Servicio al Usuario centralizado. .............................................................. 363
6.14.13. Centro de Servicio al Usuario virtual. ........................................................................ 363
6.14.14. El Centro de Servicio al Usuario virtual .................................................................... 364
6.14.15. Personal del Centro de Servicio al Usuario .............................................................. 364
6.14.16. Consideraciones Finales ........................................................................................... 364
6.14.17. Métricas o KPIs ......................................................................................................... 365
6.14.18. Externalización del Centro de Servicio al usuario .................................................... 365
7. Mejora Continua de los Servicios CSI ................................................... 367
7.1. Continual Service Improvement in the Service Lifecycle ................................... 367
7.1.1. Conceptos genéricos y definiciones ......................................................................... 367
7.1.2. Modelo de Madurez .................................................................................................. 367
7.1.3. Propósito ................................................................................................................... 368
7.1.4. Objetivos ................................................................................................................... 368
7.1.5. Ámbito ....................................................................................................................... 368
7.1.6. Valor .......................................................................................................................... 368
7.1.7. Meta .......................................................................................................................... 369
7.1.8. Actividades de CSI .................................................................................................... 369
7.1.9. El Modelo SMART ..................................................................................................... 370
7.1.10. Los Seis Pasos del Impulso ...................................................................................... 371
7.1.11. CSI y el Ciclo de Vida del Servicio ............................................................................ 371
7.1.12. El cambio organizativo .............................................................................................. 372
7.1.13. Entradas y Salidas de CSI en las fases del Ciclo de Vida ........................................ 373
7.1.14. El Principio de Propiedad .......................................................................................... 374
7.1.15. Registros de CSI ....................................................................................................... 374
7.1.16. La Mejora Continua de los Servicios (CSI) y el Cambio Organizativo ..................... 375
7.1.17. El ciclo Planificar - Hacer – Verificar – Actuar .......................................................... 376
7.1.17.1. Planificar CSI ............................................................................................................... 376
7.1.17.2. Implementar CSI (Hacer) .............................................................................................. 377
7.1.17.3. Monitorizar, medir y evaluar CSI (Verificar) .................................................................... 377
7.1.17.4. Ajustar CSI (Actuar) ...................................................................................................... 377
7.1.18. Políticas de CSI ......................................................................................................... 377
7.1.19. Métricas, KPIs y Factores Críticos de Éxito (CSF) ................................................... 377
7.1.19.1. Ejemplo cualitativo ...................................................................................................... 378
7.1.19.2. Ejemplo cuantitativo: ................................................................................................... 378
7.1.19.3. ¿Cuántos CSF y KPI? ..................................................................................................... 379
7.1.20. KPI (Key Performance Indicator) .............................................................................. 379
7.1.21. Cuadro Integral de Mando (Balanced Scorecard) .................................................... 380

7.1.22. Benchmark ................................................................................................................ 381
7.2. Los Estándares de la industria y Marcos de Trabajo ........................................ 385
7.2.1. ISO 9000 ................................................................................................................... 385
7.2.2. ISO/IEC 20000 .......................................................................................................... 385
7.2.3. ISO/IEC 27001 .......................................................................................................... 386
7.2.4. COBIT TM ................................................................................................................. 387
7.2.5. Microsoft Operational Framework ............................................................................. 388
7.2.6. SIX SIGMA ................................................................................................................ 388
7.2.7. CMMI ......................................................................................................................... 389
7.3. Sabiduría .......................................................................................................... 390
7.4. Gobierno .......................................................................................................... 393
7.4.1. El Gobierno de la Organización a través del Ciclo de Vida del Servicio .................. 393
7.4.2. Establecer la Estrategia, Políticas y Planes.............................................................. 393
7.4.2.1. Evaluar ...................................................................................................................... 393
7.4.2.2. Dirigir ......................................................................................................................... 394
7.4.2.3. Monitorizar................................................................................................................. 394
Based On Cabinet Office ITIL® Material. Reproduced Under License From The Cabinet Office
396
7.4.3. Gobierno y Actividades de Gestión ........................................................................... 396
7.4.4. Marco de Gobierno ................................................................................................... 397
7.4.5. Cuerpos del Gobierno ............................................................................................... 397
7.5. Proceso de mejora de CSI................................................................................ 399
7.6. El Proceso de los 7 Pasos de la Mejora ........................................................... 401
7.6.1. Objetivos de los 7 pasos ........................................................................................... 401
7.6.2. Ámbito ....................................................................................................................... 401
7.6.3. Valor .......................................................................................................................... 402
7.6.5. Procesos, actividades y Métodos ............................................................................. 402
7.6.6. Paso UNO ................................................................................................................. 403
7.6.6.1. Pasos 1 Definir lo que se debería medir ................................................................... 403
A. Paso 1 – Defina qué es lo que Ud. mediría .............................................................. 403
7.6.6.2. Pasos 2 Definir lo que se puede medir ..................................................................... 404
B. Paso 2 – Defina qué puede Ud. medir ...................................................................... 404
7.6.6.3. Paso 3 Procedimientos de monitorización y recolección de datos ........................... 405
7.6.6.4. Paso 4 Actividad de procesamiento de datos ........................................................... 407
D. Paso 4 – Procesando los Datos ................................................................................ 408
E. Paso 5 – Analizando los Datos ................................................................................. 409
F. Paso 6 – Presentando y Uso de la Información ....................................................... 410
G. Paso 7 – Implementando Acciones Correctivas ....................................................... 412
7.6.7. Entradas genéricas para los 7 pasos de mejora de CSI .......................................... 413
7.6.8. Roles de los 7 pasos de mejora de CSI .................................................................... 414
7.6.9. Conexión entre el modelo de 6 pasos del impulso y el proceso de los 7 pasos de
mejora de CSI ............................................................................................................................ 415
7.6.10. Roles de CSI ............................................................................................................. 415
7.6.10.1. Gestor de CSI ........................................................................................................... 415
7.6.10.2. Propietario del Servicio ............................................................................................. 416
7.6.10.3. Propietario del Proceso ............................................................................................. 416
7.6.10.4. Gestor del Conocimiento del Servicio ....................................................................... 416
7.6.10.5. Analista de Informes ................................................................................................. 416
7.6.10.6. Responsable de Comunicación ................................................................................ 416
7.6.11. Análisis de “gaps” ...................................................................................................... 416
7.6.12. Análisis DAFO ........................................................................................................... 416
7.6.13. Factores Críticos de Éxito para CSI .......................................................................... 417
7.6.14. Desafíos para CSI ..................................................................................................... 417
7.6.15. Riesgos para CSI ...................................................................................................... 417
7.7. Gestión de Nivel de Servicio en la Mejora Continua de los Servicios................ 419
7.7.1. Conceptos y Definiciones más comunes en SLM .................................................... 419
7.7.2. Programa de Mejora de Servicio (SIP) ..................................................................... 420
7.7.3. Requerimientos de Nivel de Servicio ........................................................................ 420
7.8. Informes de los Servicio ................................................................................... 421

7.8.2. Resumen las Actividades de la Mejora Continua de los Servicios ........................... 422
7.8.3. Caso de Negocio (Business Case) ........................................................................... 423
7.8.4. Herramientas para Operaciones de TI que ayuden a CSI ........................................ 424
7.8.5. Funcionalidades para Gestión de Eventos ............................................................... 425
7.8.6. Funcionalidades para Gestión de Incidencias .......................................................... 425
7.8.7. Funcionalidades para Gestión de Peticiones............................................................ 426
7.8.8. Funcionalidades para Gestión de Problemas y Cambios ......................................... 426
7.8.9. Funcionalidades para Gestión de Accesos............................................................... 426
7.8.10. Funcionalidades para Gestión de Redes .................................................................. 427
7.8.11. Funcionalidades para SACM .................................................................................... 427
7.8.12. Herramientas para de Gestión del Rendimiento de TI ............................................. 427
7.8.13. Herramientas para Análisis Estadísticos .................................................................. 427
7.8.14. Herramientas para Gestión de la Cartera ................................................................. 428
7.8.15. Herramientas de Gestión Financiera de Servicios de TI .......................................... 428
7.8.16. Inteligencia del Negocio / Información ...................................................................... 428
7.9. Por dónde empezar a implementar CSI ............................................................ 429
7.9.1. Reingeniería de los Procesos ................................................................................... 429
7.9.2. Gestión del Cambio de la organización y de los interesados ................................... 430
7.9.3. Productos del cambio organizativo ........................................................................... 430
7.9.4. Estrategias del cambio organizativo ......................................................................... 431
7.9.5. Estrategias y Plan de comunicación ......................................................................... 431
7.9.6. La Visión se vuelve confusa...................................................................................... 432
8. Glosario por orden alfabético Inglés .................................................... 435
Términos y Definiciones................................................................................................ 435
9. Glosario por orden alfabético Español ................................................. 481
C. Términos y Definiciones ........................................................................................ 481
10. Términos Principales según tipo en ..................................................... 525
11. ITIL® V3 Acronyms v1.0, 30 May 2007................................................. 529
Referencias .................................................................................................................. 533
Lecturas recomendadas ............................................................................................... 535

Advertencia Legal .1
Todos los derechos de esta obra están reservados a Ernesto Vilches Egea
El autor prohíbe cualquier tipo de fijación, transformación, reproducción, reproducción en

Internet, distribución, microfilmación ya sea por venta y/o alquiler y/o préstamo o de
cualquier otra forma de uso y/o comunicación pública de la misma, total o parcialmente,
por cualquier sistema o en cualquier soporte, ya sea por fotocopia, medio mecánico
electrónico como cintas, CDs o DVDs, incluido el tratamiento informático de la misma, en
cualquier lugar del universo.
El almacenamiento o archivo de esta obra en un ordenador diferente al inicial en este acto

de Don Andrés Castellanos está expresamente prohibido, así como cualquier otra forma
de descarga, transmisión o puesta a disposición incluido en sistema streaming.
Según el elemento 270 y siguientes del Código Penal Español, la vulneración de cualquiera
de estos derechos se considerará una actividad criminal.
La protección de esta obra se extiende al universo de acuerdo a las Leyes y Convenios

Internacionales.
Esta obra está destinada exclusivamente para el uso particular de Don Andrés Castellanos
para sus trabajos académicos de este curso de ITIL®2011 , quedando taxativamente
prohibido su uso profesional en empresas, otros centros de formación, incluyendo a sus
empleados, colaboradores y/o alumnos.
Si piensa o tiene alguna duda sobre la legalidad de la autorización de esta obra y/o que ha
llegado hasta Vd. vulnerando lo anterior y la Ley, le agradeceremos que lo comunique a
ernesto11@terra.es y será tratado el asunto de forma absolutamente confidencial.
Los nombres de empresas y productos reales aquí mencionados pueden ser marcas
comerciales de sus respectivos propietarios.
©Ernesto Vilches Egea

Nº de Solicitud M-005939/2010 del Registro Territorial de la Propiedad Intelectual de la
Comunidad de Madrid
ISBN: 978-84-92684-60-1
Actualizado 30 de Enero de 2013


Gestión de Servicios y su Ciclo de Vida .2

2.1. Resumen de la Historia de ITIL®
ITIL v3 > 2011

Rol de la Foco: Integración y alineamiento de TI y
Función TI Gestión de
el Negocio
Servicios
Gestión de Servicios para el Negocio y la
Tecnología
Gobierno de la Estrategia y Cartera de
Servicios
Partner Mejora Continua
Estratégico Gestión de
Servicios ITIL v2
de TI
Foco: Calidad y eficiencia de los Procesos de TI
TI es un Proveedor de Servicios
Proveedor de TI está separado del negocio
Servicios Gestión de TI depende del presupuesto para su control
Infraestructura
de TI ITIL
Proveedor de Foco: Estabilidad y control de la infraestructura
Technología TI son técnicos expertos
TI se preocupa de minimizar las interrupciones del
negocio
Cada uno de los dos volúmenes de ITIL® V2 describen los 10 procesos en

Servicios Operacionales y Servicios Tácticos y una Función.
Service Delivery – Tactical
 Gestión de Nivel de Servicio

 Gestión de Capacidad
 Gestión de Disponibilidad
 Gestión de Continuidad de los Servicios
 Gestión Financiera de TI
Service Support – Operational
 Gestión del Incidente

 Gestión del Problema
 Gestión del Cambio
 Gestión de la Entrega
 Gestión de la Configuración

La última versión de ITIL® se centra en el establecimiento de la Gestión de
Servicios a través del Ciclo de Vida de los Servicios. ITIL® 2011 y habiéndose
actualizado en Diciembre 2011
A partir de Julio de 2012 desaparecen los números de versión de ITIL® tal como
v2, v3 y 2011, denominándose únicamente ITIL®


2.2. ITIL ® y los Modelos de Gestión de TI

ITIL® is a registered trademark of Cabinet Office (UK)
De todos es conocida la importancia que tiene la Gestión de Servicios TI hoy en día. Mientras que
hasta los años 70 la mayor preocupación estaba en la mejora y desarrollo de nuevo hardware, y
hasta bien entrados los 80, este interés era por el desarrollo del software, la última década del
pasado siglo se ha centrado en la Gestión de los Servicios.
Durante décadas la Gestión de Servicios se ha visto como una continuación o extensión al desarrollo,
pero en los últimos años se está cambiando esta situación, ya que, como corroboran estudios de
consultoría, entre 70% y 80% de los gastos en el Ciclo de Vida de los sistemas de información son en
la fase de Operación. Esto se puede ver reforzada con situaciones en las que el 60% del tiempo de
los desarrolladores es dedicado a tareas de mantenimiento, o que las actividades diarias de la
plantilla de TI parecen centrase en tareas de gestión.
A la vista de esta situación, nos debemos preguntar lo que entendemos por Gestión de Servicios de
TI. Algunas definiciones que podemos dar a este concepto serían:
“El arte de gestionar el sector TIC 1 completo de una organización, su infraestructura y sus
actividades así como un conjunto coherente de procesos dirigidos a la provisión de servicios a la
organización”, del World Class TI Service Management Guide 2000
“ITSM es un conjunto de procesos que cooperan para asegurar la calidad de servicios conectados y
vivos, de acuerdo a los niveles de servicios acordados con el cliente, sobrepuestos a los dominios de
gestión como la gestión de Sistemas, la gestión de Redes y el desarrollo de Sistemas y a otros mucho
dominios de procesos como la Gestión de los Cambios, la Gestión de Activos y la Gestión de
Problemas”.
De otra manera, la “Gestión de Servicios TI (ITSM) es la alineación sistemática a la planificación,

desarrollo, entrega, y soporte de los servicios TI para la empresa. Une el espacio entre la comunidad
dedicada al Negocio y el departamento de TI a través de la facilitación de la comunicación y la
creación de una asociación de y para el Negocio”.
Esta nueva actividad está cada día más madura, y prueba de esta madurez es la cantidad de marcos
de trabajo teóricos que surgen cada día. En la relativa corta historia de la actividad de la Gestión de
Servicio TI, una guía se ha convertido en el estándar de facto de vario países: ITIL® v2, ITIL® v3 y en
adelante ITIL 2011. A partir de Julio 2012 solo se menciona ITIL®, sin nombrar la versión.
Para comprobar la dimensión que está tomando la Gestión de Servicios en las empresas basta con
ver la cantidad de conferencias, estudios y publicaciones que alrededor de este tema están
surgiendo en los últimos años.
Las grandes organizaciones y los principales proveedores están invirtiendo mucho dinero en
desarrollar sus propios marcos de referencia para la Gestión de Servicios TI.
Muchas de estas aproximaciones que están surgiendo están muy relacionadas con las mejores
prácticas definidas por ITIL® y profundizan en este tema. Cada marco de trabajo tiene sus propias
ventajas dependiendo de la situación en la que se aplique, pero todo ellos están diseñados para
adoptar una alineación orientada a procesos, dejando atrás los tiempos de la orientación a
funciones y organizaciones.

Normalmente todos estos modelos de Gestión de Servicios toman ITIL® como base para realizar un
desarrollo que expanda el modelo, acaparando procesos que no llegan a estar descritos en ITIL®
.Esto nos hace ver que es necesaria la ampliación de las mejores prácticas de ITIL® para alcanzar un
modelo de gestión razonable. Esto está reconocido dentro del propio mundo de ITIL® , que ha
acogido el PD0005, el Código de Prácticas para la Gestión de Servicio TI del Instituto de Estándares
Británico (BSI), y que está completamente basado en ITIL® .
Principales modelos de gestión de TI que han sido desarrollados en los últimos tiempos; pero no
únicos y que se reseñan a modo de ejemplo:
ASL (Application Service Library)

Ofrece un modelo de referencia para la gestión de aplicaciones.
BDM (TI-enabled Business Development and Management Methodology)
Un método para la gestión, el desarrollo, el mantenimiento y el uso de las infraestructuras de la
información.
BiOOlogic
Un modelo de Gestión de Servicios TI para el desarrollo y la mejora de las organizaciones de gestión
de Sistemas TI, basado en la orientación a objetos.
CobiT (Control objectives for information and related Technology)
La implementación de los procesos de gestión TI de ISACA para la Auditoría de sistema de
información.
eTOM (enhanced Telecom Operations Map)
Sirve como anteproyecto para la dirección de procesos y como punto inicial para el desarrollo e
integración de sistemas de soporte a los negocios y a las operaciones (BSS y OSS).
HP TI Service Management Reference Model
Es la visión de Hewlett Packard para organizar la gestión TI basado en ITIL®.
IMM (TI Management Model)
Es el modelo para el establecimiento de la gestión de Sistema TI a todos los niveles de Turnkiek3.
IPW (Introducing Process-oriented Working Methods)
Es el modelo de procesos de Quint Wellington Redwood y KPN Telecom, en el que la mayoría de los
procesos fundamentales de ITIL® están incluidos.
ISM (Integrated Service Management)
Como proveer un conjunto de servicios separados, de un mismo proveedor, como un servicio
integrado, manteniendo los principios generales de la Gestión de Servicios TI.
ISPL (Information Services Procurement Library)
Ofrece un nuevo estándar europeo independiente para la gestión de TI.
3
Turnkiek es una empresa holandesa de consultoría
MSP (Managerial Step-by-Step Plan)

Es la alineación a la gestión TI tal y como se enseña en la Universidad de Tecnología de Delft
ITIL ®(TI Infrastructure Library)
Es el modelo reconocido como estándar de facto para la organización de los procesos de gestión de
los sistemas TI a nivel mundial.
MIP (Managing the Information Provision)
Explica como los requerimientos de información de los procesos de Negocio pueden ser trasladados
a la provisión de servicios TI.
MOF (Microsoft Operations Framework)
Es el modelo de referencia para la gestión de operaciones desarrollado por Microsoft, basado
completamente en los fundamentos de ITIL® .
ITPM (TI Process Model)
Es la alineación basada en modelos que utiliza IBM en todo el mundo.
R2C (Regulation, Control and Continuity)
La metodología de gestión de TI de Roccade.
RPM (Recursive Process Management)
Modelo especialmente útil para las fusiones, grandes reorganizaciones o como vehículo para un
cambio de cultura.
SIMA (Standard Integrated Management Approach)
La alineación creada y usada por InterProm para el diseño de la gestión y seguridad de
infraestructuras TI abierta y multi-vendedor.
2.2.1. Otros Fabricantes

2.2.2. Otros Sistemas de Gestión

2.2.3. Gestión de Servicios TI

Uno de los asuntos más grandes en una organización es que los Roles y Responsabilidades no están
claramente definidos. Muchos empleados asumen muchos roles distintos, tal vez demasiados.
El personal de TI tiene que tratar muchos temas distintos como Incidencias, Problemas, Cambios y
no pueden gestionar esto de la manera correcta. Los directores de cuentas tienen mucho que hacer
para sus clientes, que quieren esto y aquello, y sus exigencias cambian cada día. Los directores de TI
tienen que llevar una enorme variedad de tareas. Es, por lo tanto, necesario que organizaciones de
TI ayuden a clarificar en todo esto.
Las mejores prácticas de Gestión de Servicios nos da la información para hacer precisamente esto.
2.2.3.1. Los retos de la organización

Debemos asumir que las organizaciones son cada día más dependientes de TI para satisfacer sus
objetivos corporativos y para poder cumplir sus necesidades de negocios. A menudo, los
departamentos de TI no consideran los objetivos de la empresa como los suyos propios, sino que se
considera así mismo como tan solo un proveedor. Creemos que TI deber ser visto como una parte
integral de la empresa, estrechamente integrado con los objetivos de la empresa. TI debe contribuir
al Negocio primario, debe ser un socio de empresa y crear esa relación de negocios tan importante.
Lejos quedan los días en los que TI se podía librar con tan sólo la entrega de productos. Como en
cualquier otra industria, los clientes quieren mucho más: ellos quieren servicio; quieren entrega de
servicio no de productos. Los clientes compran SATISFACCIÓN, no solo productos y servicios. Esto es
un reto para la organización de TI porque hasta ahora sólo tenían que entregar productos, nada
más. Además de esto, TI tiene que entregar un servicio constante, fiable y estable, que agregue valor
al negocio.
Tiene que estar disponible 24 x 7, máxime que en estos tiempos el e_negocio es el servicio más
importante que requerimos.
Esto y la dependencia creciente llevan a necesidades crecientes para servicios de TI de calidad,

calidad que esté en consonancia con las necesidades del Negocio y requisitos del usuario a medida
que estos surgen. Es cierto, al margen del tipo o tamaño de la organización, sea Administración
Central, Comunidad Autónoma, Administración local, organización multinacional, una oficina
descentralizada con o sin una provisión de TI local o centralizada, un proveedor de servicio
externo, o un entorno de una sola persona que proporciona soporte de TI.
2.2.3.2. ¿Cuáles son las Necesidades de los clientes?

Antes de entrar cualquier Negocio en la producción de un nuevo producto o servicio, se debe llevar
a cabo una investigación de mercado para averiguar qué quieren en realidad los clientes y qué
comprarán
2.2.3.3. ¿Qué quieren los clientes de los servicios TI?
Quieren Especificación:
Quieren saber, por adelantado, qué van a recibir. El problema con la entrega de servicio de
TI es que los clientes a menudo saben qué quieren, los expertos de TI deberían traducir sus
necesidades de empresa en soluciones. Los clientes no compran productos; compran
servicios o mejor soluciones de Negocio.
Quieren Conformidad a la especificación:

Una vez hallada la solución TI apropiada entonces deben definirse las especificaciones técnicas. Los
clientes quieren saber cuándo lo podrán recibir y deberán estar satisfechos con que se cumplirá su
requisito de Negocio.

Quieren Consistencia:
Ellos quieren que sea igual cada vez que demanden más servicios.
Quieren Valor por su dinero:

El precio que pagan debe ser justo por el producto o servicio que reciben.
Quieren Comunicación:
Quieren que se les diga lo que reciben, cuándo, cómo y qué hacer con ello.
2.2.3.4. Necesitamos el Compromiso de la Dirección

Habitualmente el compromiso de la dirección suele ser con la motivación y el liderazgo. Si los
directivos no respaldan amplia y demostrablemente el uso de las mejores prácticas, o si no se está
completamente comprometido con el cambio y la innovación, no se puede esperar que la plantilla
mejore por si sola los procesos de Gestión de Servicios o el servicio a los clientes. El auténtico
compromiso de la dirección es completamente necesario para ‘estar en el camino’ cuando se
implementa la Gestión de Servicios en una organización.
Lo que se necesita saber primero es el beneficio de utilizar un marco o guías y como comercializar el
mensaje de estos beneficios a la organización. Estos asuntos pueden ser parte de una “propuesta de
negocio” para la mejora o implementación de los procesos. Una importante parte de las “propuestas
de negocio” es probablemente relativa a la articulación de los problemas con la posición actual y la
demostración de los beneficios de la nueva visión.
Una “propuesta de negocio” debería fijarse en los beneficios, desventajas, costes y riesgos de la
situación actual y la futura situación para que la dirección pueda sopesar todos estos factores
cuando decidan si el proyecto se ejecutara o no. Las organizaciones modernas requieren la
alineación entre el Negocio y TI, y además una total alineación a la calidad es requerida desde la
dirección. Los diferentes aspectos de gestión del compromiso pueden ser encontrados en los
Modelos de Calidad Total utilizados (TQM).
2.2.3.5. ¿Por qué falla la implementación?

Si estamos examinando las causas de los fallos al nivel más alto encontraremos un patrón. El diseño
e implementación de procesos nuevos o actualizados no asegura el éxito. Existen un número de
factores que pueden hacer que el resultado no alcance los objetivos.
En la mayoría de los casos el fallo es debido a la pérdida de atención sobre los procesos
habilitadores. No es suficiente para la dirección el dar los fundamentos para los procesos de
implementación y sentarse de espaldas esperando a que todo funcione. La dirección debe estar
comprometida durante el ciclo completo (“Plan-Do-Check-Act.”) y debería dirigir también todos los
aspectos del marco de Gestión de Servicios.

También influye en los fallos:
Carencia de compromiso y entendimiento de la plantilla

Carencia de formación
Los empleados con la responsabilidad de la implementación no son dotados con la
autoridad suficiente para la toma de decisiones.
Cese laboral de la persona a cargo de la implementación de la Gestión de Servicios.
Pérdida del ímpetu desde del primer anuncio.
Pérdida de la financiación inicial y de los beneficios cuantificables a largo plazo.
Demasiada concentración en la parte táctica, se buscan soluciones tácticas en lugar de
estratégicas. Por ejemplo, llevar a cabo elementos individuales de la Gestión de Servicios en
lugar de toda la situación.
Demasiadas Expectativas en los beneficios inmediatos o en intentar hacerlo de una sola vez.
Planificación de la implementación poco realista.
Dificultades para cambiar la cultura de la organización.
Las herramientas son incapaces de respaldar el proceso, necesitando ajustar a la medida el
proceso y la herramienta.
Ámbito de los procesos inadecuado.
Carencia de apreciación del trabajo y disciplina necesarios para implementar la Gestión de
Servicios.
2.2.3.6. Los Problemas del Soporte
Hay muy pocos SLAs (Acuerdo de Nivel de Servicio) que consiguen su supuesto objetivo de mejorar
la calidad de servicio. Eso si de verdad existen SLAs. Una gran causa de esta no mejora de la calidad
es porque no tenemos una información de gestión disponible, las decisiones se toman basadas en lo
que “creo” en vez de en lo que “sé”. Medir la gestión de servicio que conlleva a una mejora es muy
difícil si no se puede identificar la línea de referencia (baseline). Esto puede hacer muy difícil
justificar un Programa de Mejora de Servicios (SIP). Si realmente algo vale lo que cuesta no se
puede juzgar sin un buen entendimiento de los costes (incluidos los costes de los cambios). Un
entendimiento de costes de servicio también proporciona una base sólida para el desarrollo de TI.
En muchas organizaciones de TI no existe un mecanismo de Soporte al Cliente estructurado. Puede

que exista Service Desk y algún tipo de apoyo de líneas de segundo o tercer nivel, pero todas
aquellas organizaciones están intentando resolver las mismas incidencias solas. No hay
comunicación ni cooperación que resulta en el hecho de que las incidencias no se resuelvan con la
suficiente rapidez y que nos enfrentemos a una calidad inconsistente de respuesta a las llamadas y
de tiempo de respuesta inapropiados.
Esta es una de las razones por las que aquellas organizaciones tienen un bajo nivel de percepción /
confianza por parte de sus clientes y esos clientes empiezan a resolver sus propios asuntos que
resulta en un nivel de “peer support” (soporte de su propio grupo). Los costes son difíciles de
calcular, especialmente los de oportunidades, pero pueden ser altos, afectando al Negocio.
La mayoría de organizaciones son dirigidas por acciones reactivas e interrupciones. Los recursos de
soporte están infra gestionados y están continuamente en conflicto, resolviendo incidencias y
problemas repetidamente en lugar de eliminarlos definitivamente.

Cambios no coordinados y sin registrar ocurren cada día. Este mal control del cambio cuesta mucho
dinero y agota recursos porque debemos hacer las cosas una y otra vez. Una falta de Gestión de
Cambios puede tener efectos negativos mayores en otros procesos porque no controlamos nuestro
entorno. Por ello, también nos incapacita para poder manejar los cambios en nuestro Negocio.
En el de tema de Personal, también tenemos que hablar.
En primer lugar, sobre dependemos de empleados clave porque no documentamos los

conocimientos que tienen en su cabeza, no gestionamos el conocimiento.
En segundo lugar, en muchos empleados encontramos una falta de enfoque de los temas por los
que nos encontramos aquí. Por último, los recursos de personal y los requisitos de coste
relacionados son la mayor parte del tiempo muy poco claros. A menudo, no sabemos lo que hacen
muchas personas ni por qué están aquí. ¡A veces no lo saben ni ellos mismos!
2.2.3.7. Qué espera el Cliente

El nuevo entorno de empresa de TI ahora es más complicado debido a:
La Adopción del paradigma del cliente - servidor- proporcionando flexibilidad de
aplicación y facilidad de manejo para los clientes.
Aplicaciones adaptadas a Internet- entornos realmente integradores de Negocio y TI,
pero aumentando la demanda de recursos de TI y requisitos de seguridad.
Intentos esporádicos de re-inventar TI para servir mejor las necesidades del servicio al
cliente
Islas de herramientas de “lo mejor de su clase”, la mayoría de las cuales han sido
soluciones “punta” . . . pero en su día.
Mientras algunos o todos estos esfuerzos pueden haber sido intentados por varias organizaciones TI,
las corporaciones de hoy se dan cuenta que es la combinación de “procesos + personas + productos
+ partners (asociados)” (Las 4 Ps) lo necesario para poder entregar servicios de calidad a sus clientes.
2.2.3.8. ¿Por qué implementar Gestión de Servicios?

Habiendo reconocido que los departamentos de TI están ahora en el Negocio de proveer servicios,
deben adoptar una manera completamente nueva de pensar y comprender los mismos conceptos
de Negocio que aquellos utilizados por todos los Proveedores de Servicios. Hay mucho camino por
recorrer para alcanzar a los demás. Llevamos casi 20 años sin conocer ITIL®
El enfoque de Gestión de Servicio para ITIL® es esa nueva manera de pensar. Pero, no debe
implementarse porque ahora mismo esté de moda. Si no se entiende por qué se está
implementando ITIL® , éste no tendrá éxito. El motor del éxito debe ser el deseo de hacer entrega
de valor añadido al Negocio y valor real al cliente.
2.2.3.9. Gestión de Servicio

Gestión de Servicio es un enfoque orientado a entregar servicios de TI al cliente en su negocio que
alcancen los objetivos de coste y realización que se marcan en asociación con clientes y englobados
en los Acuerdos de Nivel de Servicio (SLAs) y Acuerdos de Nivel Operacional (OLAs).
Gestión de Servicio (ITSM) trata de la entrega y apoyo de los servicios de TI que cumplen los
requisitos de Negocio de la organización. (ITSM) se basa en implementar procesos, preferiblemente
con la orientación de una guía como ITIL® que proporciona un conjunto comprensivo, consistente y
coherente de prácticas idóneas para los procesos de (ITSM), promocionando un enfoque de calidad
a alcanzar efectividad y eficiencia en el uso de los sistemas informáticos. Los procesos de ITIL®
tienen la intención de ser implementados para que apoyen; pero no pueden dictar los procesos de
Negocio de una organización. Eso corresponde a cada organización.

2.2.4. ITIL ® es un éxito ¿Por qué?

ITIL ®se ha convertido en el estándar de facto a nivel mundial para la Gestión de Servicios TI, siendo
utilizado como núcleo para el propio desarrollo de las grandes compañías de Gestión de Servicios.
Las razones para este éxito se deben a las características de ITIL®, que son:
2.2.4.1. Dominio público

Desde sus comienzos ITIL® ha estado disponible a todo el universo público. Esto es que cualquier
organización puede utilizar este marco que se describió hace años por la CCTA en sus publicaciones.
Por este motivo ITIL® ha sido utilizado por una gran variedad de organizaciones, tanto el gobierno
central como autoridades locales, energía como finanzas, comercio o fabricación. Desde
organizaciones muy grandes hasta organizaciones muy pequeñas, pasando por todos los tipos han
implementado ITIL®.
2.2.4.2. Mejores prácticas
ITIL® documenta las mejores prácticas de la industria. ITIL® ha probado su valor desde sus inicios.
En su día, CCTA recopiló información sobre cómo varias organizaciones llevaban la Gestión de
Servicios, la analizó y filtró aquellos puntos que podrían ser útiles para la CCTA y para el gobierno
central del Reino Unido. Otras organizaciones encontraron que estas guías eran aplicables de
manera general y la industria del servicio creó con rapidez mercados fuera del gobierno.
Siendo un marco de trabajo, ITIL® describe el perfil de las organizaciones de Gestión de Servicios.
Los modelos muestran los objetivos, las actividades generales, y las Entradas y/o inversiones y
Salidas y/o resultados de los varios procesos que pueden incorporarse dentro de las organizaciones
TI.
ITIL® no pretende obligar sobre cada una de las acciones que deben hacerse a diario, dado que
difieren mucho de una organización a otra. En su lugar se centra en las mejores prácticas que
pueden ser utilizas de distintos modos de acuerdo a la necesidad de cada organización.
Gracias a este marco de mejores prácticas comprobadas, ITIL® puede ser usado dentro de
organizaciones con métodos y actividades de gestión de servicio ya existentes. El uso de ITIL® no
implica una manera completamente nueva de pensar y actuar, provee un marco de trabajo en el
cual ubicar los métodos y actividades existentes en un contexto estructurado. Resaltando la
importancia de las relaciones entre los procesos, cualquier deficiencia de comunicación y
cooperación entre varias funciones TI puede ser eliminada o minimizada.
2.2.5. Los Recelos de la Organizaciones para implementar ITIL®

I. Recelos al Cambio
ITIL ®exige que los CIO comuniquen constantemente los objetivos y progresos a la plantilla y a los
gerentes, se trata de un poco a poco cada día y no un todo al final del último día. Se trata de una
profunda transformación en los procesos de gestión que debe ser estrechamente seguida y
controlada. La cuestión es que el recelo al cambio es algo común a todos los aspectos de la vida,
incluidos los entornos laborales, pero los expertos aseguran que si se dejan vencer por el temor que
ITIL® provocará, sin duda en muchos de los miembros de las plantillas TI, estos departamentos,
perderán la oportunidad de conseguir un mayor reconocimiento y de aumentar la relevancia de sus
esfuerzos. Cierto que ITIL® representa un gran cambio, pero a menudo termina dignificando a los
departamentos de TI.

Para evitar estos temores, que en realidad tienen su origen en el instintivo miedo a lo desconocido,
se pueden aplicar diversas estrategias, como designar Gestores de Procesos dentro de la plantilla.
De cualquier modo, los directores de TI deben contar con que muchos de los miembros de sus
equipos intentarán evitar el gran cambio cultural que supone ITIL® pero no tirar la toalla al primer
inconveniente.
II. Recelos porque nos van a medir
Uno de los objetivos buscados por el Gobierno Corporativo mediante la implementación interna de
ITIL® es aumentar la eficiencia de las TI, que después deberá probarse. Y para probar la mejora de
las eficiencias, resulta imprescindible que los departamentos de TI midan la eficiencia de los
procesos antes y después de ITIL®. Es decir necesitamos métricas.
ITIL® focaliza en la necesidad de medir e informar a la Gerencia sobre la calidad de los servicios. He
aquí la raíz de otro de los recelos que dificultan la implementación de ITIL®. Los departamentos de TI
temen verse sometidos a una evaluación constante.
Sin embargo de ella también se derivan importantes ventajas. Ser capaz de medir e informar sobre
la calidad de servicio es una buena manera de probar a los usuarios finales que los servicios de TI
están cumpliendo sus expectativas, aunque siempre existirá algún usuario descontento que
considere que todo es un desastre (normalmente el menos profesional). Por otra parte, si los
servicios mejoran, la demostración de la mejora mediante indicadores (KPIs) evidenciará ante la
compañía que el departamento de TI merece ser recompensado por sus esfuerzos y su eficiencia.
Si la cuantificación es acordada por ambas partes, el Negocio entenderá mejor el valor que el
departamento de TI aporta y es más seguro que esté dispuesto a proporcionarle los recursos
financieros que vaya necesitando en el crecimiento.
III. Recelos a que vayamos a reducir la eficiencia del Proceso
A muchos lo que les preocupa es la posibilidad de que unos procesos excesivamente rígidos puedan
llegar a lastrar a los departamentos de TI hasta el punto de llevarlos al extremo opuesto al
perseguido, reduciendo su efectividad y eficiencia
Pero ITIL® ofrece un alto grado de flexibilidad en los procesos y está basada en un marco que incluye
un amplio abanico de alternativas, y éstas pueden combinarse permitiendo a los clientes encontrar
aquello que mejor se adapta a su entorno TI.
IV. Recelos a su utilidad
ITIL® se ha convertido en una palabra de moda dentro de la industria y hace que algunos directores
de TI desconfíen de su utilidad real, desconfianza agravada por el hecho de tratarse de un conjunto
de procesos y no de un producto tangible como el software. Respecto al primer punto, los expertos
advierten que los departamentos de TI no deben lanzarse a ITIL® porque sí, antes hay que realizar un
análisis crítico de dónde estamos ahora y dónde queremos llegar.
El nivel de interés del mercado en general por ITIL® está creciendo, pero esto no significa que sea la
solución perfecta para todas las organizaciones. No resolverá algo que no necesita solución,
simplemente porque sea un concepto de moda. ITIL® encajará o no en cada entorno organizativo
según sus problemas y necesidades específicas.

V. Recelos a no conseguir el ROI y estemos perdiendo dinero
El tiempo, los recursos humanos y los costes requeridos para la implementación de un proceso
constituyen otro de los recelos que actúan como inhibidores de la adopción de ITIL® en muchas
organizaciones. Para muchos, la inversión parece demasiada en comparación con la recompensa,
porque no ofrece una gratificación instantánea.
Se entiende que ITIL® exige una inversión inicial en formación, pero lo cierto es que una vez esa
inversión ha sido realizada, el beneficio a medio y largo plazo la supera con creces en términos de
ahorros de costes y mejora de servicios
VI. Recelos a elegir el Proceso que no es el adecuado
Dado que ITIL® predica sus preceptos estructurándolos en más de 26 “Procesos” diferentes y
muchas “Funciones y Actividades”, los analistas aseguran haberse encontrado con la situación de
que muchos departamentos de TI quedan casi paralizados por el miedo a elegir o implementar el
proceso o el conjunto de procesos equivocados. Las preocupaciones varían desde el derroche de
tiempo y dinero invertido que tal error acarrearía hasta el temor a despilfarrar recursos en un
proyecto que quizá, finalmente, nunca llegue a despegar.
Asimismo, aseguran que cuando de seleccionar un proceso se trata, para tener éxito, los directores
de TI simplemente deben relacionar de manera clara y directa sus elecciones con objetivos de
Negocio. Las organizaciones sólo tienen que priorizar su mayor área de necesidad, sus mayores
problemas de Negocio que ITIL® puede resolver, y empezar por ellos. Y nada más.
VII. Recelos a la complejidad de tantos Procesos.
ITIL ® incluye alrededor de un 50% más de información y de materiales que otros Modelos de
Gestión. El recelo a la complejidad existente en torno a los procesos definidos en lTIL tiene sus raíces
en una reacción instintiva ya tratada: el temor a cambiar. En este sentido, ITIL® proporciona más
información, pero ello no significa que toda deba ser necesariamente utilizada o aplicada, ITIL®
admite implementaciones parciales y/o progresivas.
A muchos profesionales parece preocuparles de manera especial el proceso relacionado con la

Continua Mejora de los Servicios, algo que, por definición, no tiene fin y el hecho de que ITIL® exija
la participación de demasiadas personas por la multiplicidad de roles recogidos en el modelo. Sin
embargo, los roles definidos en ITIL® son algo positivo, porque resultan en una mayor
comunicación, colaboración y consistencia.
VIII. Recelos a no satisfacer las expectativas de la Gobernanza.
Los directores de TI no sólo tienen que convencer a los ejecutivos del área de Negocio de la
conveniencia de realizar una inversión inicial para lanzar un proyecto ITIL® , sino que tendrán que
arreglárselas continuamente para no defraudar sus expectativas. Así, muchos temen que sus
esfuerzos de ITIL® finalmente no consigan satisfacer las expectativas que los altos ejecutivos de sus
empresas se hayan creado al respecto.
Con relación a este punto, ITIL® no representa de ninguna manera un comodín para resolver
cualquier problema en el ámbito TI, y los Directores del Negocio deben tomar conciencia de ello. Por
tanto, las expectativas de estos ejecutivos deben ser controladas de manera proactiva por los
directores de TI.

IX. Recelos sobre el dimensionamiento de la organización
Algunos departamentos TI ni siquiera se plantean la posibilidad de adoptar ITIL® debido a su

tamaño, creyendo que los marcos de mejores prácticas sólo son aplicables a compañías mundiales o
grandes organismos gubernamentales. Pero esto no es necesariamente así, dado que ITIL®
constituye un marco flexible capaz de adaptarse por completo a entornos de cualquier dimensión.
X. Recelos sobre el encorsetado de los Procesos
El décimo y último recelo identificado como importante barrera para la acogida de ITIL® en las
empresas está directamente relacionado con la tendencia de los profesionales de TI a pensar que
este marco cargado de procesos obstaculizará su creatividad a la hora de administrar la tecnología.
Lo cierto es precisamente todo lo contrario.
Una vez las organizaciones TI tengan “su propia casa organizada” podrán ir con facilidad más allá de
enfoques reactivos basados en la mera resolución de los problemas y requerimientos según vayan
surgiendo para asumir actitudes creativas y proactivas. Cuando existen procesos eficientes existe
también la base para la creatividad.
2.2.6. El mundo ITSM
El mundo ITSM
Implantación
de procesos Continuidad
SERVICIOS BS 25999
TIPA ITIL
Calidad en
ISO 20000
productos y
SOFTWARE ISO-15504-8
Servicios
CMMI COBIT SEGURIDAD TI
ISO-15504-5 MOF
LEAN TI
ISO-12207
IT ISO 27000 Gestión de
ISO-29110
Métrica 3 GOVERNANCE Riesgos
Mejora y CobIT
evaluación de ISO-38500 MAGERIT
CALIDAD Val IT PROYECTOS
Procesos COBIT
ISO-15504 ISO-9000 PMI
CMMI-SVC SIX SIGMA GESTIÓN DE
PROCESOS DE
Prince2 Arquitectura
NEGOCIOS empresarial
BPM TOGAF
ZACHMAN

2.3. Breve Historia de ITIL

1983: IBM publica la primera edición de ISMA con el libro “A Management System for the
Information Business”
1986: La CCTA (Central Computer and Telecomunications Agency) impulsa un programa para el
desarrollo común de un conjunto de directrices operacionales con el objetivo de incrementar la
eficiencia en el Gobierno de TI.
1988: El “Government Infrastructure Management Method (GITMM)” es formalizado como las

directrices para las operaciones del Gobierno de TI en el Reino Unido haciendo foco en la Gestión de
Nivel de Servicio. En este mismo año, el equipo de desarrollo fue incrementado y su trabajo
continuó en su estudio del Coste, Capacidad y Disponibilidad
1989: Se llega a la conclusión que GITMM era inadecuado. El GITMM no era un método, por lo que
se decidió quitar la última M de la sigla, así como debería perder la G en base a establecer un
alcance más allá del ámbito de la Administración Pública. Se eliminan las siglas de ITM, y se
establece el acrónimo ITIL.
En este mismo año, ve la luz la primera publicación de ITIL, cuyo contenido abarcaba la Gestión de
Nivel de Servicio, así cómo se ocupó del Help Desk (incorporando los primeros conceptos de la
Gestión de Incidencias), Plan de Capacidad y Gestión del Cambio (libro de 70 páginas).
1990: Se publican los libros de Gestión de Problemas, Gestión de la Configuración y la Gestión del
Coste para los Servicios de TI.
1991: Se publica la parte concerniente a la distribución y control de Software (libro de 90 páginas).

También en esta fecha se creó el ITIMF (TI Infrastructure Management Fórum).
1992: Se publica la Gestión de la Disponibilidad (libro de 69 páginas).
1997: Se hace un estudio más profundo del libro de Gestión de Nivel de Servicio para hacer frente a
las demandas de los clientes (libro de106 páginas). El ITIMF se convierte a lo que hoy conocemos por
ITSMF (Fórum de la Gestión de Servicios de TI).
1999: Se publica el libro de Gestión de la Seguridad manteniendo el foco en la protección de la

Infraestructura basada en los requerimientos y la negociación de los niveles de servicios acordados.
2000: Se publica el TI Service Support v2 (libro de 306 páginas). Se publicó la primera edición de la
Norma BS 15000 basada en el código de prácticas para la Gestión de Servicio TI.
2001: Se publica el TI Service Delivery v2 (libro de 376 páginas). La CCTA pasa la custodia de ITIL al
Office of Government Commerce (OGC).
2002: Se publican tres nuevos libros: Gestión de Aplicaciones (158 páginas), Plan para la
Implementación de la Gestión de Servicios de TI (208 páginas) y Gestión de la Infraestructura (283
páginas).
2003: Se publica la Gestión de Activos de Software (146 páginas)
2004: Se publica el libro de la Perspectiva de Negocio (180 páginas). Se empieza los primeros
trabajos para la ITIL v3.

2005: La Organización de Internacional de Estandarización (ISO) adapta la BS 15000 a una nueva

norma internacional ISO: ISO/IEC 20000.
2007: Se publican cinco libros que representan el núcleo de ITIL v3 (Estrategia de Servicio, Diseño de
Servicio, Transición de Servicio, Operación de Servicio y Mejora Continua de Servicio.
2010: La OGC, custodio de ITIL, delega la propiedad y registro de la marca ITIL a la Oficina del
Gabinete del reino Unido
2011: Se revisan los 5 libros y se reescriben algunos procesos. Aparecen los procesos de Gestión de
la Estrategia, Gestión de Relaciones con el Cliente, Gestión de Coordinación del Diseño y Los 7 Pasos
de la Mejora Continua. El proceso Evaluación pasa a llamarse Evaluación del Cambio. Fecha de
actualización definitiva diciembre 2011
2012: Para Julio 2012 desaparecen los números de versión de ITIL v2, v3 y 2011. Solo se hará
referencia a ITIL
2.3.1. Quien es quien en ITIL

OGC (The Office of Government Commerce) por sus siglas en inglés, es la Oficina independiente del
Tesoro en el Reino Unido. El objetivo de la OGC fue definir estándares y proporcionar las mejores
prácticas para la Gestión de Servicios de TI en el Reino Unido y es su propietario, si bien es de libre
circulación.
APM Group es el Acreditador Oficial de la OGC y es el propietario del esquema de certificación de

ITIL. Este grupo define los estándares de los exámenes, los formadores certificados, los materiales
de los cursos, los syllabus y los proveedores de formación en ITIL. Es el propietario del esquema de
certificación de ITIL
itSMF
El Information Technology Service Management Forum (itSMF) es un grupo de usuarios

Internacionalmente reconocido, dedicado a la Gestión de Servicios TI. Es propiedad de sus miembros
y con independencia total de fabricantes con objeto de mantener la integridad de su filosofía de
trabajo. El itSMF goza de un gran prestigio y contribuye a la Industria para las Mejores Práctica y a
los Estándares a nivel mundial.
El primer capítulo del itSMF se fundó en el Reino Unido en 1991. El itSMF holandés fue el siguiente,
establecido en Noviembre de 1993. Ahora existen filiales en casi todos los países de los cinco
continentes, que cooperan con itSMF Internacional.
EXIN y ISEB
“Examination Institute for Information Science” (EXIN) (Fundación holandesa) y la inglesa

“Information Systems Examination Board” (ISEB) cooperaron en su momento de manera conjunta
un sistema de certificación profesional para ITIL. Este sistema de certificación fue realizado en
estrecha cooperación entre la OGC, itSMF, EXIN e ISEB. Son organizaciones sin ánimo de lucro que
cooperan para ofrecer una amplia gama de certificaciones.

Cabinet Office
En junio de 2010 el Ministro de la Oficina del Gabinete anunció la reorganización de algunas

actividades del Gobierno. La Oficina de Comercio Gubernamental (OGC), que es el custodio de la
cartera de Mejores Prácticas de Gestión de Servicios, ha pasado de ser una oficina del Tesoro de Su
Majestad a formar parte de la Oficina del Gabinete y las funciones de OGC se han trasladado a la
Oficina del Gabinete. La Oficina del Gabinete es un departamento separado del Gobierno del Reino
Unido responsable de apoyar el Primer Ministro y el Gabinete del Reino Unido.
Es el propietario de la Marca ITIL y sus logos ITIL es una marca registrada de Cabinet Office.
2.3.2. Gestión de Relaciones con el Cliente
Organización cliente Organización TI
Gestión Relaciones Políticas

Políticas Con Clientes TI
Estrategia
Gestión
Del
Alineamiento
Negocio Gestión TI
Extratégico
Táctica Titulares del Gestión Nivel

Presupuesto Niveles de de Servicio
Servicio
Operacional Petición de Gestión Cambios

Cambio Gestión Incidentes
Gestores de Departamento Service Desk
Gestores de Proyecto Gestión Problemas
Soporte Gestión de Entrega
Usuarios
DEMANDAR PROVEER
Based on Cabinet Office ITIL® material. Reproduced under licence from the Cabinet Office
2.3.3. Las capas tectónicas de la Gestión de Servicios de TI
SERVICIOS DE SOPORTE DE TI
SERVICIOS DE
ENTREGA DE TI
GESTIÓN DE INFRAESTRUCTURA DE TI
PERSPECTIVA GESTIÓN DE
DEL NEGOCIO APLICACIONES

2.3.4. ITIL® v2 versus ITIL® v3
2.3.4.1. Qué es ITIL® ?

Las siglas de ITIL® se corresponden a “Information Technology Infrastructure Library”, que
podíamos traducir como la Biblioteca de la Infraestructura de las Tecnologías de la Información.
A pesar de no poder considerar a ITIL® como el modelo de referencia perfecto para la Gestión de
Servicios TI, sí podemos decir que es el modelo de facto en estos momentos a nivel mundial y que ha
sido adoptado como base de gestión por grandes compañías.
2.3.4.2. Estructura de ITIL®

Inicialmente ITIL® era un conjunto de 40 libros, que en la versión ITIL v2 publicada en el año 2000
se agruparon en 9 publicaciones. Cada una de estas publicaciones describe un conjunto principal de
procesos de Gestión de Servicios TI. Las dos publicaciones centrales son la de Soporte del Servicio y
la de Entrega del Servicio.
La última versión de ITIL® v3 de 2007 consiste en una estructura sobre la base de 5 publicaciones
que substituyen la versión previa del de ITIL® v2 (publicado en 2000). Las publicaciones básicas
proporcionan la dirección necesaria para un acercamiento integrado según los requisitos de la
especificación estándar de ISO/IEC 20000.
A partir de 2012 desaparecen los nombres de las versiones de ITIL para llamarse solo ITIL.
Estrategia de Servicio
Diseño de Servicio
Transición de Servicio
Operación de Servicio
Mejora Continua de Servicio
ITIL ® is a registered trademark of the Cabinet Office. Copyright The Crown.

2.3.5. The ITIL® Esquema de las Acreditaciones


Plan
e
? Bu
ild
nag /ev
M a olv
e


2.4. Gestión de Servicios como Práctica

2.4.1. ¿Qué es un Servicio?
Un Servicio es un conjunto de recursos que son provistos a los clientes para soportarlos en
la operación de una o más áreas del Negocio.
Un Servicio es percibido como algo único y completo.
Un Servicio siempre proporciona resultados a los interesados.
Un Servicio soluciona problemas.
Un Servicio debe ser fiable, consistente, de alta calidad y de coste aceptable.
Un Servicio tiene que añadir valor al Negocio.
NOTA: Por lo general, los servicios facilitan resultados realzando el funcionamiento y reduciendo
los picos de trabajo de última hora
2.4.2. ¿Qué es Gestión de Servicios?

Gestión de Servicios es un conjunto de Capacidades o habilidades organizativas que
añaden valor a los activos del cliente en forma de Servicios sin que este tenga que asumir
riesgos ni costes inesperados.
Estas capacidades toman la forma de Procesos y Funciones para gestionar un Servicio a
través de un Ciclo de Vida.
Un Servicio es un medio de entregar valor a un cliente sin que éste tenga que exponer
costes o riesgos.
Valor es el núcleo del concepto del Servicio y se compone de Utilidad y Garantía.
NOTA: La transformación de recursos en servicios de valor es la base de la Gestión de

Servicios.

2.5. El Ciclo de Vida del Servicio

2.5.1. ¿Qué es el Ciclo de Vida del Servicio?
ITIL ® enfoca la Gestión de Servicios desde el Ciclo de Vida de un Servicio. El Ciclo de Vida de un
Servicio es un modelo de organización con una visión en:
 Todas las fases del Ciclo de Vida están relacionadas con el valor de los servicios de TI
 La forma en que la Gestión de Servicios es estructurada.
 La forma en que varios componentes están enlazados unos con otros.
 El impacto que un cambio puede tener en un componente, en otro componente del sistema
o en el sistema entero.
2.5.1.1. Consiste en 5 fases que son:

Estrategia del Servicio
Diseño del Servicio
Transición del Servicio
Operación del Servicio
Mejora Continua del Servicio
ITIL® se focaliza en el Ciclo de Vida del Servicio a partir de la gestión de un servicio

desde la solicitud del mismo hasta su entrega y retiro
ITILv3 se focaliza en el Ciclo de Vida del Servicio a partir de la gestión de

un servicio desde la solicitud del mismo hasta su entrega
Requerimientos Negocio / Clientes
Estrategia Objetivos y Políticas Los Objetivos y

Recursos y grandes las Políticas
Cartera de Servicios & Catálogo de
del Servicio forman parte de

Contratos
la Estrategia del
Estándares Servicio
Diseño Arquitecturas
del Servicio Diseño de soluciones
SDP
Servicios
Prueba de soluciones
Transición Plan de Transición
del servicio SKMS
Operación Servicios
del servicio operacionales
Planes y
Mejora Continua acciones
del Servicio de mejora

Esto es una definición algo limitada, por lo que hemos de examinar el Ciclo de Vida del Servicio más
de cerca. Para ser efectivo y eficiente, el alineamiento del ciclo vital requiere la especialización,
coordinación y control entre los procesos y las funciones dentro y a través de los elementos del ciclo
de vida.
El Ciclo de Vida de los Servicios debe:
Proveer la estructura, la estabilidad y la fuerza a las capacidades de los gestores de

servicios de TI con principios, métodos y herramientas potentes.
Servir para proteger las inversiones y proporcionar la base necesaria para poder medir,
aprender y mejorar.
La estrategia empresarial la dicta la estrategia del Negocio.
Se ayuda de la estrategia del Negocio, por las soluciones del Diseño del Servicio.
Se prueban las soluciones del servicio diseñado para permitir ser puesta en Transición y desplegada
y con soporte al Negocio.
Mientras que están en funcionamiento, en las Operaciones de Servicio, estos se han de mantener y
se les da soporte, para asegurar su funcionamiento de acuerdo a los requisitos convenidos.
Para asegurar la competitividad, la eficiencia y la efectividad, El Ciclo de Mejora Continua tiene que
ser adoptado.
La Estrategia del Servicio y la Mejora Continua de los Servicios afectan siempre a todas las demás
fases
La estrategia es el núcleo de la acción en el Ciclo de Vida de los Servicios, y cada fase proporciona los
puntos para la retroalimentación y el control (El Gobierno)
ITIL ® hace foco en la mejora continua de la calidad de los servicios.

2.5.2. El Ciclo de Vida de los Servicios basado en la arquitectura

de ITIL®
Los procesos describen cómo las cosas cambian mientras que la estructura describe cómo están
conectadas.
La estructura determina un comportamiento y debe ser un marco de organización diseñado para el
funcionamiento sostenible.
El Ciclo de Vida es un acercamiento comprensivo para que en la Gestión de Servicios:
Se entienda su estructura
Las interconexiones entre todos sus componentes
Cómo los cambios afectarán el sistema y sus componentes
El "problema” de hoy es creado a menudo por la solución de ayer
Confiado
Problema Acción de Resultado

percibido Remedio
Entregado
Based on Cabinet Office ITIL® material. Reproduced under license from the Cabinet Office
2.5.3. ITIL ® Librería

El Ciclo de Vida de los Servicios se explica en una librería de 5 volúmenes en los que
con todo detalle se pormenoriza en los Servicios, Procesos y Funciones
Estrategia del Servicio: Busca conseguir el alineamiento entre el negocio y TI. Pretende entender y
trasladar las necesidades del negocio a las estrategias de TI. Transforma la Gestión del Servicio en un
activo estratégico.
Diseño del Servicio: Una guía en la producción y mantenimiento del diseño de arquitecturas y
políticas de TI sobre el desarrollo de servicios incluyendo insourcing y outsourcing y asegurando los
requerimientos actuales y futuros del negocio.
Transición del Servicio: Después de definida la Estrategia del Servicio y documentado el Diseño del
Servicio, se deben poner éstos en producción y se centra en la gestión de cambios de servicios
nuevos o modificados antes de la fase de Operaciones.
Operación del Servicio: Enfatiza en la mejora efectiva y eficiente para entregar y soportar los
servicios en orden a asegurar valor a los Clientes y Proveedores de Servicios, según lo acordado.
Mejora Continua del Servicio: Hace foco en las entradas y salidas necesarias para el adecuado ciclo
de mejora continua sobre los servicios existentes para mantener o mejorar su valor.

2.5.4. ITIL ® – Los Procesos en el Ciclo de Vida de los

Servicios.
Los Procesos en la versión 3 de ITIL® se muestran en la figura de más abajo y su mapeo con la
tradicional vista en la versión 2.
Las columnas representan los las actividades que se realizan dentro de cada uno de las cinco etapas
del Ciclo de Vida del Servicio y las filas representan los procesos.
Algunos procesos son trasversales y existen en diferentes etapas del Ciclo de Vida del Servicio y
pueden ser múltiples y otros caben dentro de una sola etapa del Ciclo de Vida del Servicio. Como se
puede apreciar es el camino para que una organización pueda ser certificada en la ISO/IEC 20000
Los colores que se muestran en cada proceso se hacen coincidir con el color del libro o volumen de
ITIL®, pero solo como referencia, sin que exista otro propósito, y para facilitar su ubicación.
Procesos en el Ciclo de Vida
Diapositiva 39
Ernesto Vilches ITIL® is a registered trade mark of the Cabinet Office ernesto11@terra.es

2.5.5. ITIL® v3, qué se conserva de la v2 y que se actualiza en 2011

Edition.
Función Gestión
Operaciones TI
MEJORA CONTINUA DE LOS SERVICIOS Función Gestión
de Aplicaciones Los 7 Pasos de
Gestión del Gestión del la Mejora
De ITIL ® v2 Catálogo Función
Conocimiento
Gestión Técnica
FUNCIÓN v2 Coordinador del
Diseño Evaluación del
Cambio Peticiones de
En ITIL ® v3 Gestión de Servicio
Suministradores Validación y
FUNCIONES v3 Pruebas del Gestión de
Gestión de la Servicio Eventos
Gestión de la Seguridad de la
Estrategia Información Planificación y
Soporte de la Gestión de
Gestión de la Gestión de la Transición Accesos
Demanda Continuidad
Gestión de Gestión de
Gestión de la Gestión de la Lanzamientos Problemas
Cartera de Servicios Disponibilidad
Gestión de Relaciones Gestión de la
Cambios Incidencias
con el Negocio Capacidad
Gestión Financiera Gestión Nivel Gestión de Función Centro de

de TI de Servicio Configuración Servicio al Usuario
Estrategia del Diseño del Transición del Operación del

Servicio Servicio Servicio Servicio
Los Procesos que se conservan de ITIL v2 se han resaltado con fondo verde oscuro
La Función que se conserva de ITILv2 se ha resaltado con fondo azul claro
Los Procesos que se incorporan en 2007 con la versión ITILv3 se han resaltado con fondo verde claro
La Funciones que se incorporan en la versión ITIL v3 se han resaltado con fondo azul oscuro
En Agosto 2011 se incorporan los procesos siguientes:
Gestión de la Estrategia y Gestión de Relaciones con el Negocio en la fase de Estrategia del Servicio
Gestión de Coordinación del Diseño en la fase de Diseño del Servicio
Los 7 pasos de la mejora en la fase de Mejora Continua de los Servicios
El proceso llamado Evaluación, en la fase de la Transición, pasa a llamarse Evaluación del Cambio
A partir de Julio 2012 desaparecen los números de versiones de ITIL®. Solo hay un ITIL®

2.5.6. ITIL ®– Conceptos básicos y definiciones

Un PROCESO es una o varias actividades diseñadas para obtener un objetivo definido. Hay dos tipos
de actividades, la operacional y la de control o medida. (QUÉ)
Un PROCEDIMIENTO es una específica forma de llevar a cabo una actividad (CÓMO y QUIÉN)
Una INSTRUCCIÓN DE TRABAJO define como una o varias actividades en un procedimiento son
llevadas a cabo usando tecnología u otros recursos (EL QUÉ).
CONFIABLE es que hace lo que tiene que hacer.
EFECTIVIDAD DE UN PROCESO es el grado de aproximación al objetivo requerido.
TAREA es una instrucción de trabajo a realizar en un tiempo definido (ACCIONES)
ROL es un conjunto de responsabilidades, actividades y autoridades que se dan a una persona o
grupo. (QUÉ)
Un DEPARTAMENTO es una parte de la estructura jerárquica de un negocio y es responsable de la
actividad de un grupo de empleados.
CULTURA EMPRESARIAL es la forma en que las personas se comportan con las demás, la forma en
que las decisiones son hechas y actitud de los empleados con sus compañeros, jefes, clientes y
proveedores.
EL PROCESO NO ES un método de estructuración de una organización
EL PROCESO proporciona sus resultados primarios a los Clientes e Interesados
EL PROCESO siempre responde a un específico evento
EL PROCESO será EFICAZ si su resultado se ajusta a los estándares definidos
El PROCESO será EFICIENTE si las actividades del Proceso también se desarrollan con el mínimo
esfuerzo y con los costes solo necesarios
En el PROCESO se definen: Roles, Actividades, Líneas maestras y Estándares
El PROPIETARIO (Process Owner) del Proceso es el responsable de los resultados del mismo. Ayuda
a Design Service para que cada dueño de un proceso se asegure de que los procesos utilicen
términos y plantillas estándares
El GESTOR (Process Manager) del Proceso es responsable de realizar los procesos e informar sobre
ellos al PROPIETARIO del Proceso
El OPERADOR del Proceso es responsable de las actividades y tareas específicas e informa al
GESTOR DEL PROCESO.
La UTILIDAD (Lo que hace) de un servicio se comunica por los resultados o eliminación de riesgos y
costes La adecuación para un fin y es lo que el cliente recibe.
La GARANTÍA (Lo bien que lo hace) de un servicio es la adecuación a un uso, es la forma en que se
entrega y la más aproximación a la disminución de las pérdidas para el cliente durante la entrega del
mismo.
Propietario del Servicio: Actúa como punto central de contacto para un servicio concreto,
independientemente de donde residan las funciones, procesos o componentes tecnológicos
subyacentes.
Titular y representante del servicio, actuando como principal punto de contacto para el cliente sobre
todos los asuntos relacionados y entiende todos los componentes que forman el servicio.
Asegura que el servicio cumple los requerimientos del cliente.
Identifica oportunidades de mejora del servicio, tratándolo con el cliente y realiza la evaluación de
los RFCs.

Actúa de enlace con los propietarios de los procesos a través del Ciclo de Vida de la Gestión del
Servicio
Mantiene los datos de los servicios en el Catálogo de Servicios
Participación en la negociación de SLAs y OLAs.
Gestor del Servicio: Coordina el desarrollo, producción y evaluación de uno o más productos o
servicios. Es responsable de:
Efectuar las estrategias y alcanzar los objetivos de la empresa
Realizar comparaciones de análisis gaps.
Gestión económica
Gestión de clientes
Gestión de distribuidores
Gestión de todo el Ciclo de Vida
Gestión del inventario
Propietario del Proceso: Se encarga de garantizar que la organización siga un proceso.
Desempeña el rol esencial del proceso como representante, líder de su diseño, interlocutor,
formador y principal defensor.
Recursos: Recursos son entradas directas para producción tal como: Tecnología, Capital,
Aplicaciones, Infraestructura, Gente, Información, etc. que son usados para transformar los
recursos. Los recursos son más fáciles de adquirir que las capacidades.
Capacidades: Las capacidades por sí misma no producen valor sin los adecuados recursos y se
desarrollan a través de los años. Las capacidades coordinan y controlan los recursos.
Las redes de valor: Es un sistema de relaciones que genera valor, tangible o intangible, mediante
intercambios complejos y dinámicos entre dos o más organizaciones.
Activos del servicio: Los recursos y las capacidades son los activos del servicio de un Proveedor de
Servicios. Las organizaciones los utilizan para crear valor en forma de bienes y servicios.
Gestión de la Cartera de Servicios (Service Portfolio Management)
Es un método dinámico de destreza para gobernar las inversiones en Gestión de Servicios a lo largo
de la vida de la empresa para obtener valor y representa las oportunidades y disposición de un
proveedor de servicio a los clientes y el mercado.
Gobierno: Las actuales organizaciones de TI interno deben transformarse en efectivos y eficientes
Proveedores de Servicios de TI o dejarán de ser relevantes para la empresa y poco después dejarán
de existir. Este incesante y continuo impulso hacia un mayor valor de negocio con mayor eficiencia
interna está en el Gobierno.
Gobierno Corporativo: Considera el panorama en su conjunto y se proporciona una forma,
transparente, justa y responsable de gestionar una organización.
Gobierno de Negocio: Da como valor buenos resultados para la empresa.
Gobierno Empresarial: La combinación del Gobierno Corporativo y de Negocio
Gobierno de TI: Parte integrante de la gobierno empresarial y consiste en el liderazgo, las
estructuras organizativas y procesos que aseguren que la organización de TI soporta y extiende en la
organización sus estrategias y objetivos.
El Caso de Negocio (Business Case de Kaplan):
Es un documento empleado para evaluar o analizar el impacto financiero y/o económico de una
propuesta generada en una empresa y documentar los aspectos más relevantes considerados al
momento de hacer el análisis.
Se trata de una metodología que nos permite analizar desde el punto de vista financiero y
operacional una propuesta o alternativa, midiendo el impacto que ésta tendrá en la empresa.
Respondería a: ¿Si invierto aquí lo puedo recuperar y cuándo?

Modelo de Servicios: Sirven para que los procesos y las funciones de Gestión del Servicio se
comuniquen y colaboren en la creación de valor. Los Modelos del Servicio describen cómo los
activos del servicio obran recíprocamente con los activos del cliente y crean el valor para una lista
dada de contratos en el Portfolio
Paquete del Diseño del Servicio (SDP): El Diseño de Servicio produce un “Paquete para el Diseño de
un Servicio” para cada nuevo Servicio, cambio importante o retiro de un Servicio o cambio de uno ya
producido “Paquete para el Diseño de un Servicio”.
El SDP se pasa del Diseño de Servicio a Transición de Servicio y detalla todos los aspectos del
servicio y de sus requisitos con todas las etapas subsiguientes del Ciclo de Vida.
Sistema de Gestión del Conocimiento de los Servicios (SKMS)
Conjunto de herramientas y bases de datos que se emplean para gestionar el conocimiento y la
información. El SKMS incluye tanto el Sistema de Gestión de Configuración como otras herramientas
y bases de datos. El SKMS almacena, gestiona, actualiza y presenta toda la información que un
Proveedor de Servicio de TI necesita para gestionar todo el Ciclo de Vida de los Servicios de TI.
La Gestión del Conocimiento es especialmente importante durante la Transición del Servicio pues
depende de la información disponible y del conocimiento de los usuarios, del Centro de Servicio al
Usuario, del soporte y del Proveedor del Servicio.
Sistema de Gestión de la Configuración (Configuration Management System) - (CMS)
Repositorio donde se almacenan todos los Elementos de Configuración (CIs) junto con sus atributos,
trazabilidad, relaciones y correspondencias. Puede consistir en varias bases de datos físicas que
conforman una lógica.
Buena Práctica: (Literalmente: un método correcto): ITIL® se presenta como una Buena Práctica, es
decir, enfoque o método que ha demostrado validez en la prácticas de la industria, lo que supone un
respaldo sólido para las organizaciones que desean mejorar sus servicios de TI.
Meta: Fin a que se dirigen las acciones o deseos de alguien o de una organización. Por ejemplo: La
meta de mi empresa es llegar a ser la primera de su sector y referencia en el mundo.
Objetivo: Término citado en el ámbito empresarial para referirnos al resultado que un negocio en
quiere alcanzar. Para alcanzar la meta seguramente nos marcamos unos objetivos dentro de un
plan. Por ejemplo- “Nuestra empresa se ha marcado como objetivo el aumentar las ventas este año
entorno a un 10%”.

Estrategia del Servicio .3

3.1. Fundamentos de la Estrategia de los Servicios
Un buen modelo comercial describe los medios de satisfacer los objetivos de una organización. Sin
embargo, sin una estrategia que dé cierta manera de entregar un servicio hace del Proveedor de
Servicios el objeto de valor únicamente al cliente, pero eso es poco para evitar los desplazamientos
de la organización por el dinamismo del negocio y los cambios de su espacio de mercado.
Una Estrategia de Servicio por lo tanto define un acercamiento único para entregar un mejor valor.
La necesidad del tener una Estrategia de Servicio no se limita a los Proveedores de Servicios que son
empresas comerciales. Los Proveedores de Servicios internos necesitan también tener una
perspectiva clara de sus los planes para asegurar que siguen siendo relevantes para las estrategias
empresariales de su organización.
Los clientes intentan continuamente mejorar sus modelos comerciales y estrategias. Quieren las
soluciones que no se deterioren por las barreras de su funcionamiento comercial y alcanzar la más
de alta calidad de resultados en procesos de negocio con poco o nada de aumento en coste.
Tales soluciones generalmente hacen que sus productos sean innovadores, directos, disponibles y
con entregas constantes de sus servicios. Si tales soluciones no están disponibles dentro del control
de los clientes en los contratos de servicio, o de la red del valor, se obligarán a que miren a otra
parte.
Una organización puede ser interna o externa, comercial o sin fines de lucro
¿Cómo hacer para decidir sobre una estrategia para atender a los clientes? En primer lugar,
reconocer que existen otras organizaciones cuyo objetivo es competir con la suya. Incluso las
agencias del gobierno están sujetas a la competencia
Mientras que el valor que crean a veces puede ser difícil de definir y medir, estas fuerzas exigen que
una organización deba cumplir con su misión, mejor que otras alternativas
Cuando a los directivos se les pide diseñar una estrategia, la respuesta normal es: Un plan
estratégico que detalla cómo la organización se mueve de su estado actual a un estado futuro
deseado
Pero hay deficiencias con este entendimiento. La primera dinámica es el futuro de oposición frente
al actual estado
El ritmo de cambio en los negocios es muy acelerado, no importa cuán grande sea la organización o
en lo que compitan. Las oportunidades surgen y otras desaparecen. Lo bueno de un plan de hoy
puede ser malo mañana
Una Estrategia de Servicio resuelve las grandes cuestiones para que sus empleados puedan seguir
adelante con los pequeños detalles
Pero centrarse solo en un plan estratégico puede impedir a la organización responder a entornos
cambiantes


3.2. Conceptos Genéricos y Definiciones

3.2.1. Valor de un servicio: Utilidad y Garantía
Cualquier incertidumbre en los resultados del servicio crea escepticismo sobre el valor esperado del
servicio.
Los costes pueden estar asegurados en la no varianza, pero la utilidad puede variar a partir de una
unidad de salida a otra. Para disipar dudas y convencer a un cliente sobre NO aumentos de pérdidas
posibles, el valor de un servicio se debe describir en términos de utilidad y garantía.
Los clientes no pueden beneficiarse de algo que cumple para el propósito pero no cumple para el
uso y viceversa.
La FUNCIONALIDAD (Utilidad-Lo que hace) de un servicio se comunica por los resultados o

eliminación de riesgos y costes.
La GARANTÍA (Lo bien que lo hace) asegura la funcionalidad de un servicio haciendo que
esté Disponible y que ofrezca un nivel mínimo de Capacidad, Continuidad y Seguridad.
DISPONIBILIDAD: Garantía de que el cliente hace uso de los servicios en las

condiciones acordadas de tiempo y localidad.
CAPACIDAD: Garantía de que el cliente recibe los servicios con capacidad de
almacenamiento, rendimiento y comunicaciones según lo acordado.
CONTINUIDAD. Garantía de que los clientes pueden usar un servicio incluso en
momentos de grandes dificultades o desastres.
SEGURIDAD. Garantía de que los clientes reciben el servicio con integridad,
confidencialidad y disponibilidad con toda confianza.

Service Strategy - Conceptos Básicos

Bien = Activo (Asset)
Elemento de un proceso del negocio que forma parte
de los activos de la empresa. Puede ser un CI
Elemento de Configuración (CI):
Un componente de una infraestructura o un elemento que está
o estará bajo control de la Gestión de la Configuración y Activos del
Servicio.
Ej. HW, SW, Documentación, Personas, etc.
Es siempre un Asset.
Base de Datos de Configuración - (CMDB)
Configuration Management System - (CMS)
Repositorio donde se almacenan todos los Elementos de
Configuración (CI´s) junto con sus datos, trazabilidad,
relaciones y correspondencias. Puede consistir en
varias bases de datos físicas que conforman una lógica.
LA CMS NO ES UN INVENTARIO PARA EL BALANCE

3.3. Estrategia del Servicio en el Ciclo de Vida del Servicio

Del griego ΣΤΡΑΤΗΓΙΚΗΣ Stratos = Ejército y Agein = Conductor, Guía
La Estrategia de Servicio de cualquier proveedor de servicios (SP) (De Mintzberg) se debe
basar en el reconocimiento fundamental de que sus "clientes no compran productos ni
servicios, ellos compran la satisfacción de necesidades particulares”
Visión y Misión Políticas y

Distinciones
Perspectiva Posicionamiento
Strategy
Patrones Planes
Acciones y Métodos y
Ajustes en curso Ejecución
3.3.1. Propósito
La Estrategia de Servicio permite una relación más clara entre varios servicios, sistemas o
procesos que se manejan y los modelos del negocio. Las estrategias marcan las políticas y
los objetivos que tiene que alcanzar la organización. Las 4 Ps de la Estrategia son:
Perspectiva:
Estrategia como perspectiva define las convicciones, valores y objetivos que gobiernan el
comportamiento de la organización. La perspectiva determina la dirección a través de la cual el
servicio puede mejorar los objetivos.
Posición:
Estrategia como posición define las características distinguidas de un Proveedor de Servicios ante
los ojos del cliente.
Plan:
Estrategia como plan focaliza en las acciones de la organización en un mercado competitivo. Es un
conjunto de planes coordinados a través del cual los SPs planifican e implementan estrategias de
servicios.
Patrón:
Estrategia como patrón representa los procedimientos de una organización. Como consecuencia de
la perspectiva, posición y plan, se crean las características patrón para conseguir el éxito.

Perspectiva-Posición-Plan y Patrón (Mintzberg)
Perspectiva
Plan Patrón
Posición
3.3.2. Misión
3.3.2.1. La Estrategia del Servicio tiene que responder a preguntas

como:
¿Qué servicios debemos ofrecer y quién?
¿Cómo debemos definir la calidad del servicio?
¿Cómo puede Gestión Financiera de TI proporcionar visibilidad y control sobre la
creación de valor?
¿Cómo lo hacemos para distinguirnos de la competencia?
¿Realmente vamos a crear valor para los clientes?
¿Conseguimos capturar valor para los interesados (Interesados)?
¿Podemos elegir entre diversas trayectorias para mejorar la calidad del servicio?
¿Asignamos eficientemente los recursos a través de una lista de servicios?
3.3.3. Objetivos
Identificar a la competencia y competir con ella diferenciándonos de los demás y ofreciendo un
mejor rendimiento.
Elementos básicos para los SPs:
Enfoque de mercado: Saber dónde y cómo competir.

Capacidades distintivas: Crear activos distintivos y rentables que sean apreciados por el
negocio.
Estructura basada en el rendimiento: Posiciones organizativas factibles que sea
consideradas como Activos Estratégicos
Los objetivos asociados serían:
Definir objetivos estratégicos
Determinar las oportunidades de crecimiento
Definir prioridades de inversión
Definir resultados y aprender de ellos
Crear Activos Estratégicos
Identificar claramente a la competencia
Superar a la competencia ofreciendo productos diferenciados
Desarrollar planes para conseguir el predominio sobre la competencia en el futuro


3.4.1. Recursos y Capacidades
Recursos
Recursos son entradas directas para producción tal como: Gestión, Organización, Gente y las
Experiencias que son usados para transformar los recursos.
Los recursos son más fáciles de adquirir que las capacidades.
Capacidades
Las capacidades por sí misma no producen valor sin los adecuados recursos y se desarrollan a través
de los años. Las capacidades controlan los recursos
SON LOS MAYORES ACTIVOS PARA CREAR VALOR.
Gestión A1 Capital Financiero A1

Organización A2 Infraestructura A2
Procesos A3 Aplicaciones A3
Conocimiento A4 Información A4
PERSONAS PERSONAS
Capacidades VALOR Recursos

Habilidades
3.4.2. Los Activos del Servicio como la base de la creación del valor
Las Capacidades representan la habilidad de una organización de coordinar, controlar y desplegar
los recursos para producir valor. Los activos del servicio se utilizan para crear valor en la forma de
bienes y servicios.
Los Recursos son entradas para la producción
La Organización, la Gente y el Conocimiento transforman los Recursos.
Los resultados del negocio y las opiniones del cliente definen el valor.
La capacidad de cuantificar valor agrega valor al concepto de la creación del valor, que no necesitan
necesariamente ser expresados en los términos financieros, pero se puede expresar en sensaciones,
creencia y opiniones.

3.4.3. Creación de Valor

Las PERCEPCIONES están influenciadas por:
Atributos de un servicio
Imagen de uno mismo para el cliente (innovador, líder o arriesgado)
Expectativas
Percepciones Preferencias
filtro
Resultados
de negocio
contexto
Atributos
Puede ser fácil calcular el valor económico de un servicio, pero a veces es difícil calcularlo
realmente, aunque siempre tendrá que ser posible su cálculo. El cálculo del valor puede depender
del cliente desde su percepción, por experiencias presentes o pasadas, su posición en el mercado,
etc.
El Proveedor de Servicios debería:
Demostrar valor
Influenciar en las percepciones
Responder a las preferencias
3.4.4. Red de Valor

Una Red de Valor es un sistema de relaciones que generan valor tangible e intangible mediante
intercambios complejos y dinámicos entre dos o más organizaciones
A veces necesitaremos de otros SP proveedores de servicio para agregar valor a nuestra
organización y para ello hay diversos modelos de organización a nivel mundial, por lo que
brevemente exponemos los más conocidos en la industria.

3.4.5. Modelo de Servicios

Los Modelos del Servicio describen la forma en que los Activos del Servicio interactúan con los
activos del cliente y crean valor para una determinada Cartera de Contratos.
Planes Cartera
Estratégicos de Servicios
¿Qué tipos de
Cartera Contratos de
servicio
de Clientes Servicios a proveer
se ofrecen?
¿Cómo se
Planes y patrones
especializan los
activos del servicio? operativos
Los Acuerdos de Nivel de Servicio (SLAs) especifican los términos y las condiciones en los cuales esta
interacción ocurre en cada lado.
Los resultados definen el valor que se creará para el cliente, que estarán basados en la utilidad y
garantía que se entregará al cliente.

3.4.6. Modelo de Kano

Los servicios pueden presentar atributos de estimulación, que los clientes no esperan pero que les
gustaría tener, con una oferta razonable. Ciertos clientes pueden considerarlos como factores de
rendimiento con utilidad unidimensional, y para otros, son factores de estimulación. Su ausencia no
provoca insatisfacción. Su presencia genera un incremento drástico de la satisfacción a un precio
razonable.
Los factores de estimulación y los factores de rendimiento son la base para la segmentación del
mercado y niveles de servicio diferenciados. Se utilizan cuestionarios para recabar sobre los
atributos que un servicio debe tener. La Tabla de Kano es un buen método.
Nivel de Factores de
satisfacción Factores de
estimulación
rendimiento
Alto
Utilidad atractiva
de poseer
Atractiva
de poseer
Evolución Máximo
cumplimiento Nivel de
cumplimiento
Sin cumplir
Factores
Utilidad básicos
unidimensional
Bajo
Utilidad
obligatoria
Tipo de atributo Cumplimiento y percepciones de utilidad

(ganancia/pérdida)
Factores Básicos (B) Atributos esperados del servicio que se dan por hecho. La
Se debe tener, no lineal falta de cumplimiento provocará percepciones de pérdida
de utilidad. Si se cumplen generará una ganancia de utilidad
pero solo hasta la zona neutra a partir de la cual no habrá
ganancia.
Factores de estimulación (E) Atributos del servicio que impulsan percepciones de ganancia
(Utilidad atractiva, no lineal) de utilidad pero que, cuando no se cumplen, no generan
percepciones de perdida de utilidad
Factores de rendimiento (P) Atributos del servicio que generan percepciones de ganancia
(Utilidad atractiva, lineal) de utilidad cuando se cumplen y pérdida de utilidad cuando no
se cumplen en un patrón unidimensional, casi siempre lineal
Atributos Indiferentes (I) No generan ni ganancias ni pérdidas en las percepciones de
utilidad, independientemente de si se cumplen o no
Atributos invertidos (R) Generan ganancias en percepciones de utilidad cuando no se

cumplen, y pérdidas cuando se cumplen. Es necesario invertir
los supuestos.
Respuesta cuestionable (Q) Las respuestas son cuestionables posiblemente porque las
preguntas
no eran claras o se mal interpretaron

3.5. Modelos de Organización

3.5.1. Proveedor Externo de servicios
A veces es más eficiente externalizar los servicios (outsourcing) pero hay que tener en cuenta:
Riesgos:
Sustitución. El vendedor puede reemplazar el origen de la organización.

Disrupción: El vendedor puede dañar su reputación.
Distinción: Puede desarrollar una dependencia del vendedor.
3.5.2. Ciclo de creación de valor
3.5.3. Otros modelos

1 – Network o malla: Enfocada a la rápida provisión de servicios y sobre la marcha.
Cuando la demanda se incremente este modelo ya no es efectivo.
2 – Dirigido: Ya hay un equipo de directores. Comunicación más formal y hay procesos
básicos. Si se crece más hay que delegar.
3 – Delegado: Se trata de reducir costes y mejorar servicios. Hay que delegar funciones
y se tiene la impresión de perder el control.
4 – Coordinación: Se usan sistemas formales. La centralización de funciones técnicas y
la descentralización de la Gestión de Servicios trata de mejorar el tiempo de respuesta a
las demandas del mercado
5 –Colaboración: Se mejora la co-ordinación con el Negocio. Se usa como estructura
matricial minimizando las barreras. Equipos líderes en el conocimiento de habilidades de
los productos y clientes

Servicios a través de Etapa 3: Delegación
Servicios a través de Etapa 5: Colaboración

3.5.4. Tipos de Proveedores de Servicios

1 – Internal Proveedor de Servicios: Mas control pero menos escalado. Prestan servicios
dentro de las propias Unidades de Negocio (UN).
2 – Share Services: Menos costes, trabaja con los UN internos y/o externos, aún poco
escalable. Pueden ser sustituidos
3 – External Proveedor de Servicios (Traditional outsourcing): Único contrato con el
vendedor, escala bien pero limitado para mejores capacidades.
4 – Multi-vendor outsourcing:
Prime - Único contrato con proveedor que a veces trabaja con otros
Proveedores de Servicios.
Consortium - Múltiples SPs, son los mejores en su clase; pero trabajan
quizás con la competencia.
Selective outsourcing - Un pool de seleccionados SP y gestionados por
Unidades de Negocio.
Co-Sourcing - Variable de Selective outsourcing en el que recibe combina
internos y share con externos SPs. La organización los integra. Más difícil.
3.5.5. Situaciones de externalización

On-shore: Basadas dentro del mismo país / continente.
Off-shore: Organizaciones en diferente país / continente.
Los acuerdos sencillos y muy complejos de la compra de componentes y servicios existen dentro de
la industria de TI en todo el mundo y es imposible cubrir todas las combinaciones y sus implicaciones
aquí
Aprovisionamiento Multiproveedor
Externalización Selectiva
Consorcio
Capacidades de primer nivel
Control directo
Preferencial
Aprovisionamiento tradicional
Externalización del Servicio Completo
Servicio Compartido
Aprovisionamiento interno
Interno

3.5.6. Outsourcing Structures (Roles

Director de Gestión del Servicio: Supervisa al proveedor en nombre de la empresa.
Gestor de Contrato: Gestiona los contratos de los proveedores y suministradores.
Gestor de Producto. Gestiona los servicios en la organización del Proveedor de
Servicios.
Propietario del Proceso. Gestiona los modelos de proceso que se han creado para
los usuarios.
Representantes del Negocio: Representan los intereses del cliente.

3.6. Los Procesos de la Fase de la Estrategia de Servicios
Gestión de la Estrategia de TI (SM)

Gestión Financiera de Servicios de TI (FM)
Gestión de la Demanda (DM)
Gestión de la Cartera de Servicios (SPM)
Gestión de Relaciones con el Negocio (BRM)


3.7. Gestión de la Estrategia

3.7.1. Generación de Estrategias
Mejorar el impacto estratégico a través del diseño, el desarrollo, la implementación y la

práctica de Service Management
Como capacidad de organización
Como activo estratégico
Permitir a los responsables hacer frente a demandas del mercado y afinar las estrategias
Actividades más importantes
Definir el mercado
Desarrollar las ofertas
Desarrollar los Activos Estratégicos
Prepararse para la ejecución
3.7.2. Ámbito
Gestión de la Estrategia es responsabilidad de los directivos de una organización

Les permite fijar los objetivos de la organización, para especificar cómo la
organización va a cumplir con estos objetivos y dar prioridad a las inversiones
necesarias para cumplirlas
En organizaciones medianas y grandes es poco probable que los ejecutivos lleven a
cabo las evaluaciones, el proyecto de los documentos de la estrategia y gestión de la
ejecución
Esto es normalmente realizado por una estrategia dedicada y responsable de la
planificación de informes directamente a la Junta Directiva
La estrategia de una organización no se limita a un solo documento o un
departamento. La estrategia general de una organización se divide en una
estrategia para cada unidad de negocio
3.7.3. Valor
La Estrategia de una organización articula sus objetivos, y define cómo se va a

cumplir con esos objetivos y cómo va a saber que ha cumplido con los objetivos
Sin una Estrategia, la organización sólo será capaz de reaccionar a las demandas
impuestas por las diversas partes interesadas, con poca capacidad para evaluar cada
demanda y cómo afectará a la organización
En estos casos, las acciones de las organizaciones tienden a ser conducidas por quien
está haciendo más fuerza en la demanda, en lugar de lo que es mejor para la
organización
Así la Estrategia se convierte en una función de la política de la organización y el
interés propio, en lugar de la realización global de sus objetivos

3.7.4. Políticas
Hay que definir un modelo genérico para la ejecución y medición de la Estrategia de

Servicio. Esto se puede aplicar en el nivel más alto de la organización, o cómo la
estrategia forma parte de la organización
La Estrategia de una organización se define por sus ejecutivos
Si la organización es un Proveedor de Servicios (SP) externo, con un núcleo de
negocios basado en la prestación de Servicios, la Estrategia del Servicio es el
componente central de la estrategia de la organización
En los SPs internos, la Estrategia de Servicio presta apoyo a la estrategia empresarial
general, y proporciona un plan táctico para el Proveedor de Servicios interno (Tipo I)
Mientras que la estrategia de TI es estratégica para la organización de TI, el Comité
de Dirección considerarán que es más táctico, desde su punto de vista, más que
estratégico
Por tanto, es vital que la estrategia de TI se defina en términos de estrategia global
de la organización
3.7.5. Misión
La misión de la fase de Estrategia del Servicio es desarrollar las capacidades necesarias para lograr
y mantener una ventaja estratégica y debería responder a:
¿Qué servicios deberíamos ofrecer y a quién?
¿Cómo nos diferenciamos de la competencia?
¿Cómo realmente creamos valor para nuestros clientes?
La consideración de los resultados del negocio y la creación de valor son principios de la Estrategia
del Servicio.
Permitir a los responsables hacer frente a demandas del mercado y afinar las estrategias por lo
que habrá que . . .
Definir el mercado
Desarrollar las ofertas
Desarrollar los activos estratégicos
Prepararse para la ejecución

3.7.6. Actividad 1 – Definir el Mercado
Definir servicios para Estrategias de Servicios y para Estrategias de Negocio.

Entendiendo al cliente
Entendiendo las oportunidades
Identificándose con el Negocio
Clasificar y visualizar
Estrategias Estrategias Estrategias

para de Servicios de Negocios
Servicios
Servicios
Servicios Servicios para
Estrategias
ENTENDIENDO AL CLIENTE
Para definir el valor de un servicio, el funcionamiento de los activos del cliente debe ser el foco
primario de la Gestión de Servicios, porque sin los activos del cliente no hay base para definir el
valor de un servicio para que un Negocio alcance sus objetivos.
ENTENDIENDO LAS OPORTUNIDADES
Los activos que usan los clientes para crear valor son formas de oportunidades de alcanzar el buen
funcionamiento para el Negocio que a cambio permitirá o realzará el valor-creación y por ello una
organización debe entender así las oportunidades.
Las nuevas oportunidades emergen cuando los cambios en el entorno empresarial consiguen un
resultado, hasta ahora bueno o mal resultado, si no se entienden esas oportunidades de Negocio
IDENTIFICANDOSE CON EL NEGOCIO
El Negocio necesita identificar los resultados para cada espacio del cliente y del mercado y que caiga
dentro del alcance de la estrategia particular de cada organización
CLASIFICANDO Y VISUALIZANDO
Los servicios se diferencian sobre todo por cómo crean valor y en qué contexto.
Los arquetipos del servicio son equivalentes a los modelos comerciales para los servicios
Examinar cómo los servicios crean valor y más qué activos necesitan ser implementados
para crear valor. Esto nos dará el valor de la inversión
Los servicios con los patrones que más se emparejan nos indican la oportunidad para la
consolidación o como servicios compartidos pueden crear valor
Cuando los servicios tienden a compartir espacios de mercado también tienden a
compartir las capacidades, los recursos, los costes, los riesgos, los desafíos, las
oportunidades etc.
Los servicios con alto nivel de solapamiento se podían consolidar bajo las mismas
operaciones.

Clasificar y visualizar las oportunidades de servicio en modelos de negocio.
Portfolio Arquetipo o Modelo de servicio Contexto donde se crea valor
1 Arquetipo
puede…
N servicios
.
Resultados de la creación de valor

Cuando analizamos los resultados de la creación de valor para el negocio del cliente hay que
considerar los siguientes atributos del servicio
1. Objetivos del Negocio
2. Objetivos de TI
3. Las métricas de los procesos
Servicios Similares Pueden Tener El Mismo Paquete De Servicio De Línea de
Referencia

3.7.7. Actividad 2 – Desarrollar las Ofertas

ESPACIO DE MERCADO
El espacio del mercado es definido por los resultados que los clientes desean y que son facilitados
por servicios. Representa un conjunto de oportunidades de entregar valor con los servicios
DEFINICIÓN DE RESULTADOS BASADOS EN SERVICIOS
Entregando valor a los clientes y facilitándole los resultados sin que ellos asuman costes y riesgos
específicos y habría que plantearse las siguientes preguntas.
¿Qué tipo de servicio ofrecemos? (tipo de servicio)
¿Quiénes son los clientes? (tipo de servicio)
¿Qué tipo de resultados se obtienen? (Funcionalidad)
¿Cómo crean valor estos resultados a los clientes de nuestros clientes? (Funcionalidad)
¿A qué limitaciones deben hacer frente los clientes? (Funcionalidad)
CARTERA DE SERVICIOS (SERVICE PORTFOLIO)
Es la lista de los servicios que representan todas las entregas e inversiones hechas por un proveedor
de servicio para todos los clientes y espacios de mercado.
3.7.8. Actividad 3 – Desarrollar los Activos Estratégicos

ACTIVOS ESTRATÉGICOS
La Gestión de Servicios es un activo estratégico y se debe confiar en desafíos y oportunidades en
términos de clientes, servicios y contratos de soporte. La inversión en activos confiables tiene menos
riesgos porque tienen la capacidad de una entrega más constante.
GESTIÓN DE SERVICIOS COMO LAZOS CERRADOS
La Gestión de Servicios es el abastecimiento de valor a los clientes en forma de servicios. Cuento
mejor ofrecemos más nos demandan. Las capacidades interactúan unas con otras para funcionar
como un sistema de creación de valor.
Capacidad
+ Rendimiento
Potencial de
+ para servir
Unidades de Unidad de
Negocio Servicios - Coste por Servicio
Capacidades
- RIESGO
Nivel de
Servicio
Capacidades
y Entrega y
+ Demanda Recursos
Recursos
- Capacidad
no usada

3.7.9. Actividad 4 – Prepararse para la implementación

ESTRATEGIA
Un proceso se puede representar en un modelo, alrededor del cual una estrategia puede ser
construida.
La estrategia no garantiza el éxito, ello requiere de la reflexión y examen y hacerla en un contexto
de empatía
Medir y evaluar
Generación de Estrategias,
Sugerencias de Estrategias evaluación y selección
Determinar Visión
Análisis las
Factores Perspectivas
externos
Formar Directivas
Una (Políticas)
Posición ESTRATEGIA Mejora
Objetivos DEL Continua del
Establecidos SERVICIO Servicio
Dibujar
un Servicio Portafolio
Plan
Análisis Planes Requerimientos para
Factores Diseño de Servicio
internos
Adoptar un
Requerimientos para
Patrón de Transición de Servicio
acción Acciones
Requerimientos para
Operaciones de Servicio
Medir y evaluar
Las 4 P’s
Based On Cabinet Office ITIL® Material. Reproduced Under License from The Cabinet Office
SUGERENCIAS DE ESTRATEGIAS
La estrategia actual tiene que ser definida antes de desarrollar una nueva estrategia, pues una base
de la diferenciación podría existir ya.
Necesitamos crear un patrón.
¿Cuáles de nuestros servicios o variedades del servicio son distintos a la mayoría?

¿Cuál de nuestros servicios o sus variedades son los más provechosos?
¿Cuáles de nuestros clientes e Interesados están satisfechos?
¿Qué clientes, canales de compra y por ocasiones están la mayoría provechosos de
nuestros servicios?
¿Cuáles de nuestras actividades en nuestra cadena de valores o red del valor son la
mayoría diferentes y eficientes
ACTIVOS DEL SERVICIO DEBEN ALINEARSE CON LOS DEL CLIENTE
Los Proveedores de Servicio (SP) deben manejar los activos de manera semejante a la de los clientes,
pues así se asegura que los activos del Servicio están coordinados, controlados y desplegados para
maximizar el valor a los clientes, mientras que los riesgos y los costes se minimizan al proveedor
DEFINIR LOS FACTORES CRÍTICOS DE ÉXITO

Los Factores Críticos de Éxito determinan el éxito o la falta de una Estrategia de Servicio y están
influenciados por necesidades de los clientes, tendencias del Negocio, la competencia, las leyes
reguladoras, los proveedores, los estándares, las mejores prácticas de la industria y las tecnologías.

FACTORES CRÍTICOS DE ÉXITO (CSF) Y ANÁLISIS COMPETITIVO

Tienen las siguientes características:
Se definen en términos de capacidad y recursos

Se ven como la clave para el éxito en el mercado
Se definen a nivel de mercado
Son la base para competir entre rivales
Son dinámicos
Se requiere tiempo e inversión en su desarrollo
Su valor se calcula en combinación con otros factores
Los CSF dependen de:
Clientes
Competencia
Suministradores
Reguladores
LOS CLIENTES TIENEN NECESIDADES SIMILARES A LA JERARQUÍA DE MASLOW PARA

INDIVIDUOS:
EXPLORANDO POTENCIALES NEGOCIOS

Los proveedores de servicio pueden estar presentes en muchos espacios de mercado y deben
analizar su posible presencia en futuros mercados. Es muy recomendable el análisis DAFO
(Debilidades, Amenazas, Fortalezas y Oportunidades)

ALINEAMIENTO CON LAS NECESIDADES DEL CLIENTE
Entendiendo la mutua relación entre clientes, TI y espacios de mercado

La estrategia determina generalmente la asignación de espacios y viceversa, llevando los
cambios a cualquiera de los dos, clientes y TI
Las estrategias de los proveedores se deben de alinear con la de los clientes si quieren
obtener los mismos resultados.
EXPANSION Y CRECIMIENTO
Las estrategias acertadas de expansión se deben basar en activos y listas existentes de Servicios para
ir a un nuevo crecimiento y con menos riesgo.
DIFERENCIACION EN ESPACIOS DE MERCADOS
Las CSF determinan de forma independiente si los suministradores son competitivos en su oferta del
servicio, asequibilidad, la entrega, plazos de ejecución, disponibilidad, etc.
Establezca la separación entre las curvas de valor para determinar el valor que nos
distingue ofrecido en servicios con la evaluación comparativa
La prueba patrón se puede basar en promedios de la industria, el rival más cercano
o la mayoría de las alternativas más atractivas para el cliente
La opinión del cliente se puede medir en cierta escala o índice convenientemente
aceptado dentro de la industria o de la región.
Trate de Mejorar a través de una inteligente combinación de servicios, efectividad y
eficiencia.
3.7.10. Prueba Patrón
10
Patrón o Direrenciación
Punto de
Referencia
Percepción
del Espacio no
Cliente contestado
Su
Organización
0
Disposición Confiabilidad Conformidad
Opción de Ayuda técnica
Asequibilidad de Costes reguladora
Plataformas In situ
Y tiempos
La prueba patrón se puede basar en promedios de la
industria, el rival más cercano o la mayoría alternativa y
mas atractiva para el Cliente. La opinión del cliente puede
ser medida en cierta escala o índice aceptado dentro de la
industria.

 Realizar la Prueba Patrón o Benchmark debe ser imprescindible tener que:

• Asegurar apoyo de la gerencia
• Adoptar una visión externa
• Comparar procesos, no resultados
• Involucrar a los propietarios del proceso
 Establecer equipos de benchmarking
 Adquirir las habilidades
3.7.11. Entradas Actividad 4 Prepararse para la implementación

Planes existentes
Investigación sobre aspectos de entorno por organizaciones especializadas
Estrategias de los proveedores y hojas de ruta de sus producto, que indican el
impacto (y las posibles oportunidades) de las nuevas tecnologías
Entrevistas a los clientes y los planes estratégicos para indicar posibles necesidades
futuras
La Estrategia del Servicio con los compromisos actuales y previstos de Servicios
Servicios de información para indicar la eficacia de la estrategia
Informes de auditoría que indican el cumplimiento (o la desviación ) de la estrategia
de la organización
3.7.12. Salidas
Los planes estratégicos , en este contexto y en especial la estrategia de servicio
Planes tácticos que identifican cómo la estrategia se ejecutará
Estrategia de programación de revisión y documentación
Misión y visión
Las políticas que muestran cómo los planes deben ser ejecutados, cómo los Servicios
se diseñarán, la Transición, Operación y Mejora Continua
Las necesidades estratégicas de los nuevos Servicios, y las entradas para los Servicios
existentes que puedan ser cambiados
3.7.13. Relaciones con otros procesos

Gestión de Relaciones con el Negocio
Gestión Financiera de Servicios de TI
Gestión dela Demanda


3.7.14. Disparadores
La planificación anual de ciclos de la Estrategia de Servicios se utiliza para examinar
y planificar sobre una base anual
Nuevas oportunidades de negocio
Gestión de la Estrategia de Servicios de TI, analiza, establece objetivos, perspectivas,
posiciones, planes y patrones de negocio o nuevos Servicios
Los cambios en la estrategia de gestión interna o externa para entornos de Servicios
de TI, y evaluar el impacto de los cambios de entorno en los planes existentes,
estratégicos, tácticos y operacionales
Fusiones o adquisiciones con otra empresa dará lugar a un análisis detallado y la
definición de la estrategia de la nueva organización
3.7.15. Desafíos
Que Gestión de la Estrategia de Servicios de TI se lleve a cabo en el nivel equivocado
en la organización, pues debe ser impulsada por los altos ejecutivos, y cada unidad
de organización debe seguir adelante con la elaboración de un plan estratégico,
táctico y operativo que es un subconjunto de la estrategia empresarial
La falta de información precisa sobre el entorno externo
La falta de apoyo por los interesados
La falta de mecanismos de control de documentos y procedimientos
Los objetivos operativos deben de ir acompañados de los objetivos estratégicos
3.7.16. Riesgos
Un modelo de gestión defectuoso que permite a
Los Gerentes desviarse de la estrategia a corto plazo
Prioridades a corto plazo que anulan las directivas de la estrategia. Por ej.: menos
ventas en un trimestre puede alentar a los Gerentes a aplicar incentivos y medidas
que lleven a la organización fuera de las políticas y objetivos estratégicos
La toma de decisiones estratégicas, cuando hay falta de información acerca de los
entornos internos o externos
3.7.17. Retorno de la Inversión

Caso de negocio:
Un instrumento de toma de negocios, soporte y planificación que prevé las consecuencias
probables de una acción de negocio. (¿Si invierto en este activo, lo recupero y cuándo?
ROI - Pre-Programa:
Presupuestar hoy para aumentar el flujo de caja de entrada o disminuir el de salida.
ROI - Post-Programa :
Técnicas para analizar retroactivamente las inversiones en Gestión de Servicios.
3.7.18. Automatización del Servicio

La automatización debe tener efecto sobre el rendimiento de Activos del Servicio, como la gestión,
la organización, la gente, los procesos, el conocimiento y la información.
La automatización tiene efecto considerable sobre el rendimiento de los Activos del Servicio y se
deben seguir los pasos siguientes:
Simplificar los procesos sin perder información importante.
Clarificar el flujo de actividades, el reparto de tareas y las interacciones.
Minimizar el área de contacto entre los usuarios y los sistemas.

No automatizar tareas sin analizar antes si éstas incluyen interacciones complejas y

no rutinarias.
La automatización de tareas tienen que ser simples y fáciles de entender.
Simplificar los procesos antes de automatizarlos.
3.7.19. Detalles de Paquetes en la estrategia

Un Paquete de Servicio (SP): Es una descripción detallada de un servicio TI que está disponible
para entregarse a un cliente. Incluye un Paquete a Nivel de Servicio (SLP) y uno o más Servicios
Esenciales y Servicios Añadidos.
Un Paquete a Nivel de Servicio (SLP): Nivel definido de utilidad y garantía para un determinado
Paquete de Servicios (SP). Diseñado para un determinado Patrón de Actividades de Negocio.
Paquete de Servicio Esencial (Core Service Package-CSP): Descripción detallada de un Servicio
Esencial que puede estar incluido en varios SLPs.
Línea de Servicio (LOS): Servicio esencial o de soporte con múltiples SLPs. Controlado por un
Product Manager y cada SLP está diseñado para un segmento muy concreto del mercado
3.7.20. Paquete de Servicios (SP)
Estrategia del Servicio- Paquete de Servicio (SP)

Nombre del Paquete de Servicio: “Super Usuario” 60 € mes
Paquete de Servicios de Soporte

Paquete de Servicios Dirección IP estática
Principal o Esencial Filtro antispam
100 MB espacio web
(CSP) VOIP
Conexión a Internet (Provee las diferencias o más uso efectivo
Correo electrónico del CSP y representan características que
(Servicios críticos básicos) diferencian nuestro producto de otros
similares ofrecidos por la competencia)
Paquete de Nivel de Servicio

(Nivel definido de Utilidad y Garantía por el Paquete de Servicio)
Nivel de Disponibilidad Nivel de Capacidad
Nivel de Continuidad Nivel de Seguridad
Características del Servicio
Soporte del Servicio

Velocidad de Descargas: 8000kbs – 24000kbs 98 % Garantía de Disponibilidad
Límite de Descargas: 30 GB Soporte 24 x 7
3.7.21. Cuadro Integral de Mando (Balanced Scorecard) (Kaplan &

Norton)
La forma más efectiva de conseguir alinear TI y el negocio.
Método para medir las actividades de una compañía en términos de su visión y estrategia.
Proporciona a los administradores una visión global de las prestaciones del negocio. Los cuadros
equilibrados representan un sistema de gestión que permiten incrementar el número de sus
unidades de negocio para clarificar su visión y estrategia en la acción.
El Cuadro de Mando Integral (Balanced Scorecard) constituye una de las herramientas más eficaces
para implementar y llevar a la práctica el plan estratégico de la Compañía.

Hoy por hoy el mercado nos demuestra que no basta con gestionar únicamente con indicadores
financieros, lo que conlleva un énfasis excesivo en la consecución de resultados a corto plazo.
Se hace necesario utilizar indicadores no financieros que apoyados en la metodología del Balanced
Scorecard nos ayuden a concentrar los esfuerzos en crear verdadero valor a medio y largo plazo.
Tradicionalmente las organizaciones no se suelen enfrentar a grandes dificultades para definir su
estrategia, sino para su implementación.
Agrupa objetivos, indicadores e iniciativas estratégicas bajo cuatro perspectivas: financiera, clientes,
procesos e innovación y aprendizaje » Estructura de mapa estratégico.
Para cada una de estas perspectivas se define qué es lo que se quiere lograr y cómo se va
a medir.
A continuación se definen las metas, que nos darán las claves que determinen los cambios
en la organización.
Y finalmente las iniciativas estratégicas, que son las acciones que provocarán los cambios
buscados.
Tiene la función primordial de traducir la visión y la estrategia de la organización, en un
conjunto de indicadores que informen de la consecución de los objetivos.
El cuadro de mando es una herramienta indispensable para alinear de forma coherente a
las personas con el plan estratégico, y de esta forma ayudar a conseguir los objetivos
estratégicos de la Organización.
3.7.22. Interlocutores con Proveedores de Servicios (SPI)

Durante las conversaciones del contrato se deben negociar el alcance, las responsabilidades,
dependencias y niveles de servicio.
Identificación de varios puntos de integración con otros procesos de gestión

Identificación de roles y responsabilidades concretas.
Identificación de información de gestión que es relevante para el cliente.
Uso de Interlocutores del Proveedor de Servicios

Definiciones de Especificación Relación de
Procesos del Servicio Aprovisionamiento
SPI
Contrato
de Servicio A
Gest. de Cambios
SPI
SPI
SPI Contrato
SPI de Servicio B
Gest. del Servicio
SPI
Contrato
de Servicio C
Distribución
del Software

3.7.23. Factores Críticos de Éxito y Análisis competitivo

Un factor de éxito es algo que debe ocurrir (o debe no ocurrir) para conseguir un objetivo. Este
Factor de Éxito se define como Crítico si su cumplimiento es absolutamente necesario para
cumplir los objetivos de la Organización.
Están influenciados por las necesidades del cliente, tendencias de los negocios, proveedores,
estándares, leyes, etc., y tienen las siguientes características básicas:
Se definen en términos de capacidad y recursos

Se ven como la clave para el éxito en el mercado
Se definen a nivel de mercado
Son la base para competir entre rivales
Son dinámicos
Se requiere tiempo e inversión en su desarrollo
Su valor se calcula en combinación con otros factores
Los factores de una estrategia de externalización dependen de:
Los resultados deseados.

Un modelo óptimo para la prestación de servicios.
Una posición idónea para la prestación de servicios.
Recomendaciones para desarrollar la estrategia.
Analizar las competencias internas de la organización para la Gestión de Servicios.

Comparar las averiguaciones con las referencias de la industria.
Examinar las habilidades de la organización para generar valor estratégico.
Para ello se suelen usar dos tipos de métricas:
Métricas de negocio: Eficacia de los procesos, ahorro financiero, mejora del Nivel de
Servicio, etc.
Métricas de cliente: Disponibilidad, calidad de servicio, más y mejor suministro, etc.

3.7.24. Herramientas para la Estrategia del Servicio.

Simulación: Las Dinámicas del Sistema son una metodología para comprender y
gestionar los complejos problemas de las organizaciones de TI.
Trampa de capacidad
Trampa de herramientas
Trampa del bombero
Modelado analítico.
Six Sigma, PMBok y PRINCE2 son métodos de eficacia probada basados en modelos
analíticos.
Deben ser evaluados y adoptados en el contexto de Estrategia del servicio
3.7.25. Sistema de planificación y monitorización de bucle

cerrado para la estrategia.
Medición & Evaluación
Implementación de estrategia
Diseño
Requerimientos de de Servicio
Diseño de Servicio
Continual
Estrategia Transición Service
de Servicio de Servicio Improvement
Requerimientos de
Service
Catalogue
Service
Portfolio
Operación
Requerimientos de
de Servicio
3.7.26. Indicadores Clave (KGI – KPI)

KGI (Key Goal Indicator) La Visión establece Dónde queremos estar
KPI (Key Performance Indicator) Le medición establece Dónde estamos ahora
Demuestran como la Organización de TI agrega valor al negocio.
Determinan la efectividad de la Organización de TI.
Fijan guías para el plan estratégico de TI.
Comunican y motivan acerca del funcionamiento de TI.
Establecen los informes de Gestión de TI.


3.8. Gestión Financiera de Servicios de TI

3.8.1. Objetivos
Definir y mantener un marco para identificar, gestionar y comunicar el coste de la
prestación de Servicios
La evaluación del impacto financiero de estrategias nuevas o modificadas en el Proveedor
de Servicios
Asegurar el financiamiento para gestionar la prestación de Servicios
Facilitar una buena administración de los bienes y Servicios al cliente para asegurar que la
organización cumpla sus objetivos
Comprender la relación entre gastos e ingresos y asegurar que estén equilibrados de
acuerdo a las políticas financieras de la organización
Gestión de informes de gastos en la prestación de Servicios, en nombre de las partes
interesadas de la organización
Ejecución de las políticas financieras en la prestación de Servicios
Pronóstico de las necesidades financieras de la organización para cumplir los compromisos
de Servicio a sus clientes y cumplir los requisitos normativos y legislativos
En su caso, la definición de un marco de trabajo para recuperar los costes de la prestación
de Servicios por parte del cliente
3.8.2. Valor para el Negocio

Al igual que otras partes del negocio, las organizaciones de TI están utilizando cada vez
más el proceso de Gestión Financiera para ayudar en la búsqueda de:
Mejorar la toma de decisiones
La velocidad de adaptarse más rápidamente al cambio
La gestión de la Estrategia del Servicio
Los cumplimientos legales y control financiero
El control operacional
La captura y creación de valor
Modelado de la demanda
3.8.3. Valoración del Servicio

Valorando el servicio se cuantifica en términos financieros qué recursos económicos busca el
negocio y TI para la prestación de los servicios acordados con el cliente.
El valor se calcula convirtiendo la funcionalidad y la garantía en una cifra monetaria. ITIL® usa dos
conceptos de valor para la Valoración de los servicios
Valor de provisión: Cubre los costes subyacentes reales de TI incluyendo los tangibles y no tangibles
como:
Licencias de hardware y software
Mantenimiento anual de hardware y software
Personal de mantenimiento y soporte
Costes de instalaciones
Impuestos, amortizaciones e intereses
Costes de conformidad

Valor Potencial del servicio: Componente de valor añadido, basado en la percepción de valor del
servicio o en el Utilidad y Garantía esperadas del uso del servicio.
Los Activos del cliente son la base de creación de Valor

Potencial de valor
del servicio
Rendimiento
Potencial
Rendimiento
Activos del Activos
de Nivel de
Cliente del
+ Servicio +
diseñado y Servicio
entregado
Valor potencial Valor de la Provisión

liberado del Servicio
+
Resultado
Realización del valor del
deseado
Servicio
3.8.4. Actividades Principales
Requisitos de TI Plan Operacional TI Análisis de

del Negocio del (incl. Presupuestos) Costes Cargos
Cliente (Contabilidad)
Objetivos Métodos de CHARGING

Financieros Control de Costes Cargos
PRESUPUESTO: CONTABILIDAD:
Proceso de Conjunto de procesos
planeamiento y para registrar los
control de gastos gastos con la
que consiste de una Feedback al Negocio sobre habilidad de poder
negociación por los cargos propuestos identificar costes por
periodo y el cliente, servicio,
monitorizar del día a actividad, etc.
día.

3.8.5. Presupuesto
Asegurar que los fondos necesarios estén disponibles para la provisión de servicios de TI y
que durante el periodo de presupuesto no se gasten en exceso.
Influencia clave en planes estratégicos y tácticos.
El Presupuesto puede tener:
Límites en gastos de capital.
Límites en gastos operacionales.
Límites en varianza en cualquier momento del tiempo, entre gasto presupuestado y
actual.
Directrices en cómo se debe utilizar el presupuesto.
Una carga de trabajo definida y acordada, así como un conjunto de servicios a
entregar.
Los presupuestos realizados pueden tener diferentes horizontes temporales.
Pueden ser a corto plazo, incluyendo los costes de los servicios prestados en la actualidad, o resultar
de una proyección sobre la evolución prevista del negocio en dos o más años. Aunque no existe una
única manera de realizar un presupuesto TI se exponen dos métodos habituales:
Presupuesto incremental: Se realiza en base al histórico de presupuestos anteriores,
adaptándolos a las modificaciones en los costes y el desarrollo de nuevas tecnologías y
teniendo en consideración la aparición de nuevos servicios.
Presupuesto "desde cero": Se replantea toda la estructura de costes e inversiones a partir
de una "hoja en blanco" en base a los servicios prestados en la actualidad y las
expectativas de crecimiento en el periodo presupuestado
3.8.6. Contabilidad
Nos permite basar decisiones sobre los servicios al ser proporcionados en evaluaciones de
efectividad de costo, servicio a servicio.
Tomar decisiones “como-negocio” sobre los servicios de TI y las inversiones en ellos.
Proporcionar información para justificar gastos de TI.
Planear y presupuestar con seguridad.
Demostrar el infra o sobre consumo de servicio en términos financieros.
Entender los costes que implica el no aprovechar las oportunidades de cambios
tecnológicos.
3.8.7. Costes
Proporcionar servicios de Ti a los clientes a un COSTE razonable depende de tres factores:
Calidad en términos de operación de:
Capacidad
Disponibilidad
Rendimiento
Continuidad
Soporte

Coste en términos de
Gasto
Inversión
Requisitos del cliente
El coste y la calidad deben alinearse con las necesidades del usuario con relación al
negocio.
3.8.8. Los costes pueden ser

Fijos: No afectados por el nivel de uso.
Variable: Variando de acuerdo con el nivel de uso.
Directos: Costes que se pueden identificar y asignar directamente a un cliente o servicio.
Indirectos: Gastos generales, no específico a un servicio, prorrateados entre los diferentes
clientes.
Capitales: Disminuidos por uso, provienen del inmovilizado material.
Operacionales: No disminuidos por uso, costos del día a día. P.ej.primas de seguro,
licencias.
3.8.9. Centros de coste

Unidad de Costes de Hardware
Unidad de Costes de Software
Organización de empleados (RRHH)
Unidad de Costes de Alojamiento (Hosting)
Unidad de Costes de Servicios
Externos (Outsourcing)
Unidad de Costes de Transferencia
3.8.10. Cobros
Recuperar de los clientes los costes completos de los servicios proporcionados de TI de
manera justa.
Asegurar que los clientes conozcan los costes que le impone TI e influir en el
comportamiento del cliente.
Hacer evaluaciones formales de servicios de TI y planear la inversión basada en la
recuperación de costes y beneficios de negocio.
3.8.11. Tipos de cobros

Cobros con noción (Se presenta pero no se cobra o como fase de presentación de la
imputación de costes verdaderos, es un cobro nominal).
Recuperar costes ( 0% para clientes internos).
Precio sujeto a niveles. (Varía según utilidad)
Precios directo plus.(Se incrementan de acuerdo a un porcentaje de costes indirectos
compartidos)
Coste fijo o por usuario. (No contribuye a influir en el cliente)
Uso medido.(En función de unidades de medida definidas, solo para grandes progresos en
Gestión Financiera)

3.8.12. Relaciones principales con otros Procesos
Gestión de
Relaciones con
Gestión de el Negocio
la Demanda
Gestión de la
Configuración
CMDB
Gestión de
Cambios
Gestión
Gestión de la
Financiera
Gestión de Estrategia
la Capacidad del Servicio
Gestión de la
Gestión de la Disponibilidad
Continuidad
3.8.13. Entradas
Las Políticas, normas y prácticas definidas por la legislación, los reguladores y
administradores financieros de la empresa
Principios contables generalmente aceptados (GAAP) y sus variaciones locales
Todas las fuentes de datos donde se almacena la información financiera, incluyendo la base
de datos de proveedores, el Sistema de Gestión de la Configuración (CMS), la Estrategia del
Servicio, la cartera de contratos con clientes, cartera de aplicaciones y la cartera de
proyectos
La Estrategia del Servicio ofrece la estructura de los Servicios que serán proporcionados, que
a su vez será la base para el sistema de contabilidad
3.8.14. Salidas
Retorno de la Inversión (ROI)
Análisis de Inversión de Servicios
Análisis de Impacto en el Negocio (BIA)
Cumplimiento de las Leyes Reguladoras
Optimización de Costes del Servicio
Dinámica de Costes Variables (VCD)

3.8.15. Potencial del servicio: Componente de valor añadido, basado en la

percepción de valor del servicio o en el Utilidad y Garantía esperadas del uso
del servicio.
Los Activos del cliente son la base de creación de Valor

Potencial de valor
del servicio
Rendimiento
Potencial
Rendimiento
Activos del Activos
de Nivel de
Cliente del
+ Servicio +
diseñado y Servicio
entregado
Valor potencial Valor de la Provisión

liberado del Servicio
+
Resultado
Realización del valor del
deseado
Servicio
3.8.16. ROI (retorno de la inversión

El ROI es el beneficio neto de una inversión dividido por el valor de los Activos en los que se
invierte. El resultado se aplica a los ingresos de las ventas adicionales o a la eliminación de
coste
El ROI es atrayente debido a que es positivo por sí mismo. El reto se plantea en cuanto el
cálculo del ROI se centra en el corto plazo
La aplicación de ITSM tiene diferentes niveles de ROI, en base al impacto sobre el negocio
Aunque el Servicio puede supeditarse y justificarse directamente a través de imperativos
específicos del negocio, no es fácil poder identificar con rapidez el retorno financiero para
los diferentes aspectos de la Gestión del Servicio. La Gestión del Servicio es una inversión
que las compañías deben realizar antes de obtener ningún retorno de la propia gestión
3.8.16.1. Caso de Negocio:

Un instrumento de toma de negocios, soporte y planificación que prevé las consecuencias
probables de una acción de negocio. (¿Si invierto en este activo, lo recupero y cuándo?).
3.8.16.2. ROI - Pre-Programa:

Presupuestar hoy para aumentar el flujo de
caja de entrada o disminuir el de salida.
3.8.16.3. ROI - Post-Programa:

Técnicas para analizar retroactivamente las inversiones en Gestión del Servicio.

3.8.17. Análisis de Inversiones en Servicios

Gestión Financiera provee el conocimiento y los modelos analíticos en una organización
para analizar el valor esperado y/o retorno de la inversión de una iniciativa, solución,
proyecto o programa de una forma estandarizada y legal
Con un detallado Análisis de la Inversión del Servicio la organización del Proveedor de
Servicios podrá deducir una indicación de valor para el ciclo de vida total de un Servicio
basado en el valor recibido y los costes en los que se ha incurrido durante toda la Vida del
Servicio
En el Análisis de la Inversión del Servicio, será mejor inclinarse por el uso de un inventario
exhaustivo de supuestos en lugar de un conjunto limitado de entradas de alto nivel. Con
esto, se podrá generar una visión más precisa y realista de la inversión que se está
realizando
Es preferible múltiples entradas de bajo nivel que pocas entradas de alto nivel
3.8.18. Análisis de Impacto en el Negocio (BIA)

Un BIA busca identificar los Servicios de negocio más críticos para una compañía a través del
análisis de la gravedad de la interrupción del Servicio traducida en un valor financiero,
combinado con el riesgo operativo
Es una herramienta útil para identificar el coste de la interrupción del Servicio para una
compañía y el valor relativo de un Servicio. Estos dos conceptos no son idénticos
El valor de un Servicio, en relación con otros Servicios en una Cartera de Servicios, puede
que no dependa exclusivamente de las características financieras. El Valor del Servicio se
deriva de características que pueden superar los límites de la Gestión Financiera y
representar aspectos, como la capacidad para finalizar un Servicio
3.8.19. Optimización de Costes del Servicio

Gestión Financiera provee la información clave para Optimización de Costes del Servicio.
Aquí se examina las limitaciones financieras de los componentes del Servicio o de los
modelos de entrega para determinar si deben explorarse alternativas para suministrar un
Servicio de forma diferente para hacerlo más competitivo en cuanto a coste o calidad
Un Servicio típico para Optimización de Costes incluiría aquellos a retirar del Catálogo de
Servicios, porque no se pueden suministrar por más tiempo de forma eficiente
Este análisis financiero de los componentes, limitaciones y valor del Servicio será el centro
de la interacción de Gestión del Servicio con Optimización de Costes del Servicio
3.8.20. Dinámica de Costes Variables (VCD)

Dinámica de Costes Variables (VCD) es un conjunto de análisis y entendimiento de multitud
de variables que inciden en el coste del servicio, el nivel de impacto de esos elementos a la
variabilidad, y los cambios del valor incremental asociados.
Su principal beneficio es que puede servir para identificar un cambio marginal en el coste
unitario que resulte de sumar o restar una o más unidades increméntales de un servicio. Tal
análisis es útil cuando se aplica al análisis de los impactos esperados de eventos como
adquisiciones, desinversiones, cambios en la Cartera de Servicios o alternativas de provisión
de servicios, etc.
El componente analítico de la sensibilidad de la Dinámica de Costes Variables es también
una herramienta analítica compleja debido al número de tipos de supuestos y escenarios
que en muchas ocasiones se formulan alrededor de los componentes de costes variables.

3.8.21. Desafíos
La Información financiera y los modelos de costes que se centran en el coste de la
infraestructura y las aplicaciones en lugar del coste de los Servicios. Esto hará más difícil
comunicar el valor de los Servicios a los clientes
Los Proveedores de Servicios (SP) externos no son capaces de fijar precios de sus Servicios
de forma precisa
Gestión Financiera de TI tiene que cumplir con los estándares y políticas, su plan de cuentas
y la presentación de informes debe ser apropiado para un SP de TI
Si la organización se centra en ahorro de costes en lugar de la optimización de costes,
Gestión Financiera de los Servicios de TI tiene que identificar medidas para reducir costes,
en vez de demostrar retorno de la inversión y valor, resultando que las peticiones de reducir
aún más los costes provocará que los clientes elijan a otro SP, ya que existe una baja
percepción del valor por el SP
Cuando la Gestión Financiera de TI se formalizó por primera vez, puede ser difícil encontrar
los datos financieros
Gestión Financiera de los Servicios de TI se basa en información proporcionada por la
planificación de otros procesos, tanto dentro como fuera de la Gestión de Servicios
3.8.22. Riesgos
Si la introducción de procesos de Gestión Financiera dedicada a un Proveedor de Servicios
(SP) internos, cuando las finanzas están siendo gestionadas a nivel empresarial, puede
parecer innecesario y una pérdida de tiempo y dinero. Pero hay un riesgo real si falta la
Gestión Financiera de Servicios de TI, ya que dará lugar a malas decisiones acerca del tipo y
Nivel de Servicios internos de la empresa
Las organizaciones que no cuentan con procesos adecuados de Gestión Financiera de TI
pueden verse expuestos a las sanciones por incumplimiento de las exigencias legislativas o
reglamentarias
El personal debe estar en disposición de entender el mundo del Proveedor de Servicios (en
este caso TI), así como el mundo de la contabilidad de costes

3.8.23. Resumen de Gestión Financiera de los Servicios de TI

Objetivos - Administrar de forma eficiente los activos y recursos de TI que se utilizan en la provisión de servicios
- Ser capaz de contabilizar completamente el gasto en servicios de TI
- Facilitar la asignación de estos costes a los servicios entregados a la organización del cliente
- Asistir la a dirección en la toma de decisiones relacionadas con la inversión de TI, proporcionando
detalladas justificaciones de negocio para los cambios
Procesos y - Requisitos TI de negocio
Sub-procesos - Plan operacional de TI incluyendo presupuesto: Estos subprocesos tiene un ciclo de planificación
(anual) y operación (Mensual)
o Elaboración y control del presupuesto
 Predecir el dinero requerido para la actividad de TI durante un tiempo
determinado
 Garantizar que el gasto real puede ser comparado en cualquier momento con el
gasto previsto
 Reducir el riesgo de sobre gasto
 Garantizar que los ingresos podrán cubrir los gastos previstos
 Realizar negociaciones periódicas para definir presupuestos (Normalmente
anuales)
- Análisis de Coste (Contabilidad de TI)
o Contabilizar el dinero gastado en la previsión de servicios de TI
o Calcular el coste de proporcionar servicios de TI, tanto a clientes internos como externos
o Realizar análisis de coste-beneficio o de retorno de la inversión (ROI)
o Identificar el coste de los cambios
o Obtener información detallada sobre en qué y por qué razón se ha gastado en servicios TI
o Modelo de costes:
 Costes directos: Son costes que se pueden asociar directamente a una unidad de
negocio o cliente
 Costes indirectos: Son costes asociados a diferentes unidades de negocio o
clientes (Ej.; Staff, servicios globales como el correo electrónico, el acceso
corporativo a Internet)
 Absorbidos
 No Absorbidos: Se asignan normalmente cono Costes indirectos no
absorbidos / (costes directos + costes indirectos absorbidos)
o Unidades de coste: Elementos básicos del recurso por los que los clientes serán
contabilizados
 Deberían elegirse unas unidades de coste que permitan realizar una distribución
justa y sencilla
 Deberían ser entendidos por el cliente
- Imputación de Cargos
o Recuperar del cliente el coste de los servicios de TI proporcionados a éste, de manera justa
y exacta
o Facilitar que la organización de TI funcione como una unidad de negocio, si es necesario en
vez de como una unidad de coste
o Influir en el comportamiento de clientes/ usuarios
o Factores para la política de Cargos
 Determinar el nivel requerido de recuperación del gasto
 Determinar el grado deseado de influir en el comportamiento de clientes/
usuarios
 Diseñar la política de cargos para facilitar la recuperación de los costes en función
del uso
 Usar la política de cargos como un medio para mantener el control del mercado
interno
o Establecimientos de Precios
 Implica:
 Determinar los elementos reconocibles y facturables
 Decidir cómo poner precio: Fijo, variable o combinaciones entre ambos
 Entender la demanda real del servicio
 Determinar los costes directos e indirectos
 Determinar el grado de flexibilidad del precio
 Depende de:
 El nivel de control (monopolio vs. mercado perfecto)
 El poder (Influencia) de las fuerzas del mercado externo
 Aspectos legales, regulaciones, impuestos

Implementación - Documentación: Elaborar procedimientos operativos que detalla el gasto normal diario, semanal,
mensual y anual
- Preparación
o Establecer centros de costes y unidad de costes
o Establecer el registro de datos
o Seleccionar, instalar y probar herramientas software
o Extender la medición
- Generar concienciación
- Guiar el sistema
- Monitorizar el sistema
- Planificar la continuidad de la contabilidad y la imputación de cargos de TI
Beneficios - Ayuda a basar las decisiones sobre los casos de negocios
Indicadores - Los planes y los presupuestos se realizan a tiempo
claves del - Los informes específicos se realizan cuando son necesarios
rendimiento - Las listas de inventarios se mantienen actualizadas
KPIs - Se contabilizan todos los costes
- Las inspecciones anuales se realizan oportunamente
- Se cumplen con los objetivos mensuales, trimestrales y anuales de negocio
- Numero de los cambios requeridos en el sistema de contabilidad de TI
- Exactitud de perfiles o patrones mensuales, trimestrales y anuales
- Numero de cambios realizados sobre el algoritmo de imputación de Cargos
Mejores Practicas - Establecer una clara distinción entre costes e imputación de cargos
- Establecer vínculos con Gestión de la Capacidad, Disponibilidad y Configuración.
- Utilizar la imputación de cargos basada en el cliente
Roles y - Implementar y mantener el proceso de Gestión Financiera de los servicios de TI
responsabilidades - Trabajar con representantes de la dirección de la organización y del dpto. financiero para desarrollar
las políticas de elaboración de presupuestos, contabilidad y cargos de TI
- Ayudar a la organización de TI y sus clientes a desarrollar planes de contabilidad y de inversiones
- Se puede decidir que el titular de alguno de los subprocesos sea el propio dpto. financiero de la
empresa.
Interrelaciones Proceso Entradas Salidas
G. de Incidencias Tiempo empleado en incidencias Coste medio por incidencias
G. de Problema Info. Problemas Calculo de costes
G. del Cambio Info. De cambios RFC, evaluación de costes
G. de la Configuración Información del servicios Monitorización de activos de TI
G. de la Disponibilidad Medidas de disponibilidad Calculo de costes
G. de Nivel de Servicios SLR, SLA Costes de la demanda
G. de la Continuidad Estrategia de ITSCM Calculo de costes
G. de la Capacidad Asignación de la capacidad Calculo de costes

3.9. Gestión de la Demanda (Demand Management)

3.9.1. Objetivos:
Gestionar los requerimientos del Negocio y que sean provistos con un coste justificable.
Adaptar el suministro a la demanda.
Solicitar a Gestión Financiera de TI estudios sobre coste de capacidad usada contra la no
usada para influir en el patrón de comportamiento de los usuarios.
Entender el uso de los servicios por los clientes y como varían a través del Ciclo de Vida.
Controlar el rendimiento (performance) de la Infraestructura de TI y de las aplicaciones y si
es preciso regularla.
Predecir con la máxima precisión la compra de productos y regularlo en la medida de lo
posible.
Se pueden almacenar bienes para su posterior entrega, pero no es posible con los servicios.
La capacidad de producción de los recursos disponibles para un servicio se ajusta de acuerdo
a las previsiones y patrones de la demanda.
El potencial del servicio se convierte en el potencial de funcionamiento de los activos del cliente.
El aumento del potencial de funcionamiento estimula con frecuencia la demanda adicional para el
servicio en términos de la escala o del alcance.
Esta demanda traduce en mayor uso de los activos y de la justificación del servicio para su
mantenimiento y mejoras en curso.
Se reduce la capacidad no usada.
Los costes incurridos en satisfacer la demanda se recuperan del cliente basados en los términos y
condiciones convenidos
Fundamental es estudiar los procesos de negocio del cliente para identificar, registrar y analizar
estos patrones que sirven como la base para crear una Estrategia para la Gestión de Capacidad.
3.9.2. Ámbito
Los patrones de identificación y análisis de la actividad empresarial en relación con los
Servicios
La identificación de perfiles de usuario (UP) y analizar sus patrones de uso de los servicios
La identificación, elaboración y aplicación de medidas para influir en la demanda junto con
Gestión de la Capacidad. También se nombra como “gestión de la demanda". Esto ocurriría
donde la demanda excede la capacidad de Servicio, y el aumento la capacidad no es viable
(por ejemplo, la carga diferencial, incentivos, sanciones). También podría ser en situaciones
en que pone en marcha un nuevo Servicio y desea animar a los usuarios a usarlo más
Además, se podrían utilizar para reducir la demanda en momentos de máxima utilización y
cambiarlo a momentos menos activos, consiguiendo un mejor y más eficiente equilibrio de
los niveles generales de utilización
3.9.3. Valor
El principal valor de la Gestión de la Demanda es lograr un equilibrio entre el coste de un
Servicio y el valor de los resultados de negocio que soporta
Los otros procesos de Estrategia de Servicios definen la relación entre los resultados del
negocio y la inversión requerida para los Servicios, recursos y capacidades
Gestión de la Demanda perfecciona la comprensión de cómo, cuándo y en qué nivel, estos
elementos interactúan entre sí. Esto permite a los ejecutivos de la organización evaluar la
inversión real y necesaria para lograr resultados de negocio a diferentes niveles de actividad
El personal de TI tiene que distinguir Gestión de la Demanda y Gestión de la Capacidad

3.9.4. Disparadores
Petición de un cliente para un Servicio nuevo o cambiar un Servicio existente. Esto se iniciará
a través de los procesos de Gestión de Relaciones con el Negocio y Gestión de la Estrategia
del Servicio
Un nuevo Servicio se crea para satisfacer una iniciativa estratégica, que será iniciado a través
de la Gestión de la Estrategia del Servicio
Un modelo de Servicio ya definido, así como los patrones de la actividad del negocio (PBA)
y/o perfiles de usuario (UP)
Las tasas de utilización están causando problemas potenciales de rendimiento, o un
incumplimiento de un Acuerdo de Nivel de Servicio (SLA)
Se ha producido una excepción para pronosticar Patrones de la Actividad del Negocio (PBA)
3.9.5. Entradas
Iniciativa de crear un nuevo Servicio, o cambiar un Servicio existente, bien desde la Gestión
de la Cartera o de Gestión de Cambios
Los Modelos de Servicio tienen que ser validados y los Patrones de la Actividad del Negocio
(PBA) asociados a cada modelo tendrán que ser definidos
La cartera de clientes, Cartera de Servicios y la cartera de contratos con el cliente, que
incluyen información sobre la oferta y la demanda de Servicios
Los modelos de carga serán evaluado para asegurar que sub o sobre carga de trabajo no se
produce en los Proveedores de Servicios internos
Los Servicios a entregar tendrán que ser validados para asegurar que los clientes los
perciben y los utilizan como se definieron
Las oportunidades de mejora de Servicio y los planes, deben ser evaluados en términos de
su impacto en la demanda
3.9.6. Salidas
Los perfiles de usuario (UP)
Los patrones de la actividad del negocio (PBA) serán formalmente documentados e incluidos
en la Cartera de Servicios y de clientes
Las Políticas para la Gestión de la Demanda, cuando los recursos sean más utilizados
Las políticas de cómo hacer frente a situaciones en las que la utilización del Servicio es
mayor o menor de lo esperado por el cliente
La documentación de las opciones de ofertas diferenciadas que se pueden utilizar para crear
Paquetes de Servicios (SP)
3.9.7. Gestión de la Demanda basada en actividades

Los procesos de negocio son la fuente primaria de demanda de servicios. Los Patrones de Actividad
del Negocio (PBA) influencian en los patrones de la demanda considerados por Gestión de
Proveedores.
Es muy importante estudiar el negocio del cliente para identificar, para analizar y para codificar tales
patrones para proporcionar la suficiente base para la Gestión de la Demanda.
Visualice la actividad económica del cliente y los planes en términos de demanda para los servicios
de soporte.
Por ejemplo, el cumplimiento de una orden de compra (actividad económica) puede dar lugar a un
sistema de peticiones (demanda) generadas por el proceso de Orden-a-Efectivo (negocio proceso
del cliente).

Analizar el seguimiento de los patrones de la actividad del proceso de negocio permite predecir la
demanda para los servicios en el Catálogo de Servicios que apoyan el proceso.
Es también posible predecir la demanda para los activos subyacentes del servicio que soportan esos
servicios. Cada unidad adicional de demanda generada por actividad económica se asigna a una
unidad de capacidad de servicio. Los patrones de la demanda ocurren en - Estrategia de Servicio -en
los niveles múltiples
Algunas de las ventajas para analizar PBA están bajo la forma de entradas para mantener funciones
y procesos de gestión tales como:
El Diseño del Servicio puede entonces optimizar diseños para adaptarse a patrones de la
demanda
El Catálogo de Servicios puede trazar patrones de la demanda para incluir estos servicios
La Gestión de la Cartera de Servicios puede aprobar inversiones en capacidad adicional,
nuevos servicios, o cambios a los servicios
La Transición del Servicio puede ajustar la asignación de recursos y su previsión
La Operación del Servicio puede identificar oportunidades de consolidar la demanda
La Gestión Financiera puede aprobar incentivos convenientes para influenciar en la
demanda
3.9.8. Relaciones con otros Procesos
Gestión de
Relaciones con
Gestión Financiera el Negocio
de Servicios de TI
Gestión de la
Configuración
CMDB
Gestión de
Cambios
Gestión de la
Gestión de la
Demanda
Gestión de Estrategia
la Capacidad del Servicio
Gestión de la
Continuidad

3.9.9. Modelado de la Demanda

Una inadecuada gestión de la demanda del servicio genera costes y riesgos, por lo que se debe
combinar información financiera orientada a servicios con factores de oferta y demanda para
anticiparse al uso que hará el negocio y perfilar los requisitos de TI
3.9.10. Rol en Gestión de la Demanda

Gestor de la Demanda
Es la función o rol que crea y administra incentivos y penalizaciones en el esquema.
(Los esquemas son requerimientos que influyen en la demanda).
Ayuda a responder a los cambios de los PBA (Patterns of Business Activity)
La Gestión de la Demanda optimiza y racionaliza el uso de los recursos de TI. Reduce el riesgo de no-
disponibilidad a través de:
Ayuda en la creación de los SLAs
Pronósticos.
Planeamientos.
Equilibrar la oferta y la demanda.
Asegura la calidad del servicio manteniendo la suficiente Capacidad.
Gestiona costes y crea valor reduciendo el exceso de Capacidad
3.9.11. Desafíos
La disponibilidad de información sobre las actividades de negocio si Gestión de la Demanda
no está incluido en el global de las necesidades y tiene que ser recogidas por separado
Los clientes pueden tener dificultades para romper algunas actividades que quizás si tengan
sentido para el Proveedor de Servicios, ya que no son necesarias para el cliente
Gestión de Relaciones con el Negocio (BRM) debe ser capaz de ayudar en la toma de
decisiones del cliente
La falta del proceso formal de la Cartera de Servicios. Esto dificulta que se entiendan los
requerimientos del negocio y su valor relativo
3.9.12. Riesgos
La falta de la información de Gestión de la Configuración y Activos del Servicio, lo que hace
difícil estimar el impacto de los cambios en la demanda, sobre la infraestructura del
Proveedor de Servicios (SP) y/o sus aplicaciones
Gestión de Nivel de Servicio (SLM) no es capaz de obtener el compromiso de los niveles de
utilización mínima o máxima, por lo que es difícil comprometer dichos niveles. Esto resultará
en niveles más altos

3.10.Gestión de la Cartera de Servicios (SPM)

3.10.1. Gestión del Portafolio de Servicios (SPM)
Es un método dinámico de destreza para gobernar las inversiones en Gestión de Servicios a lo
largo de la vida de la empresa para obtener valor y representa las oportunidades y disposición de
un proveedor de servicio a los clientes y el mercado.
Se divide en tres subconjuntos de servicio:
El Catálogo de Servicios
El Flujo de Creación de Servicios
Los Servicios Retirados
Es un proceso dinámico y continuo que incluye los siguientes marcos de trabajo:
Definición: Inventario de los Servicios, asegura los proyectos del Negocio y establece la lista
de Servicios. Puede ser tan amplio como decir “¿Cuáles son TODOS los servicios que nos
gustaría tener si no nos los impusieran los clientes?" (éstos pueden ser todos los posibles
de nuestra capacidad). Recoge datos de Servicios Existentes y Propuestos.
Análisis: Maximiza el valor del portafolio alineando, priorizando y equilibrando la oferta y la
demanda. ¿Cuáles son los objetivos?
Aprobación: Finaliza el portafolio propuesto, autoriza los recursos y los Servicios.
Categorizan las salidas de STATUS para todos los Servicios.
Retención
Sustitución
Racionalización
Refactorización
Renovación
Retirada
Institución (Charter): Comunica decisiones, asigna recursos y servicios para empezar y
documentación de servicios.
Service Portfolio Management (SPM)
Es un método dinámico de destreza para gobernar las inversiones en
Gestión de Servicios a lo largo de la vida de la empresa para obtener valor.
Estrategia del
Servicio
Caso de Negocio
DEFINIR Inventarios
Propuestas de valor
ANALIZAR Priorización
Cartera de Servicios
APROBAR Autorización
Asignación de
INSTITUIR recursos
Comunicación

Service Portfolio Management (SPM)

Catálogo de Servicios
Servicio de Pipeline
Catálogo de
Terceros
Espacio de
Mercado
Servicios
Transición retirados
de Servicio
Operación de
Servicio
Diseño de
Clientes Servicio
CONJUNTO DE RECURSOS COMUNES
Cliente A Cliente B
Service Knowledge
3 6
2 NEGOCIO 5
Management System
Service Portafolio
Unidad de Unidad de
Negocio 1 Negocio 4
SLRs EF Servicios Service Pipeline

SLAs A B CD TI
Transición Operación
de Servicio de Servicio
TI Service
Catalogue
Diseño de Servicio
Estrategia
de Servicio PROCESOS
SLM SCM
Mejora del Arquitectura
Suministradores
Servicio
Seguridad
Disponibilidad
Equipo de Continuidad Suministradores
Métricas
Soporte Capacidad
Service Portfolio (Cartera de Servicios) es el conjunto de la lista de servicios visibles o no al cliente y

a disposición de los mismos. Consiste en los servicios actualmente activos en la fase de Operación
del Servicio y los aprobados para ser ofrecidos a los clientes actuales o futuros.

El Service Portfolio (Cartera de Servicios) tiene tres componentes, como hemos comentado y que
son:
3.10.2. Catálogo de Servicios

Es la expresión de la capacidad operacional del proveedor en el contexto de salida al mercado. Tiene
dos aspectos: El Catálogo de Servicios del Negocio y el Catálogo de Servicios Técnico.
3.10.3. Canal de Entrada ( Service Pipeline )

También llamado Flujo de Creación de Servicios, contiene todos los servicios de TI que están
desarrollándose. Estos Servicios pasarán a la fase de Operación del Servicio y están en la fase de
Diseño de Servicios o Transición del Servicio. Es el crecimiento anticipado y nos dice la salud del
negocio.
3.10.4. Servicios Retirados

Aquellos obsoletos y que han rebasado la Operación del Servicio en su día. Ya no están en
producción. Y seguramente aún se les da soporte.
3.10.5. Objetivos de la Gestión de Cartera

La Gestión de la Cartera de Servicios se dirige a crear el máximo el valor al manejar riesgos y costes.
La realización del valor se deriva de mejores experiencias del suministro de servicios y del cliente.
Los gestores de servicios pueden mejor entender los requisitos de calidad y costes
El PRINCIPAL propósito del Service Portfolio es describir los Servicios en términos de VALOR AL
NEGOCIO.

3.10.6. Valor al Negocio

El valor se deriva de mejores experiencias del suministro de servicios al cliente y comienza con los
servicios de documentación.
Service Portfolio Management (SPM) demuestra valor con la capacidad de anticipar el cambio y la
capacidad de mantener trazabilidad de la estrategia y el planeamiento.
Ayuda a responder a:
¿Qué servicios deberíamos ofrecer y a quién?

¿Qué oportunidades hay en el mercado?
¿Cómo serían asignados nuestros recursos y capacidades?
¿Por qué los clientes compran nuestros servicios?
¿Cuáles son los modelos de precio y facturación?
¿Cuáles son nuestras fortalezas y debilidades, prioridades y riesgos?
¿Cómo se deben asignar nuestros recursos y capacidades?
Las organizaciones que se embarcan en orientarse en proveer servicios tienen una tendencia a verla
como serie de programas tácticos. Las organizaciones acometen con frecuencia industrializar los
resultados del servicio. El impulso es poner en marcha iniciativas cambios en la organización o
reajuste de sus procesos de negocio. Mientras que éstos son elementos importantes para su
cumplimiento, hay un orden que los grupos de interés deben de tener en cuenta. Mientras que este
orden no es absoluto sí que debe responde a dos propósitos.
Primero, advertirnos contra pasos en falso tales como ejecución de diseños de organización antes de
saber qué servicios ofrecer, o realizando una selección de la herramienta antes de saber si es la
óptima.
En segundo lugar, señalar la necesidad de una lista de servicios, con los servicios a entregar a
Clientes dentro del espacio de mercado más vital con todos sus estudios sobre riesgos y pérdidas
para conducir estrategias del negocio y manejar las inversiones.
La lista del espacio de mercado y del servicio en la etapa de la Estrategia de Servicio conduce a la
eficiencia a través del ciclo de vida, haciéndola valiosa en:
La toma de decisiones en términos de un plan apropiado de la Transición del

Servicio.
Y los requisitos de recursos durante las Operaciones de Servicio necesarias
para el Negocio.
3.10.7. Ámbito
El alcance es todos los Servicios que un Proveedor de Servicios (SP) tiene previsto entregar,
los que actualmente entrega y los que han sido retirados del Servicio
El principal empeño de la Cartera de Servicios es si el SP es capaz de generar valor, a partir
de los Servicios, y por lo tanto hará un seguimiento de las inversiones en Servicios y
compararlos con los resultados de negocio deseados
Los SP internos tendrán que trabajar con las unidades de negocio para enlazar cada Servicio
con los resultados de negocio, antes de que se puede comparar el Retorno de la Inversión
(ROI)

Los SP externos tienden a evaluar el valor de manera más directa, ya que cada Servicio tiene
que ser capaz de generar ingresos directamente, o Servicios de apoyo a la generación de
ingresos
Gestión de la Cartera de Servicios evalúa el valor de los Servicios, a lo largo de su Ciclo de
Vida, y debe ser capaz de comparar los nuevos Servicios que se ofrecen con los sustituidos y
retirados
3.10.8. Políticas y principios
Políticas, Principios y Conceptos Básicos
Canal de Catálogo de Servicios
Entrada Servicios Retirados
CMS
Sistema Información
Cartera Cartera Cartera Cartera Contratos y
Clientes Aplicaciones Contratos Proyectos Suministradores CMDB
3.10.9. Propietario del Proceso

Es la función clave dentro de la Gestión de la Cartera de Servicios
Gestiona los Servicios como un producto a través del Ciclo de Vida desarrollándolo y manteniéndolo.
Es el propietario de la Cartera de Servicios y coordina el mismo.
Trabaja con el Gestor de Relaciones con el Cliente enfocado al Portafolio del
Cliente.
Evalúa las nuevas oportunidades de Negocio, modelos de operaciones,
tecnologías y necesidades emergentes de los clientes.
Asigna los recursos y lista los servicios de acuerdo a los presupuestos del cliente.
Promueve nuevos servicios para el Diseño de Servicio y los que están acabados ya
en la fase de Transición del Servicio.
3.10.10. El desarrollo de una organización

Las empresas se organizan de varias maneras. Los factores externos influyen sobre la Estrategia del
Servicio y se caracterizan por el estilo de gestión dominante que en un momento determinado
necesitan.
ITIL ®describe cinco fases en el desarrollo de una organización

3.10.11. Modelos de fases organizacionales

1 – Network o malla: Enfocada a la rápida provisión de servicios y sobre la marcha. Cuando
la demanda se incremente esta fase ya no es efectiva.
2 – Dirigido: Ya hay un equipo de directores. Comunicación más formal y hay procesos
básicos. Si se crece más hay que delegar.
3 – Delegado: Se trata de reducir costes y mejorar servicios. Hay que delegar funciones y se
tiene la impresión de perder el control.
4 – Coordinación: Se usan sistemas formales. La centralización de funciones técnicas y la
descentralización de la Gestión de Servicios trata de mejorar el tiempo de respuesta a las
demandas del mercado
5 –Colaboración: Se mejora la cooperación con el negocio. Se usa como estructura matricial
minimizando las barreras. Equipos líderes en el conocimiento de habilidades de los
productos y clientes
3.10.12. De grupo de trabajo a departamento

Si un grupo crece hasta departamento, éstos se pueden dividir según distintos atributos
Estructura Descripción Consideraciones estratégicas
básica
Función La organización por funciones es la Especialización
mejor forma de especialización Desarrollo de estándares
Pequeña escala
Producto La organización por productos es una Orientación al producto
buena opción para organizaciones Excelentes conocimientos del producto
centradas en productos nuevos y
variados
Mercado o La organización por mercados o clientes Servicio exclusivo para cada segmento
cliente permite diferenciarse con más Servicio al cliente
conocimientos y más capacidad para Elevado consumo
responder a los deseos del cliente Servicio rápido
Geografía La organización geográfica es una buena Servicios in situ
opción cuando se prestan servicios en Proximidad a clientes en soporte y
zonas muy próximas. Minimiza costes de prestación
viaje y distribución y aprovecha el La organización se percibe como
conocimiento de la zona empresa local
Proceso La organización por procesos es la mejor Ciclos de procesos breves
opción cuando se ejecutan procesos de Excelencia de procesos
principio a fin
Una nueva estrategia ha sido concebida, o una estrategia existente cambia
Gestión de Relaciones con el Negocio (BRM) recibe una solicitud de un nuevo Servicio o
cambio a un Servicio existente, con oportunidades de mejora del Servicio
Comentarios de los equipos de Transición sobre desviaciones del Servicio durante la etapa
del proceso de entrega
Gestión de Nivel de Servicio identifica que un Servicio no está cumpliendo con los resultados
esperados

3.10.14. Entradas
Planes de Estrategia nuevos o modificados
Las solicitudes, sugerencias o quejas del Cliente
Actualizaciones de proyectos de Servicios en la etapa de entrega
Oportunidades de mejora de servicios
Informes financieros
3.10.15. Salidas
Actualizaciones de la Estrategia del Servicio
Informes de estado de un nuevo o cambiado Servicio
Informes de inversiones en Servicios y Retorno de la Inversión (ROI)
Identificación de riesgos estratégicos
3.10.16. Desafíos y riesgos

La falta de acceso a la información del negocio de los clientes, lo que impedirá la
comprensión de los resultados de negocio deseados
La ausencia de un enfoque de gestión de proyectos formales. Esto significa que es más difícil
los cargos (Charging) por Servicios y realizar un seguimiento a través de las fases de Diseño y
La ausencia de una “cartera de proyectos”, que hacen que sea difícil evaluar el impacto de
las nuevas iniciativas de nuevos Servicios o cambios propuestos en los Servicios
La ausencia de una “cartera de clientes” y “cartera de contratos”, lo que hará que sea difícil
identificar los objetivos, uso y retorno de inversiones de los Servicios
Una “Cartera de Servicios”, que sólo se centra en los aspectos del Proveedor de Servicios
(SP)
La falta de un proceso de Gestión de Cambios formal, que puede ser utilizado para controlar
la introducción de nuevos Servicios, o para manejar los cambios a los Servicios existentes
3.10.17. Gestión de la Información por el Gestor de la Cartera de

Servicios
La cartera de proyectos para gestionar los Servicios que se han encargados y están
diseñados para ser construidos
La cartera de aplicaciones que permite a los Servicios gestionar la cartera y entender la
relación entre las aplicaciones y Servicios
La cartera de clientes y la cartera de contratos alineados con la Cartera de Servicios, que
permite a la Gestión de la Cartera de Servicios (SPM) entender al cliente en sus requisitos,
los Servicios que han sido diseñados para cumplirlos, y los acuerdos que se han hecho para
entregarlos
Modelos de Servicio que permiten a SPM comprender la composición y la dinámica de un
Servicio antes de que se diseñe y construya. Los Modelos de Servicio también indican que un
Servicio puede aprovechar las inversiones existentes
La fase de la Estrategia del Servicio proporciona un marco de las oportunidades previstas,
limitaciones, los objetivos de negocio deseados y los resultados
El Sistema de Gestión de Configuración (CMS) proporciona datos e información para apoyar
el desarrollo y evaluación de modelos de Servicio

Gestión Validación
Gestión de Financiera y pruebas
la Demanda de TI del Servicio
Gestión de la
Configuración
CMS
Gestión de
Seguridad de la
Información Gestión del
Gestión de la
Cambio
Cartera de
Servicios
Estrategia
del Servicio Gestión de la
Capacidad
Gestión de
Gestión del Nivel Relaciones con
Gestión de la
de Servicios el Negocio
Continuidad

3.11.Gestión de Relaciones con el Negocio

3.11.1. Propósito
El Gestor de Relaciones con el Negocio (BRM) es el responsable de identificar la combinación más
adecuada de Líneas de Servicio (LOS) y Paquetes de Nivel de Servicio (SLP) para cada resultado del
cliente con el que esté relacionado.
Los BRMs relacionan los resultados que quieren los clientes con el Perfil del Usuario (UP) a soportar
Cada (UP) se empareja después con el Paquete de Nivel de Servicio (SLP) adecuado para crear una
oferta de Servicios personalizada para cada resultado del cliente
Los BRMs representan a los clientes, y trabajan estrechamente con los Propietario del Servicio para
asegurar que el Catálogo de Servicios tenga la combinación adecuada de LOS y SLPs para satisfacer
las necesidades de la Cartera de Clientes
3.11.2. Conceptos Básicos

Un Paquete de Servicio (SP): Es una descripción detallada de un servicio TI que está
disponible para entregarse a un cliente. Incluye un Paquete a Nivel de Servicio y uno o más
Servicios Esenciales y Servicios Añadidos.
Un Servicio Esencial (ES): Representa el valor que el cliente quiere y por el que está
dispuesto a pagar.
Un Paquete de Servicio Principal (Core Service Package- CSP): Descripción detallada de un
Servicio Esencial que puede estar incluido en varios SLPs.
Un Paquete de Servicios de Soporte, que puede estar orientados a dar continuidad al
servicio o a mejorar su propuesta de valor. Representan las características que diferencian
nuestro producto de otros similares ofrecidos por la competencia.
Un Paquete a Nivel de Servicio (SLP): Nivel definido de utilidad y garantía para un
determinado Paquete de Servicios (SP). Diseñado para un determinado Patrón de Actividad
de Negocio (PBA).
Una Línea de Servicio (LOS): Servicio Esencial o de Soporte con múltiples SLPs. Controlado
por un Product Manager y cada SLP está diseñado para un segmento muy concreto del
mercado
3.11.3. Ámbito
Los resultados de negocio que el cliente quiere lograr
Los Servicios que se ofrecen actualmente a los clientes, y la forma en que son utilizados por
el cliente
La forma en que los Servicios se ofrecen “ya”, incluyendo quién es el responsable de los
Servicios, los niveles de Servicio acordados, la calidad de los Servicios prestados y los
cambios que se prevén
Tendencias de la tecnología que podrían afectar a los actuales Servicios del cliente, y la
naturaleza de los posibles efectos
Los niveles de satisfacción del cliente, y planes de acción que se ponen en marcha para
eliminar las causas de la insatisfacción
¿Cómo optimizar los Servicios para el futuro?
¿Cómo el Proveedor de Servicios está representado con el cliente?
El personal de TI tiene que saber distinguir BRM de SLM

3.11.4. BRM vs SLM
Gestión de Relaciones con el Gestión de Nivel de Servicio

Negocio
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 clientes y asegurar que todos los procesos de
sus necesidades de negocio. gestión de Servicios, acuerdos de nivel
Para identificar las necesidades del operativo (OLAs) y de los contratos (UCs) que
cliente (utilidad y garantía) y asegurarse sustentan, son apropiados para los objetivos
de que el Proveedor de Servicios es de Nivel de Servicio acordado
capaz 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 nuevos
Servicios del SP son ofrecidos para y existentes, y si el Proveedor de Servicios es
satisfacer las necesidades de los clientes capaz de cumplir esos acuerdos
Primera La satisfacción del cliente, también una Alcanzar los niveles acordados de
medida mejora en la intención del cliente de Servicio (que conduce a la
utilizar mejor y pagar por el Servicio. satisfacción del cliente)
Otro indicador es si los clientes están
dispuestos a recomendar el Servicio a
otros (potenciales) clientes
3.11.5. Valor
El valor de Gestión de Relación con el Negocio (BRM) está en la capacidad del Proveedor de
Servicios (SP) para articular y satisfacer las necesidades empresariales de sus clientes
BRM crea un foro para la comunicación con sus clientes. Esto permite a BRM lograr una
mejor alineación y la integración de Servicios en el futuro, así como para lograr los
resultados de negocio actual
Con la comunicación hay una mayor comprensión por parte del SP del negocio de sus
clientes, y una mayor comprensión por parte del cliente de las capacidades del SP y Servicios
que recibe
Ayuda a establecer las expectativas de los clientes, y pone un rostro humano en el Servicio
El enfoque en la satisfacción del cliente permite que el SP y el cliente midan por igual la
eficacia de los objetivos de negocio, y si se están cumpliendo
3.11.6. Políticas y Principios

El proceso de Gestión de Relaciones con el Negocio (BRM) a menudo se confunde con el
papel de GESTOR de relaciones con el negocio. Esto es así porque el papel de BRM es de alto
perfil y muchos clientes identifican las actividades del proceso con la PERSONA que juega el
papel
El papel de los BRM también pueden causar confusión sobre el proceso. Esto se debe a que
BRM representan a veces a otros procesos cuando participan en la gestión de relaciones
comerciales. Ejemplo: Cuando se obtienen la información sobre los requisitos del cliente y
los resultados del negocio, el BRM también está proporcionando entradas a Gestión de la
Estrategia del Servicio, Gestión de la Demanda y Gestión de la Capacidad.
Por ello, puede parecer confuso en cuanto a que el proceso está ejecutando el papel de
gestión de relaciones comerciales

Se ha iniciado un nuevo Servicio, o un cambio de un Servicio existente
Una nueva oportunidad se ha identificado
Un Servicio ha sido autorizado por Gestión de la Estrategia del Servicio
El cliente solicita consejo o sugerencia
Las quejas del cliente
Una reunión planificada con el cliente
Una encuesta de satisfacción del cliente ha sido programada
3.11.8. Entradas
Las peticiones del cliente, escaladas o cumplidas
Las quejas y elogios del cliente sobre los Servicios de TI
Siempre que sea posible, la estrategia de negocio del cliente
La Estrategia del Servicio
La cartera de proyectos para asegurar que los requisitos se recogen en el momento
oportuno
Los Acuerdos de Nivel de Servicio (SLA)
Las solicitudes de cambio (RFC)
Los Patrones de Actividad del Negocio (PBA) y los perfiles de usuario (UP) por Gestión de la
Demanda deben ser validados a través de los BRM
3.11.9. Salidas
Las definiciones de los Interesados
Definición de los resultados de negocio
Acuerdos para financiar (interno) o pagar (externos) Servicios
La cartera de clientes
Los requisitos de la Estrategia del Servicio, del Diseño y Transición
Las encuestas de satisfacción del cliente, y los resultados publicados de las mismas
Los horarios de actividad de los clientes en las actividades de procesos de Servicio para
procesos de negocio
Calendario de eventos de capacitación y sensibilización
Informes sobre la percepción del cliente del rendimiento del Servicio
3.11.10. Desafíos
Si la Gestión de Relaciones con el Negocio (BRM) se intenta simplemente como un medio de
trabajo en los niveles de satisfacción del cliente, es probable que falle. BRM debe participar
en la definición de los Servicios, y el seguimiento de su entrega, de acuerdo a los niveles
acordados. Ellos son más que "un escaparate“, hacen que TI muestre un aspecto amigable al
cliente
Si anteriormente un Servicio fue malo, puede que sea difícil para BRM funcionar con
eficacia, ya que tendrá que lidiar con la falta de credibilidad
La confusión entre el papel del GESTOR de relaciones comerciales y el proceso de Gestión de
Relaciones con el Negocio
BRM son a menudo necesarios para ejecutar las actividades de otros procesos, simplemente
debido a su posición de cara al cliente. Esto no hace que esas actividades, sean parte del
proceso de negocio de gestión de relaciones comerciales

3.11.11. Riesgos
Debido a que Gestión de Relaciones con el Negocio (BRM) está muy conexo con otros
procesos, la confusión sobre los límites entre estos procesos significa que existe la
posibilidad de duplicación de la actividad, la interferencia o actividades descuidadas
Ejemplo: Es negativo que varios procesos traten de escalar el mismo tema , como es un
incidente; porque el Gestor de Incidentes se verá inundado con llamadas del GESTOR de
relaciones comerciales, Gestión de Nivel de Servicio, etc., que en les impide ser capaces de
re solucionar el incidente. Es importante que estos límites están claramente definidos
Si hay una desconexión entre los procesos de cara al cliente, como BRMs, y los que se
centran más en la tecnología, tal como la Gestión de la Capacidad, es probable que el
Proveedor de Servicios sea ineficaz. Ambos son críticos para el éxito, y tienen que estar
debidamente integrados

3.12.Estrategia del Servicio - Interfaz con otras fases del Ciclo de

Vida
Implementación de estrategia
Diseño
Requerimientos de de Servicio
Diseño de Servicio
Continual
Estrategia Transición Service
de Servicio de Servicio Improvement
Requerimientos de
Service
Catalogue
Service
Portfolio
Operación
Requerimientos de
de Servicio
3.12.1. Edward Deming (PDCA)

• Edward Deming (1900-1993)
• En 1947 Japón buscaba reactivar su economía ya que

esta quedó muy dañada en la II guerra mundial, por lo
tanto estaban abiertos a varias opiniones para lograrlo.
Es en esta época cuando Deming llega a Japón y les
instruye sobre la importancia de la calidad y desarrolla
el concepto de Gestión de Calidad Total (TQM).
• Con el tiempo los Estados Unidos se dio cuenta de los

efectos de incluir la calidad en su producción,
convirtiendo a Deming en el asesor y conferencista
más buscado por grandes empresas americanas. Por
su influencia se creó el premio Deming, reconocido
internacionalmente como premio a la calidad
empresarial.

3.12.2. Estrategia del Servicio & Ciclo de Deming
Mejora continua paso a paso no tiene fin
Alineamiento
TI
Optimo
Nivel de Madurez
PLAN HACER
Gestionado
Definido ACTUAR REVISAR
Repetible
Inicial Consolidación de Nivel

Mejora Continua Paso a Paso ISO 20000
y aseguramiento ISO 900X
de la calidad
Escala de Tiempo
PDCA
LO PREPARO
Requerimientos de
Diseño de Servicio
LO
LO PIENSO LO PRUEBO MEJORO
Requerimientos de
LO HAGO
Requerimientos de

3.12.3. Riesgos
Es un resultado incierto, o una oportunidad positiva o una amenaza negativa
Identificar
Definir un los riesgos
Marco de trabajo
Identificar a los
Integrar y probables responsables
revisar de los riesgos
Evaluar
Comprobar la
los riesgos
efectividad
Definir niveles
Implementar aceptables de riesgo
respuestas
Identificar respuestas
adecuadas a
los riesgos
GESTIÓN DEL RIESGO ANALISIS DEL RIESGO

Riesgos de contrato: Los riesgos de que el Proveedor de Servicios haga imposible los acuerdos
contractuales son riesgos estratégicos y no solo es una amenaza para la producción sino una falta de
confianza en el futuro.
No haber consultado, negociado con OLAs y asegurado con los equipos de Gestión Técnica y
Operaciones de Servicio, antes de concluir en los SLAs los precios, garantías y las políticas de
cancelación.
Riesgos de diseño: Los clientes esperan que los servicios se concreten en rendimiento de los activos.
Desde el punto de vista del cliente es una Funcionalidad. Un diseño deficiente corre el riesgo de que
los servicios no den el resultado esperado.
Riesgos operativos: Siempre existirá el riesgo operativo desde el punto de vista de la Gestión de
Servicios. Pueden ser para las unidades de Negocio o de Servicio.
Riesgos de mercado: Una buena Gestión de Servicios disminuye los riesgos competitivos al poder
aumentar la escala y el alcance de la demanda. Se pueden reducir a:
Riesgos y contingencias que definieran la probabilidad de que un conjunto
de alternativas negativas coincidirían por incertidumbres en sus
operaciones.
Diferenciación – Los Proveedores de Servicios (SPs) deben ofrecer servicios
activos importantes que otros no pueden proporcionar.
Consolidación – La consolidación de la demanda reduce riesgos financieros
para los clientes y los SPs.

Diseño del Servicio .4

4.1. Diseño del Servicio en el Ciclo de Vida
El diseño de apropiados nuevos o modificados Servicios de TI incluyendo sus arquitecturas, los
procesos, las políticas, las métricas y documentación para su paso a un entorno de producción.
4.1.1. Sobre la Definición:

Traslada los planes de Estrategia de Servicios y objetivos y crea el diseño y especificaciones
para ejecutarlos a través del Transición del Servicio y de Operación del Servicio.
Proporciona la dirección para combinar la infraestructura, usos, sistemas, y procesos junto
con proveedores y socios, para presentar ofertas de servicios factibles de su cumplimiento.
Es el diseño y desarrollo de servicios y de sus procesos para la Gestión de Servicios.
Dicho de otra manera:
El nuevo servicio se añade desde la fase del concepto de Cartera de Servicios y se debe
mantener actualizado durante todo el proceso.
Los Requisitos a Nivel de Servicio (SLR) tienen que estar claros antes de la entrega del
servicio.
La Gestión de la Capacidad puede modelar los requisitos tomando como base las SLRs.
La Gestión Financiera debe participar si se desea un mayor nivel de soporte.
Combinar la infraestructura, las aplicaciones, los sistemas, los procesos nuestros de TI, del
cliente y de proveedores de terceros para presentar una oferta factible.
Antes hay que hacer un Análisis de Impacto en el Negocio (BIA) y evaluación sobre Gestión
de Continuidad del Servicio de TI (ITSCM), Gestión de la Disponibilidad y Gestión de la
Capacidad.
El Centro de Servicio al Usuario debe contribuir a acelerar la entrega de los nuevos
servicios o modificados.
Si se van a hacer adquisiciones debe participar Gestión de Suministradores.

4.1.2. Objetivos
Su objetivo es el diseño de nuevos o modificados servicios para su paso a un entorno de
producción.
El libro del Diseño del Servicio proporciona la dirección en el diseño y el desarrollo de servicios y de
la gestión de los procesos.
Diseñar servicios para satisfacer objetivos de negocio, basándose en los requisitos de
calidad, conformidad, riesgo y seguridad, entregando soluciones de TI más eficaces y
eficientes alineados con las necesidades del negocio
Identificar y gestionar riesgos para que puedan retirarse o mitigarse antes de que los
servicios pasen a estar activos
Diseñar métodos de medida y métricas para evaluar la efectividad y eficiencia de los
procesos de diseño y de sus entregables
Generar y mantener planes, procesos, políticas, arquitecturas, marcos de trabajo y
documentos de TI para el diseño de soluciones de TI de calidad, para satisfacer las
necesidades del negocio actuales y futuras acordadas y que sean rentables. Sin embargo,
la mejora continua debe ser incorporada en todas las actividades del Diseño de los
Servicios para garantizar que las soluciones aún más eficientes en el tiempo
Incluye los principios y los métodos de diseño para convertir los objetivos estratégicos en
la Cartera de Servicios y en Activos del Servicio.
También proporciona la dirección en el desarrollo de las capacidades del diseño para la
Gestión de Servicios.
Diseño del Servicio NO está limitado a los nuevos servicios. Incluye los cambios y las mejoras
requeridas para mantener o para aumentar valor a los clientes durante el Ciclo de Vida de los
Servicios, considerando:
La continuidad de los Servicios,

Conformidad a los estándares y a las regulaciones.
Logro de los porcentajes de disponibilidad.
Debe adoptar un acercamiento holístico:
Para todos los aspectos de cada área.

Para asegurar la consistencia e integración.
Dentro de todas las actividades y procesos.
A través de toda la tecnología.
Para proporcionar todo lo relacionado con el mercado de inicio a fin en cuanto a
funcionalidad y calidad.
4.1.3. La Clave:
Es importante que un acercamiento holístico a todos los aspectos del diseño sea adoptado y que al
cambiar o modificar elementos individuales cualquiera de los del diseño sean considerados en todo
el resto de los aspectos.
Así, cuando se diseña, no debe ser hecho en el aislamiento, debe también considerarse el impacto
en el servicio y todos sus CIs.
Esto asegurará de que no sólo los elementos funcionales sean tratados por el Diseño, sino también
que se traten como una parte fundamental del Diseño y no solo que afecte a una parte.


Con un buen Diseño de Servicio será posible entregar la calidad, servicios rentables y
asegurarse de que se están resolviendo los requisitos del Negocio con los beneficios de:
Reducir el Total Coste de Propiedad (TCO).

Mejorar la calidad de los servicios.
Mejorar la consistencia del Servicio.
Más facilidad de implementar nuevos o modificados Servicios.
Mejorar el apego del Servicio con el Negocio.
Más efectivo rendimiento de los Servicios.
Mejorar el Gobierno de TI.
Más efectiva Gestión de Servicios y procesos TI.
Mejorar la información y la toma de decisiones.
Para obtener los mejores beneficios
Determinar los roles de los procesos y de la gente

Implementar las herramientas para automatizar los procesos
Facilitar los roles a la gente y sus tareas específicas
Desarrollar un modelo de las áreas “de extremo a extremo” con todas las ayudas de la tecnología
para minimizar las lagunas, disminuir los “silos” y mantener las 4 Ps integradas. Sin la integración y la
relación estrecha entre el cualquiera de las 4 Ps, el diseño, los planes y los proyectos fallarán
normalmente, debido a la carencia de la preparación y de la gestión.



4.2.1. Proveedor de Servicios (SP)
La entidad responsable de la entrega de un servicio (p.ej. email, facturación) a los clientes y al
Negocio (interno o externo).
Organización interna o externa que quiere cumplir con las mejores prácticas de ITIL® y la Norma
ISO/lEC 20000
4.2.2. Suministrador (Supplier).

Cualquier entidad de terceros externa necesaria para proporcionar las líneas de ayuda a los
componentes requeridos para proporcionar las mallas del servicio (p.ej. hardware, software).
4.2.3. Acuerdo de Nivel de Servicio (SLA)

Es un Acuerdo entre un Proveedor de Servicios de TI y un Cliente. El SLA describe el Servicio de TI,
documenta los objetivos de Nivel de Servicio y especifica las responsabilidades del Proveedor de
Servicios de TI y del Cliente. Ayudándose del Catálogo de Servicios, el proceso Gestión de Nivel de
Servicios debe de diseñar la más apropiada estructura de SLA, garantizando que todos los servicios
de los clientes se alineen a las necesidades de las organizaciones.
4.2.4. Contrato (Contract) (UC)

Un contrato es un acuerdo entre dos o más partes atándolas legalmente. Cubre las obligaciones que
cada entidad tiene con la otra a partir del primer día del contrato, extendiendo a veces más allá de
su terminación.
Se utiliza como base para los acuerdos externos del Suministrador donde se requiere una comisión
ejecutoria. Las relaciones de alto valor y/o estratégicas se aceptan en un contrato formal. La
formalidad y la naturaleza obligatoria de un contrato no están en desacuerdo con la cultura de un
acuerdo entre socios y de buena fe.
4.2.5. Acuerdo de Nivel Operacional (OLA)

(OLA) Es un acuerdo entre el Proveedor de Servicios y otros departamentos internos de la misma
organización para el mejor desempeño de sus funciones.
4.2.6. Paquete de Diseño del Servicio - (SDP)

El Diseño de Servicio produce un “Paquete para el Diseño de un Servicio”, para cada nuevo Servicio,
cambio importante o retiro de un Servicio o cambio de un ya producido “Paquete para el Diseño de
un Servicio”.
El SDP se pasa del Diseño del Servicio a Transición del Servicio y detalla todos los aspectos del
servicio y de sus requisitos con todas las etapas. Debe de contener:
Requisitos
 Plan de negocio ( Recursos, beneficios, servicios afectados, etc. )
 Requisitos de aplicabilidad (cuando y como se va a usar).
 Contactos del servicio.
 Requisitos funcionales del servicio ( Sor )
 Requisitos de negocio.
 Requisitos de Nivel de Servicio. SLRs y SLAs
 Requisitos operacionales y de servicio.
 Diseño del Servicio y topología.

Evaluación de predisposición organizativa

 Evaluación de predisposición organizativa
Plan de ciclo de vida.
 Programa o plan general del Servicio ( que cubra todo el ciclo)
 Plan de transición del servicio ( como se paquetizará y entregará )
 SAC Criterios de aceptación
 Plan de aceptación operativa del servicio.
Se crea en:
 En Estrategia se definen los SDPs y revisar las plantillas SLA.
 En Diseño y siguientes se alimentan y actualizan.

4.3. Claves Principales y Modelos

4.3.1. Importancia de las 4 Ps
La puesta en práctica de la Gestión de Servicios se basa en la preparación y planeamiento del uso

sincronizado y eficiente de los 4 Ps
Personas
Roles
Responsabilidades
Habilidades...
Procesos
ITSM Productos
Objetivos
Actividades
Infraestructura de TI
Interrelaciones...
Herramientas...
Partners
Proveedores
Outsourcers...
La implementación de Gestión del Servicio de ITIL como práctica trata sobre la preparación y
planificación del uso eficaz y eficiente de las cuatro P: las Personas, los Procesos, los Productos
(servicios, tecnología y herramientas) y los Socios (Partners) (suministradores, fabricantes y
proveedores)

4.3.2. Grupos Estratégicos

Para asegurarse de que el negocio y los servicios de TI sigan sincronizados, muchas organizaciones
forman comités entre Gestión sénior del negocio y Organizaciones de TI. El comité lleva la
responsabilidad para el gobierno, la dirección, la política y la estrategia para los servicios de TI.
Muchas organizaciones refieren a este grupo como TI Strategy o TI Steering Group (ISG). La función
de un ISG es actuar como asociado entre TI y el Negocio.
Debe reunirse regularmente y repasar el negocio y las estrategias de TI, diseños, planes, cartera de
servicios, arquitecturas y políticas para asegurarse de que estén alineados uno con el otro.
Debe proporcionar la visión, fijar la dirección y determinar prioridades de programas y de proyectos
individuales para asegurarse de que está alineada y centrada en los objetivos y en la buena
dirección.
El grupo debe también asegurarse de que los calendarios poco realistas, que podrían comprometer
calidad o interrumpir requisitos operacionales normales, no sean impuestos ni sean intentados por
el negocio o TI
ASUNTOS RAZONES PARA LA DISCUSIÓN
Revisión del Negocio Para identificar cualesquier cambio en cualquier área que accionaría la
y planes de TI necesidad de crear, realzar o mejorar los servicios
Planeamiento de la Para identificar cualesquier cambio en cuanto a Demanda para la planificación
Demanda de horizontes a largo y corto plazo. Los cambios pueden ser aumentos o
disminuciones en demanda, y se refiere a negocios en marcha y proyectos
Autorización del Para asegurarse de que los proyectos estén autorizados y con prioridad a
Proyecto y satisfacción mutua del Negocio y de TI
priorización
Revisión de Para asegurarse de que los beneficios esperados del Negocio se están realizando
Proyectos de acuerdo con los casos del negocio e identificar si los proyectos están
marchando según lo programado
Externalización Para identificar la necesidad y contenido de las estrategias de compra de
potencial componentes para la provisión de servicios TI.
Revisión de las Para discutir cambios importantes en la Estrategia empresarial y propuestas de

estrategias de TI y el cambios en la Estrategia de TI y la tecnología, para asegurar que la alineación es
Negocio la acordada.
Continuidad de los El grupo o una parte del grupo de trabajo es responsable de alinear la
Servicios y Continuidad del Negocio y las Estrategias de la Continuidad de los Servicios
Continuidad del
Negocio
Políticas y Estándares Es responsable de asegurar que las políticas y estándares, particularmente en lo
referente a estrategia y a funcionamiento financieros está en el lugar y alineado
con la visión corporativa.

Grupos Estratégicos
Objetivos
Estrategias y Planes Corporativos
Estrategias y planes del Negocio

Planes Planes Planes
Planes
Negocio Negocio Negocio
Negocio TI Unidad 1 Unidad 2 Unidad 3
Consejo
de
Estrategias y planes Funcionales Dirección
de TI
TI Planes Planes Planes
Planes Unidad 1 Unidad 2 Unidad 3
Estrategias y planes Operacionales
TI Planes Planes Planes

Planes Unidad 1 Unidad 2 Unidad 3
4.3.3. Propósito del Diseño del Servicio

El Propósito principal de la etapa del Diseño del Servicio durante su Ciclo de Vida es el diseño del
nuevo o cambiante servicio para introducirlo en un ambiente de producción y tiene 5 aspectos:
Solución del Servicio (requisitos del Servicio, recursos y capacidades).
El Servicio de Portafolio (Cartera de Servicios) y el Catálogo de Servicios.
Arquitectura (Tecnológica y de gestión).
Los Procesos de la Gestión de Servicios.
Las Métricas y los sistemas de medición
Proporciona las líneas maestras para el desarrollo de servicios, los modelos y procesos ayudando a
decidir sobre las actividades que se harán (cómo y qué)
4.3.4. Los 5 aspectos importantes del Diseño del Servicio

Diseño de la Solución del Servicio:
La identificación de los requisitos del Negocio, la definición de los requisitos de los servicios y el
diseño de los mismos.
Los Servicios se diseñan con todos los requisitos y capacidades necesarias.
Gestión de la Cartera de Servicios(SPM) y el Catálogo de Servicios:
La Cartera de Servicios se diseña en la fase Estrategia del Servicio y se gestiona por Diseño del
Servicio.

Diseño Arquitectónico de la tecnología y cómo se gestiona.

Diseña las políticas, estrategias, documentos, arquitecturas, planes y procesos de la tecnología y los
sistemas de gestión requeridos para proporcionar los servicios. Desarrollo y despliegue de una
infraestructura de TI y la implementación y mejora de servicios y soluciones a toda la organización.
Diseño de los Procesos.
Diseñar los procesos necesarios para la transición, funcionamiento y mejora de los servicios, las
arquitecturas y los procesos mismos. Definición de los objetivos, propietarios, actividades, entradas,
salidas y tareas para trabajar más efectiva y eficientemente.
Diseño de Métricas.
Diseñar los métodos de medición y las métricas de los servicios para investigar el progreso,
cumplimiento, efectividad y eficiencia del proceso.

4.4. El Diseño de Soluciones del Servicio

4.4.1. Requisitos del Negocio
Para que una organización produzca un nuevo o modificado servicio, antes hay que terminar
ciertas actividades dentro del Diseño de Servicio.
Un acercamiento estructural es necesario con el coste correcto, calidad funcional y dentro del
tiempo. Se debería incluir:
Identificación de los Requerimientos del Negocio.
Definición de los Requerimientos del Servicio.
Diseño de los Servicios
Análisis de los requisitos convenidos con el Negocio (SLR)
Revisar la existente infraestructura de TI
Diseño de las soluciones del servicio a los nuevos requisitos incluyendo los componentes de
soporte.
Instalaciones, funcionalidad e información requeridas
Procesos de Negocio soportados, dependencias, prioridades, criticidad e
impacto de los servicios, con las ventajas del Negocio entregadas por el
servicio
Ciclos económicos, niveles de la transacción de Negocio, niveles de la
transacción del servicio, los números/tipos de usuarios, crecimiento futuro
anticipado y los requisitos de la continuidad del Negocio
Requisitos y objetivos del porcentaje de disponibilidad con la medición
requerida del servicio, la información y actividades de mejora continua
Escala de tiempo implicada, resultados previstos y el impacto en cualesquiera
servicios existentes
Requisitos para la prueba, incluyendo cualquier prueba de aceptación de
usuario (UAT) y responsabilidades asociadas
Requerimientos de Criterios de Aceptación del Servicio (Service Acceptance Criteria) (SAC)
Evaluación y Coste – Diseño alternativo
Convenir el gasto y los presupuestos
Re-evaluar y confirmar los beneficios del Negocio (ROI & TCO)
Rentabilidad de la inversión (ROI) - todos los costes del servicio, ventajas para
el Negocio y réditos crecientes
Coste total de la propiedad (TCO)
Costes de lanzamiento tales como costes del diseño, costes de la transición,
presupuesto de proyecto y todos los costes operacionales en curso incluyendo
la gerencia, el soporte y el mantenimiento
Convenir la solución preferida, sus resultados y objetivos previstos (requisito del porcentaje
de disponibilidad en la SLR)
Confirmar la inclusión corporativa, Gobierno de TI y controles de Seguridad
Terminar los riesgos de la preparación y asegurar una operación óptima

Para asegurarse de que el servicio pueda funcionar eficientemente para cumplir los objetivos
convenidos, confirmando la capacidad apropiada para entregar al nivel comprometido en la SLA.
Esto incluirá:
El impacto comercial en la organización del Negocio y desde la perspectiva de
TI incluyendo todas las ventajas del Negocio y todos los costes
El aumento y la mitigación de los riesgos que se asociaron al nuevo o cambiado
servicio, particularmente en lo que respecta a la operación, a la seguridad, a la
disponibilidad y a la continuidad del servicio
Capacidad y madurez del Negocio. Debe ser realizado por el Negocio mismo
para asegurarse de que todos los recursos están en el lugar donde deben
funcionar los nuevos servicios TI
Entorno y todas las áreas de la tecnología, considerando el impacto en los
componentes existentes de la infraestructura y los servicios existentes de TI
Estructura de organización, los roles y las responsabilidades
Procesos y su documentación o Conocimientos, conocimiento y capacidad del
personal
Procesos de la gestión de TI y herramientas de apoyo
Establecer los suministradores y los acuerdos de soporte
Montar el Paquete para el Diseño de un Servicio (SDP) para las etapas subsiguientes.
4.4.2. Composición de un Servicio en Dominios
Servicio de Negocio A
Gestión del Servicio Proceso de Proceso de Proceso de

de Negocio Negocio 1 Negocio 2 Negocio 1
Requisitos/Demanda
Servicio de TI Conformidad con

la política/estrategia del
Utilidad: Gobierno Corporativo
Nombre, descripción, SERVICIO
propósito, impacto, contactos
Garantía: SLAs/SLRs
Niveles de servicio, objetivos, Incluyendo
Horario de servicio, aseguramiento, Coste/precio
responsabilidades
Activos/recursos:
Sistemas, activos, Infraestructura Entorno Datos Aplicaciones
componentes
Activos/capacidades: Procesos
Procesos, objetivos de Contratos Servicios de TI
OLAs de Soporte
soporte, recursos
Activos/recursos: Equipos
Recursos, personal, habilidades, Suministradores de Soporte
activos, componentes

4.4.3. Identificando los requerimientos de un Servicio
Unidad de Negocio A Unidad de Negocio B Unidad de Negocio C El

Negocio
3 6 9
2 5 8
Proceso Proceso Proceso
de Negocio 1 de Negocio 4 de Negocio 7
Servicios de TI
B C
Servicio A SLAs
Infraestructura TI
Sistema Sistema
DBMS RED Entorno Datos Aplicaciones
H/W S/W
Servicios
OLAs de Soporte
Equipos
Servicios
Contratos
de Soporte
(iii)
(ii) Suministradores
Equipos
de Soporte (i)
(iii)
(ii)
Suministradores (i)
Diseño del Servicio deberá considerar todos los elementos del mismo asumiendo un método
integral para el diseño de un nuevo servicio. Este método debería considerar el servicio y sus
componentes y sus interrelaciones garantizando que los servicios entregados cumplan la
funcionalidad y calidad esperadas por el negocio en todas las áreas que se muestran en esta figura.
Ningún servicio se puede diseñar, pasar por transición ni operarse de forma aislada.
4.4.4. Identificando influencias externos en el Servicio
Mejora
Diseño
Transición
Estrategia
El Coordinador de Diseño del Servicio deberá 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.

4.5. El diseño de la Cartera de Servicios (Service Portfolio)

Hay que diseñar los servicios de forma que se cumplan las salidas de la Estrategia de Servicios y que
se puedan control a través de su Ciclo de Vida con los sistemas de gestión y sus herramientas
Para que una organización soporte y automatice procesos eficientes y maneje eficazmente todos los
aspectos del Ciclo de Vida del Servicio, los sistemas de gestión han de ser puestos a disposición del
cliente.
Service Portfolio es una de las herramientas de gestión usadas para describir los servicios de un
suministrador en términos de valor de Negocio.
4.5.1. Cartera de Servicios-(Service Portfolio) (SPM)

Por definición, los términos de “valor de negocio” corresponden a los términos del mercado, el
proveer una forma de comparar competitividad del servicio a través de proveedores alternativos.
Al actuar como la base de un marco de decisión, una lista de los servicios (Cartera de Servicios)
aclara o ayuda a aclarar las preguntas estratégicas siguientes:
¿Por qué debe un cliente comprar estos servicios?
¿Por qué deben comprar estos servicios de usted?
¿Cuáles son los modelos de precios y de costes a aplicar?
¿Cuáles son mis fuerzas y debilidades, prioridades y riesgo?
¿Cómo deben mis recursos y capacidades ser asignados?
4.5.2. Service Portafolio en el SKMS:

Registrarse como un documento en el SKMS dentro de (CMS) Configuration Management System.
Contiene los servicios activos y aprobados ya en Operación del Servicio con sus políticas, directrices,
responsabilidades, etc. El cliente puede revisar la mayor parte de los atributos de los servicios
aprobados pero a través del Catálogo de Servicios. Muy útil para Gestión de Capacidad y Gestión de
Continuidad.
Las opciones de STATUS en el Las opciones de DETALLE en el

Servicio de Portafolio incluirían: Servicio de Portafolio incluirían:
Nombre del Servicio
Requerimientos Descripción del Servicio
Estado del Servicio
Definido
Clasificación del Servicio
Analizado Critico o no
Aplicaciones usadas
Aprobado Fecha del esquema
Presupuestado Procesos soportados del Negocio
Propietarios del Negocio
Diseñado Usuarios del Negocio
Desarrollado Propietarios de TI
Garantía a nivel de Servicio
Construido SLA
Desplegado SLR
Servicios soportados
Operacional Recursos soportados
Mantenimiento Servicios dependientes
OLA
Retirado Coste de Servicio

Cada uno de los servicios listados en la Cartera de Servicios debería de tener un status o
ESTADO como por ejemplo:
Requerimientos: Un conjunto de requisitos del esquema que se han recibido desde el

Negocio o de TI para un nuevo o modificado servicio
Definido: Un conjunto de requisitos para el nuevo servicio que se está determinando,
definiendo, y documentando y se está produciendo el SLR
Analizado: Un conjunto de requisitos para el nuevo servicio que está siendo analizado y
priorizando
Aprobado: Un conjunto de requisitos para el nuevo servicio que está siendo finalizado y
autorizado
Presupuestado: Los requerimientos para el nuevo servicio están siendo comunicados y
asignando los recursos y presupuestos al mismo
Diseñado: El nuevo servicio y todos sus componentes están siendo diseñados y procurados,
si ello es requerido
Desarrollado: El nuevo servicio y todos sus componentes están siendo desarrollados o
comprados, si ello es aplicable
Construido El nuevo servicio y todos sus componentes están siendo construidos
Test: El nuevo servicio y todos sus componentes están siendo probados
Desplegado: El nuevo servicio y todos sus componentes están siendo liberados
Operacional: El nuevo servicio y todos sus componentes están operacionales dentro del
entorno vivo de producción
Mantenimiento: El nuevo servicio y todos sus componentes están siendo revisados o
mejorados
Retirado: El nuevo servicio y todos sus componentes han sido retirados
El Service Portfolio por lo tanto contendría los detalles de todos los servicios y de su estado con
respecto a la etapa actual dentro del Ciclo de Vida del Servicio.
La lista de los servicios es la fuente de información principal en los requisitos de los servicios y
necesita ser diseñada muy cuidadosamente y cubrir todas las necesidades de todos sus clientes y
usuarios.
El diseño de la lista de los servicios necesita ser considerado de la misma forma que el diseño de
cualquier otro servicio para asegurarse de que cubren todas estas necesidades.
Service
Portafolio
Ciclo de Vida Service
del Servicio
Pipeline
Estado del Servicio:
Requerimientos Servicios
Definido Retirados
Analizado
Aprobado
Instituído
Diseñado Service El Equipo de Soporte de
Desarrollado los Clientes ven SOLO
Probado Catalogue
esta sección del
Entregado
Catálogo en el
Operacional
Portafolio
Service Knowledge Management System

4.6. El Diseño de la Arquitectura

Es el desarrollo y mantenimiento de políticas, estrategias, arquitecturas, diseños, planes y
procesos de TI para el despliegue, implementación y mejoras de servicios y soluciones de TI
apropiado en toda la organización.
Este aspecto se refiere al diseño de las arquitecturas de la tecnología y los sistemas de gestión
requeridos para proporcionar los servicios y se refieren a los “modelos estratégicos totales” que
satisfacen las necesidades actuales y futuras del Negocio.
Aunque la tecnología sostenga la entrega de los servicios de la calidad, ésta no puede hacerlo solo
por sí misma, es esencial que se considere a la gente, el proceso y a los interesados (Stakeholders).
Aspectos que hemos de tener muy en cuenta.
Arquitectura: La organización fundamental de un sistema (System) que está incorporado a sus
componentes (CIs), a las relaciones del uno con el otro y al entorno y a los principios que dirigen
su diseño y evolución.
Sistema (System): Un conjunto de componentes interrelacionados o independientes, que
interactúan como un TODO operando juntos para un propósito común.
Diseño arquitectónico: El desarrollo y el mantenimiento de TI, las políticas, estrategias,
arquitecturas, documentos, planes y procesos para el despliegue en Operación del Servicio.
Cada uno de estos sistemas de la arquitectura consta de:
Los componentes del sistema. Las relaciones entre ellos (por ejemplo
intercambios de datos de los interfaces y de su control)
Las relaciones entre el sistema y su entorno (políticas, organización,
tecnología, etc.)
Los principios de diseño que informan, dirigen y obligan su estructura y
operación, así como su desarrollo futuro
Las infraestructuras, los entornos, los datos, los usos y los servicios externos
que responden a las necesidades del Negocio, de sus productos y de los
servicios. Esto incluye los componentes de la tecnología y su gestión
El equilibrio correcto se alcanza entre la innovación, el riesgo y el coste
mientras que busca una posición competitiva para el Negocio
Conformidad con los cultura empresarial, las estrategias, las políticas, las
regulaciones y los estándares arquitectónicos relevantes (requisitos fiduciarios)
La coordinación que se proporciona entre TI, los diseñadores y los
planificadores, los estrategas y los diseñadores del Negocio
Arquitectura Empresarial: Muestra cómo todos los componentes se integran para alcanzar los
objetivos de Negocio ahora y en el futuro y puede ser grande y compleja. Hay varios marcos de
trabajo (Como Togaf) para desarrollar la Arquitectura de la Empresa que incluye lo siguiente
Arquitectura de Servicios: Convierte las aplicaciones, la infraestructura, la
organización y las actividades de soporte en servicios para el negocio
Arquitectura de Aplicaciones: Garantiza la creación de proyectos para
desarrollar aplicaciones individuales.
Arquitectura de la Información: Se centra en la distribución y gestión de las
fuentes de la información.
Arquitectura de la Infraestructura de TI: Se centra en la estructura, la función
y la distribución geográfica del software y el hardware.
Arquitectura del Entorno: Describe todos los aspectos, niveles y tipos de los
controles del entorno

Nos estamos centrando en esas arquitecturas referidas al Negocio y a los sistemas de

información como ayuda al mismo, cada uno de estas arquitecturas tiene disciplinas y campos
de especialización arquitectónicos distintos.
Con las arquitecturas necesarias en su lugar, el papel del Diseño del Servicio se afecta como
sigue:
Tiene que trabajar dentro del marco y de los estándares arquitectónicos
convenidos
Pueda reutilizar muchos de los activos creados como parte de la arquitectura
Si se va al diseño de una arquitectura con eficiencia y economía, los
documentos, los procesos y las actividades del Negocio y del diseño
arquitectónico deben ser coordinados y ser sincronizados muy de cerca.
La clave: La ventaja verdadera y el ROI de la arquitectura de la empresa viene no de la

arquitectura en sí misma, sino de la capacidad de una organización de diseñar y de ejecutar
proyectos y soluciones de una manera rápida y constante
La organización fundamental de un sistema, materializado en sus componentes, en sus

relaciones con los demás y con el entorno, y en los principios que guían su diseño y
evolución
Arquitectura del Negocio / Organización
Elemento integrador de la Arquitectura de la Empresa
Arquitectura del Negocio
Arquitectura del
Servicio
Arquitectura de Arquitectura de la
la Aplicación (RAD) Información / Datos
Arquitectura del Entorno

Arquitectura de la
Infraestructura
Arquitectura
de TI
de Gestión
Arquitectura
del Producto
La Arquitectura de la Empresa puede ser grande y compleja. Aquí estamos interesados en

aquellas arquitecturas implicadas con el negocio de la organización y con los sistemas de
información que les dan soporte. Cada una de estas arquitecturas exige distintas disciplinas de
arquitecturas y áreas de experiencia.
La Arquitectura de la Empresa es definida por Gartner como:
“El proceso de traducción de la visión y estrategia del negocio en un cambio empresarial

eficaz, creando, comunicando y mejorando principios y modelos clave que describen los futuros
estados de la empresa y que permiten su evolución”.

4.7. Diseño de los Procesos

La definición de las actividades, sus entradas, salidas y los objetivos esperados permite trabajar de
una forma eficiente y orientada al cliente.
El diseño de los propios procesos para el del Diseño, Transición y de Operación del Servicio son
necesarios para mejorarlos en sí mismos.
Cada proceso debe tener un propietario que es responsable de los resultados y de su mejora.
4.7.1. Modelo del Proceso:

EL PROCESO es un conjunto de actividades diseñadas para obtener ciertos objetivos definidos. El
modelo de proceso permite entender y ayudar a articular las características distintivas de un
proceso. Incluye roles, responsabilidades, recursos y gestión de control para posibilitar Directivas.
PERO HAY QUE CONTROLAR. Controlar es medir
Un proceso toma una o más entradas y los retorna en salidas definidas.
Un proceso incluye todos los roles, responsabilidades, herramientas y controles de
gestión requeridos para entregar confiablemente las salidas.
Un proceso puede también definir o revisar políticas, estándares, pautas,
actividades, procesos, procedimientos, e instrucciones de trabajo si son necesarias.
PROCESOS DE MEJORA CONTINUA
Objetivos Resultados
Propietario del proceso Propietario del proceso
(OWNER) es responsable (OWNER) es responsable
de los resultados de los resultados
Gestor (ROL) Gestor (ROL)

realiza el proceso realiza el proceso
No confundir ROL No confundir ROL

con Personas con Personas
Entrada El Operador es El Operador es

Entrada
responsable de las responsable de las
TAREAS TAREAS
Salida Salida
Procedimientos Procedimientos
Proceso es un conjunto de actividades para obtener objetivos concretos
Proveedor
Actividad 1 Proceso
Actividad 2
Actividad 3
Control y calidad del servicio

Cliente
Disparador

4.7.2. El Propietario del Proceso (Process Owner)

El Propietario del Proceso: Es el responsable de los resultados del mismo. Ayuda a Diseño del
Servicio para que cada dueño de un proceso se asegure de que los procesos utilicen términos y
plantillas estándares, sean constantes y se integren de extremo a extremo a través de todas las
áreas y es responsable de:
El Proceso y sus mejoras continuas
Asegurarse que el Proceso cumple sus objetivos.
4.7.3. Medición de las Salidas (Outputs)

Definiendo cuáles son las actividades de la organización que son necesarias y sus entradas y
salidas del proceso, es posible trabajar de una manera más eficiente y más efectiva.
La medición y la dirección de las actividades aumentan esta eficiencia.
Finalmente, agregando normas al proceso, es posible agregar medidas de la calidad a la salida.
La siguiente figura proporciona más detalles a esto.
Control Propietarios
Feedback
de los
de Procesos Objetivos
de los
Procesos
Procesos Documentos
de los
Procesos Políticas
de los de los
Procesos
Procesos
Procesos
Actividades Procedimientos Roles
de los de los de los
Procesos Procesos Procesos
Salidas
Métricas Mejoras
Instrucciones de los
Entradas de los de los
De Trabajos Procesos
Procesos Procesos
de los
Procesos
Procesos
Recursos Capacidades
Activados de los de los
Procesos Procesos
Este acercamiento sostiene el `planear-hacer-chequear-actuar' (PDCA) del Ciclo de la Mejora

Continua de los servicios para cualquier sistema de gestión de calidad.
Se debe de planear el propósito de los procesos de una manera tal que las acciones de proceso
se puedan revisar, determinar y medir para el logro propuesto y, mejorando el anterior.
Normas o estándares
Define las condiciones que los resultados deben cumplir e introducen aspectos de la calidad al
proceso
No a los Procesos Perfectos
Adopte un acercamiento formalizado al diseño y la puesta en práctica de los procesos de la
Gestión de Servicios
No diseñe los “procesos perfectos”, diseñe los procesos prácticos y apropiados con los
mecanismos “incorporados” para mejorar la eficiencia y efectividad de los procesos

4.8. Diseño de las Métricas (KPIs)

4.8.1. Mejora Continua del Servicio (CSI):
Los Procesos tienen que ser monitorizados, medibles y sus objetivos alcanzables
Para agregar valor al negocio hay 4 razones para monitorizar y medir, que son:
VALIDAR – DIRIGIR – JUSTIFICAR – INTERVENIR
Si no lo mides, no puedes manejarlo.
Si no lo manejas, no puedes Controlarlo.
Para Controlarlo necesitamos las Métricas.
Controlar es Medir
Si te interesa mídelo, y si no puedes influenciar en ello, no lo midas.
Se puede aplicar las métricas de la tecnología a cada uno de sus CIs.
Las mmétricas de los servicios miden los Servicios de extremo a extremo.
Las métricas ayudan a los Procesos a que:
Cumplan con el propósito
Tengan el apropiado nivel de calidad
Sean los correctos desde el principio
Sean efectivos y eficientes
La actividad del planeamiento y de regularización de un proceso, se realice de forma
consistente.
Los procesos una vez definidos, se documentarán y una vez bajo control, pueden ser repetidos y
manejados.
Un proceso se organiza siempre alrededor de un sistema de objetivos. Las salidas principales del
proceso se deben encauzar para cumplir los objetivos y deben incluir siempre las medidas de
proceso (métrica), los informes y la mejora del proceso. Muchas veces la entrada de otro proceso es
nuestra salida, es decir nuestro resultado y viceversa
El sistema de evaluación que hayamos diseñado tiene que estar sincronizado con la capacidad y
madurez de los procesos evaluados. La evaluación tiene que ser cuidadosa pues afecta a la moral de
trabajo de los empleados y por ello a la provisión de servicios.
Los procesos inmaduros no admiten evaluaciones sofisticadas.
Los elementos que se pueden investigar son cuatro:
Progreso
Cumplimiento
Eficacia
Eficiencia
Progresión: Tener mesura al seleccionar medidas y métricas porque afectarán y cambiarán el
comportamiento de la gente que trabaja con las actividades y los procesos, particularmente donde
éstas se relacionan con los objetivos.
Solamente las medidas que animan la progresión hacia objetivos del Negocio o de cambio deseado
deben ser seleccionadas

Los Métodos y las Métricas deben:

Reflejar los requisitos y diseños para medir la capacidad de los procesos de diseño
para cumplir estos requisitos
Reflejar la calidad y el éxito de los procesos de diseño desde la perspectiva del
Negocio, de los clientes y de los usuarios
Reflejar la capacidad de las soluciones entregadas para cumplir los requisitos
identificados y convenidos del Negocio.
Conveniencia: Las medidas de proceso seleccionadas necesitan ser apropiadas para
la capacidad y la madurez de los procesos que han sido medidos.
Progreso: Etapas y productos a entregar en la capacidad del proceso.
Conformidad: Conformidad del proceso a los requisitos de los gobiernos y
organismos reguladores y a la conformidad de las personas que usarán del proceso.
Efectividad: La exactitud y corrección del proceso y de su grado de aproximación a
su objetivo.
Eficiencia: La productividad del procesos cuando se realice a la mayor brevedad
posible, según los estándares de la empresa con el menor esfuerzo posible y usando
los recursos de la organización a un coste aceptable.
4.8.2. Marcadores Equilibrados (Kaplan y Norton):

Es un método para medir las actividades de una compañía en términos de su visión y estrategia.
Proporciona a los Gerentes una visión global de las prestaciones del Negocio.
Los marcadores equilibrados representan un sistema de gestión que permiten incrementar el
número de unidades de negocio para clarificar su visión y estrategia en la acción.
Se puede utilizar para desarrollar árboles o tableros de métricas; el método más eficaz de medida
es establecer un "árbol de la métrica" o el "árbol de KPI".
4.8.3. Métricas y Medidas

La Métrica es una escala de medida que se define en términos de un estándar, esto
es, en términos de una unidad bien definida. La cuantificación de un evento a través
del proceso de medida se basa en la existencia de una métrica explícita o implícita,
que es el estándar al que se referencian las medidas.

Las métricas son un sistema de parámetros o medios de evaluación cuantitativa de

un proceso que se tiene que medir, junto con los procesos necesarios para realizar
tal medida. Las métricas definen qué se tiene que medir. Las métricas se
especializan normalmente por cada tipo de área, en cuyo caso sólo son válidas
dentro de un cierto dominio y no pueden compararse o interpretarse directamente
fuera del mismo. No obstante, las métricas genéricas pueden agregarse entre
diversos tipos de áreas o unidades de negocio de una empresa.
Estas medidas o métricas pueden servir para realizar el seguimiento de las
tendencias, la productividad, los recursos y para muchas otras aplicaciones.
Habitualmente, las métricas a las que se les realiza un seguimiento son KPI.
4.8.4. Opciones de Externalización – Modelos de Entrega

Las métricas deben ser aplicadas a organizaciones internas y externas. Sobre las externas habrá
que tener en cuenta el tipo de organización de aprovisionamiento como por ejemplo:
Insourcing (Internalización): Utiliza recursos internos de la organización en el Diseño,
Transición, Operación y/o de ayuda de nuevas, cambiantes o revisadas operaciones de
servicios.
Outsourcing (Externalización): Utiliza los recursos de una organización externa en un
contrato formal para proporcionar una parte bien definida del diseño, desarrollo,
mantenimiento, operaciones y/o de ayuda de un servicio.
Co-sourcing (Co-aprovisionamiento): Combinación del insourcing y del outsourcing, usando
un número de organizaciones del outsourcing que trabajan junto a los elementos claves
dentro del ciclo de vida. Esto implicará usar de organizaciones externas que trabajan junto a
la nuestra para el Diseño, Transición, Operaciones y/o apoyar una parte de un servicio.
Sociedad o multi-sourcing (Multi-aprovisionamiento): Los contratos formales entre dos o
más organizaciones para proporcionar una parte bien definida del Diseño, Transición,
Operaciones y/o de la ayuda de un servicio.
Business Process Outsourcing (Externalización de Proceso de Negocio BPO): La tendencia a
aumentar a poner el negocio entero con contratos formales entre organizaciones donde una
proporciona y maneja los procesos y funciones enteros del negocio de la otra organización
en una localización de bajo costo.
Aplication Services Provider (Provisión de Servicios de Aplicación): Implica contratos
formales con una organización Proveedora de Servicios de Aplicaciones (ASP) que
proporcione servicios computerizados compartidos con las organizaciones Cliente sobre una
red.
Knowledge Process Outsourcing (KPO) (Externalización del Proceso del Conocimiento): Las
organizaciones de KPO proporcionan procesos propietarios y maestría basados en
experiencias en el negocio antes que maestría sobre el proceso. Requieren habilidades
analíticas y especialización avanzada desde la organización del outsourcing.


4.9. Diseño del Servicio – Interfaz con otras fases en el Ciclo de

Vida
El Negocio /
Clientes
Estrategia de Servicio
Directivas – Recursos
Objetivos de los requerimientos
Service
Portfolio Diseño de Servicio
Soluciones de diseño – Arquitectura
Estándares - SDPs
Continual
Service
Improvement
Service
Planes de Transición
Catalogue Soluciones probadas - SKMS
Planes operacionales
csi
Based On Cabinet Office ITIL® Material. Reproduced Under License From The Cabinet
Office
4.9.1. Modelos de Diseño del Servicio y sus limitaciones
Antes de adoptar un modelo de diseño hay que analizar las capacidades y los equipos de TI de que
disponemos en la organización y ha de centrarse en los siguientes elementos:
 Directrices y demandas del negocio

 Ámbito y capacidades del SP actual
 Requisitos y objetivos del nuevo o modificado servicio
 Ámbito y capacidades de los SP externos
 Madurez de los procesos y de las organizaciones
 La cultura empresarial de las organizaciones
 Infraestructura de TI, aplicaciones, datos y componentes
 Nivel de Gobierno Corporativo y de TI
 Recursos y presupuestos disponibles
 Personal disponible y sus aptitudes y capacidades

4.9.2. Restricciones del Diseño del Servicio
Hay considerables limitaciones obligatorias y legales que se aplican y que se deben considerar
durante el Diseño del Servicio.
Restricciones que se aplican y a considerar durante el Diseño del Servicio
Garantias
Financieras
Comisiones de
Servicios Valores y
ética.
Espacio de la solución Recursos

(Service Portfolio)
Estándares y Leyes
Propiedad
Intelectual Otras
Restricciones
Utilidades
Capacidades
Una vez aplicadas las restricciones o limitaciones en el diseño del Servicio, su resultado es el
ESPACIO DE LA SOLUCIÓN.
Es lo que debe de quedar y queda aprobado en la Cartera de Servicios

4.10.Procesos y otras actividades

Cada fase del Ciclo de Vida produce resultados en forma salidas que son entradas en la fase
siguiente. La Estrategia del Servicio produce información para el Diseño del Servicio, que
son sus entradas y estas informaciones documentadas sobre el diseño, salidas, son las
entradas para la Transición del servicio
Para desarrollar servicios de forma eficiente y a veces de forma eficaz es vital incorporar al
Diseño del Servicio los resultados de otras áreas y procesos. Los procesos más fuertemente
conectados son los ocho siguientes.
Gestión de Coordinación del Diseño

Gestión de Catálogo de Servicios
Gestión del Nivel de Servicio
Gestión de la Capacidad
Gestión de la Continuidad del Servicio de TI (ITSCM)
Gestión de la Seguridad de la Información
Gestión de Suministradores
Además de estos siete procesos hay tres importantes Actividades:
Desarrollo de Requisitos.
Gestión de la Información y los Datos.
Gestión de Aplicaciones.


4.11.Gestor de la Coordinación del Diseño

4.11.1. Objetivos
Asegurar el Diseño coherente de los Servicios adecuados, sistemas de gestión de la
información, arquitectura, tecnología, procesos, información y métricas para
cumplir con los resultados de negocio actuales y futuros y sus requisitos
Coordinar todas las actividades de Diseño a través de proyectos, cambios, equipos
de apoyo, proveedores, gestión de programas, recursos y conflictos
Planificar y coordinar los recursos y capacidades necesarias para diseñar Servicios
nuevos o modificados
Producir los Paquetes de Diseño del Servicio (SDP) en base al Catálogo y/o RFCs
Asegurar que los Diseños adecuados de Servicios se producen y que son entregados
a Transición del Servicio como se acordó
Gestionar los criterios de calidad, los requisitos y los puntos de transferencia entre
las fases de Estrategia, Diseño y Transición de los Servicios
Asegurar que todos los modelos y el Diseño de Servicios se ajustan a la solución
estratégica, gestión de arquitectura, y otras necesidades corporativas
Mejorar la efectividad y la eficiencia de todas las actividades de Diseño de Servicios
Asegurar que todas las partes adopten un marco común de las prácticas estándar
Controlar y mejorar el rendimiento de la etapa del Diseño del Servicio en el Ciclo
Vida del Servicio
4.11.2. Ámbito
Asistencia y apoyo a cada proyecto u otro cambio, a través de todas las actividades
de Diseño de Servicios
Mantenimiento de las políticas, directrices, normas, modelos, presupuestos,
recursos y capacidades para las actividades de Diseño de Servicios y procesos
Coordinación, priorización y programación de todos los recursos de Diseño de
Servicios para satisfacer las demandas de los proyectos y sus cambios
Planificación y previsión de los recursos necesarios para futuras demandas de las
actividades de Diseño de Servicios
Revisar, medir y mejorar el rendimiento de todas las actividades de Diseño de
Servicios y de los procesos
Asegurar que se tengan en cuenta todos los requisitos en el Diseño de Servicios, en
particular los requisitos de utilidad y garantía
Garantizar la producción de Paquetes de Diseño de Servicios y su entrega a
Transición del Servicios
La responsabilidad de las actividades o procesos fuera de la fase de Diseño del
Servicio no es responsabilidad del Coordinador del Diseño
4.11.3. Valor
Alcanzar el valor de negocio previsto en los servicios a través del diseño y con un
riesgo aceptable y los niveles de costes previstos
Minimizar los costes laborales asociados con cuestiones de diseño y no tener que
volver a trabajar durante las etapas posteriores del ciclo de vida de servicio
Conseguir el logro que quieren los clientes y la satisfacción de los usuarios y mejorar
la confianza en la información y los servicios recibidos
Asegurar que todos los servicios se ajustan a una arquitectura consistente, que
permita el intercambio de datos y la integración de los servicios y los sistemas
Proporcionar un enfoque mejorado en el valor del servicio, así como los resultados
de negocio y el cliente
Desarrollar una mayor eficiencia y efectividad de todas las actividades de servicios y

procesos de diseño, ayudando así a un mayor volumen de cambios entregados de
manera oportuna y rentable
Lograr una mayor agilidad y mejor calidad en el diseño de soluciones de servicio,
dentro de los proyectos y de cambios importantes
4.11.4. Rol de Coordinación del Diseño
Asumir las Estrategias del Servicio generales y asegurar que se reflejen en la práctica
de Diseño del Servicio y en los Diseños del Servicio que se generan para cumplir los
requisitos de negocio documentados
Diseñar los aspectos funcionales de los servicios y de la infraestructura, de las
aplicaciones, del entorno y de la gestión de datos
Generar diseños de calidad, seguros y flexibles para servicios nuevos o mejorados, la
arquitectura tecnológica, procesos o sistemas de medida que cumplan todos los
requisitos de TI actuales y futuros acordados de la organización
Generar y mantener toda la documentación del diseño, incluyendo diseños, planes,
arquitecturas y políticas
Medir la eficacia y eficiencia del proceso de Diseño del Servicio.
Asegurar el diseño coherente de los servicios adecuados, sistemas de gestión de la
información, arquitectura, tecnología, procesos, información y métricas para
cumplir con los resultados de negocio actuales y futuros y los requisitos
Coordinar todas las actividades de diseño a través de proyectos, cambios, equipos
de apoyo, proveedores, gestión de programas, recursos y conflictos
Planificar y coordinar los recursos y capacidades necesarias para diseñar servicios
nuevos o modificados
Producir los Paquetes de Diseño del Servicio (SDP) en base al Catálogo y/o RFCs
Asegurar que los diseños adecuados de servicios se producen y que son entregados
a Transición del Servicio como se acordó
Gestionar los criterios de calidad, los requisitos y los puntos de transferencia entre
las fases de Diseño, Estrategia y Transición de los Servicios
Asegurar que todos los modelos de servicios y los diseños de servicios se ajustan a la
solución estratégica, gestión de arquitectura, y otras necesidades corporativas
Asegurar que todas las partes adopten un marco común de las prácticas estándar
Controlar y mejorar el rendimiento, en sí mismo, de la etapa del Diseño del Servicio
Definir y mantener las Planear diseños

políticas y métodos individuales
Planear y diseñar los

Coordinar diseños
recursos y capacidades
individuales
Coordinar las
actividades del diseño Monitoriza diseños
individuales
Gestionar los riesgos y
problemas del diseño
Revisar los diseños y
garantizar el Paquete
Mejorar el Diseño del de Entrega del Servicio
Servicio

4.12. El Catálogo de Servicios

4.12.1. Service Catalogue Management (SCM)
El Catálogo de Servicios es un subcomponente de la Cartera de Servicios (SPM) y contiene
información consistente de todos los servicios que ofrece el Portafolio. Solo acceden a él las
personas autorizadas e incluye las siguientes Actividades:
Definir los servicios
Producir y mantener el Catálogo con contenido preciso
Proporcionar información del Catálogo a los grupos de interés
Gestionar la interacción, dependencia y consistencia con SPM
Gestionar la interacción y dependencia mutua entre servicios y aquellos de soporte en el
Monitorizar estos aspectos en el CMS
4.12.2. Objetivos
Es un subcomponente de la Cartera de Servicios (Service Porfolio). Ambos son la columna
vertebral del Ciclo de Vida del Servicio. La Cartera de Servicios se crea en Estrategia del
Servicio pero requiere la cooperación de todas las fases sucesivas.
Su objetivo último es el desarrollo y mantenimiento de un Catálogo con todos los datos
exactos y el estado de los servicios existentes, así como aquellos en operaciones. Es una
parte de la Cartera de Servicios que es visible al cliente.
4.12.3. Ámbito
Acota la parte visible del Catálogo de Servicios a los clientes
Interactúa con los equipos de soporte y los Gestores de Relaciones con el Negocio (BRMs)
Son expertos en las Líneas de Servicios (LOS)
Promueve nuevos servicios en colaboración con los Gestores de Relaciones con el Negocio
(BRM) y son expertos en la integración de los suministradores
Desarrollo y mantenimiento de las descripciones de Paquetes de Servicio (SP) y los servicios
adecuados para el Catálogo de Servicios
Interfaces, las dependencias y la coherencia entre el Catálogo de Servicios y la Cartera de
Servicios (SPM) en general
Las interfaces y las dependencias entre todos los servicios y los servicios de soporte dentro
del Catálogo de Servicios y el CMS
Las interfaces y las dependencias entre todos los servicios y componentes de apoyo y los
elementos de configuración (CI) en el Catálogo de Servicios y el CMS
4.12.4. Valor
Asegurar un entendimiento común de los servicios de TI y mejorar las relaciones entre el
cliente y el Proveedor de Servicios mediante la utilización del Catálogo de Servicios para la
comercialización como herramienta de comunicación
Mejorar la atención de proveedores de servicios (SP) en los resultados de los clientes
mediante la correlación de las actividades internas del SP y los activos de los servicios de
procesos de negocio y los resultados
Mejorar la eficiencia y la efectividad de otros procesos de ITSM mediante el
aprovechamiento de la información contenida o en conexión con el Catálogo de Servicios
Mejorar el conocimiento, la alineación y centrarse en el "valor de negocio” de cada servicio
en toda la organización del SP y sus actividades
4.12.5. Catálogo de Servicios de Negocio y Técnico

El Catálogo de Servicios tiene dos aspectos a diferenciar:
I. El Catálogo de Servicios de Negocio
Ésta es la parte del catálogo que se muestra al cliente.

Contiene los detalles de todos los servicios entregados o a entregar al cliente.
En él se incluyen las relaciones a las unidades de negocio y el proceso de negocio que confía en los
servicios que le brindamos desde TI.
Facilita el desarrollo de un proceso mucho más dinámico y alineado a la SLM, permitiendo que se
desarrolle más en el campo de la Gestión de Servicios a empresas.
II. El Catálogo de Servicios Técnicos
No debe mostrar el Catálogo de los Servicios en operaciones en empresas y no forma parte de la

opinión del cliente.
Contiene los detalles de todos los servicios a entregar a los clientes. Incluye las relaciones a los
Servicios de Soporte, a los servicios compartidos, a los componentes y a los necesarios CIs de
soporte y que deban de estar a disposición del servicio al negocio.
De gran ayuda para construir la relación entre los servicios, SLAs, OLAs y otros acuerdos y
componentes del soporte y todo lo referente a los Requerimientos Técnicos (SLRs).
Algunas organizaciones mantienen un Catálogo de los Servicios a empresas y un Catálogo de
Servicios Técnicos para TI de forma separada.
Organizaciones más maduras mantienen ambos aspectos dentro de un solo Catálogo de Servicios
que sea parte de una lista de los servicios totalmente integrado en la Gestión de Servicios.
Catálogo de Servicios del Negocio

(Clientes)
Proceso 1 Proceso 2 Proceso 3
Servicio Servicio Servicio Servicio Servicio

A B C D E
Servicio de Hardware Software Programas Datos

Soporte
Catálogo de Servicios de TI
(Técnicos)

4.12.6. Entradas
Información de negocio de la organización, de su estrategia y planes de TI.
Análisis de impacto sobre el negocio (BIA).
La Cartera de Servicios (Service Porfolio).
CMS.
Las salidas de otros procesos.
4.12.7. Salidas
Documentación y acuerdo de una “definición de servicio”.
Actualizaciones de la Cartera de Servicios.
Actualizaciones del Catálogo de Servicios.
4.12.8. Sugerencias de Métricas (KPIs)

Número de servicios registrados y mantenidos en el Catálogo de Servicios.
Porcentaje de los que se entregarán y pasan a Transición del Servicio.
Número de diferencias detectadas en la información del catálogo y la realidad.
Porcentaje de mejora en actualizar el Catálogo de Servicios de negocio comparado con los
servicios operativos.
Porcentaje de mejora en actualizar el Catálogo de Servicios Técnico comparado con los
componentes de TI que soportan a los servicios.
4.12.9. Implementación
Lo que pudiera ofrecer más dificultad será el mantenimiento sin errores de la Cartera y el
Catálogo de Servicios.
En principio ayudarán hojas de cálculo o bases de datos antes de integrar el Catálogo de

Servicios Técnicos y de Negocio y la Cartera de Servicios en el Sistema de Gestión de la
Configuración (CMS) y en el Sistema de Gestión del Conocimiento del Servicio (SKMS).
4.12.10. Factores Críticos de Éxito (CSF)

Catálogo de Servicios exactos y reales.
Familiarización de los usuarios del negocio con los servicios proporcionados.
Familiarización de la organización de TI con las tecnologías que soportan los servicios.
4.12.11. Propietario, actividades, métodos y técnicas

Definir los servicios operacionales y registrarlos
Producir y mantener el Catálogo con contenido preciso
Proporcionar información del Catálogo a los grupos de interés
Gestionar la interacción, dependencia y consistencia con SPM (Service Portfolio
Management)
Gestionar la interacción y dependencia mutua entre servicios y aquellos de soporte en el
Monitorizar estos aspectos en el CMS
Gestionar los Servicios como un producto a través del Ciclo de Vida desarrollándolo y
manteniéndolo.

Es el propietario de Service Catalogue y coordina el mismo.

Trabaja con el Gestor de Relaciones con el Cliente enfocado al Portafolio del Cliente.
Acota la parte visible del Service Catalogue a los clientes.
Interactúa con los equipos de soporte, SPs, y Gestión de la Configuración y Activos del
servicio (SACM) sobre sus relaciones, dependencias y CIs contenidos en el SCM Técnico.
Asigna los recursos y lista los servicios de acuerdo a los presupuestos del cliente. Promueve
nuevos servicios para el Diseño de Servicio y a los que están acabados en fase de Transición
de Servicio.
4.12.12. Desafíos
El principal desafío al que se enfrenta el Gestor del Catálogo de Servicios es el de mantener
un Catálogo de Servicios preciso como parte de una Cartera de Servicios, incorporando todas
las vistas de catálogo, como parte de una estrategia global del CMS y SKMS
Un enfoque puede ser el desarrollo independiente de hojas de cálculo o bases de datos antes
de intentar integrar el Catálogo de Servicios y la Cartera de Servicios dentro del CMS o SKMS
Para lograr esto, la cultura de la organización tiene que aceptar que el Catálogo de Servicios y
la Cartera de Servicios son fuentes esenciales de información para todo el mundo dentro de
la organización de TI
4.12.13. Riesgos
Información inexacta en el Catálogo de Servicios.
No está bajo control de Gestión de Cambios.
Poca aceptación del Catálogo de Servicios en su uso en los procesos operativos.
Herramientas y recursos necesarios para actualizar la información.
Acceso deficiente a procesos e información exacta sobre Gestión de Cambios.
Evitar el uso de la Cartera de Servicios y del Catálogo.
Información demasiado detallada como para poder mantenerla.

4.13.Gestión del Nivel de Servicio (SLM)

4.13.1. Meta
Garantizar que se proporciona un nivel acordado de servicio de TI para los servicios actuales y que
los futuros se entreguen de acuerdo a objetivos alcanzables.
4.13.2. Objetivos
Mantiene y mejora continuamente la calidad de los servicios ofrecidos de TI al Negocio a
través de un constante ciclo de los objetivos (KPI).
Mejora las relaciones del negocio entre el Cliente, la propia Organización TI y los
Proveedores.
Mayor flexibilidad y respuesta en la provisión de servicios.
Equilibra las exigencias del cliente y el costo de la provisión de servicio.
Es el responsable de los SLAs, que son acuerdos entre la organización TI y el cliente interno o
externo y se describen los servicios a brindar desde la percepción del cliente y con
transparencia. Y durante el tiempo que dure sirve de estándar para medir y ajustar los
servicios TI.
Tienen estructura jerárquica. Los servicios para toda la organización del cliente los aprueba la
Gerencia y los departamentales se acuerdan con sus responsables.
4.13.3. Ámbito
SLM representa al Proveedor de Servicios de TI ante el Cliente de Negocio y al Negocio ante TI. Su
contacto es bidireccional y tiene que gestionar las expectativas de ambas partes además de
garantizar que la calidad del servicio entregado cumple lo acordado en la SLA.
El proceso debe de incluir diversos elementos entre los que se encuentran:
Cooperación con los procesos de Gestión de Relaciones con el Negocio (BRMs)

Negociación y acuerdo de las futuras necesidades de Nivel de Servicio, así como la
documentación y la gestión de los SLRs de todos los servicios nuevos o modificados
Negociación y acuerdo de los actuales Requisitos de Nivel de Servicio y metas, así como la
documentación y la gestión de SLAs para todos los servicios operativos
Supervisión de OLAs apropiadas para asegurar que los objetivos están alineados con los
objetivos de los SLAs
Revisión de todos los acuerdos con proveedores y contratos que firma Gestión de
Suministradores para asegurar que los objetivos están alineados con los de los SLAs
La prevención proactiva de fallos en el servicio, la reducción de los riesgos y la mejora de la
calidad del servicio, junto con todos los demás procesos
Presentación de informes y gestión de todos los logros de Nivel de Servicio y revisión de
todas los incumplimientos de los SLAs
La revisión periódica y la renovación de los SLAs y OLAs dentro del alcance del servicio
La identificación de oportunidades de mejora para su inclusión en el registro de CSI
La revisión y priorización de las mejoras en el registro de CSI
Fomentar y coordinar el Plan de Mejora del Servicio (SIP)


SLM comprende la planificación, coordinación, redacción, monitorización, acuerdo e informes de
los SLAs, así como la revisión continuada de los logros del servicio para garantizar la calidad
requerida y a un coste justificable
Gestión de Nivel de Servicio (SLM) proporciona una interfaz coherente con el negocio
sobre los asuntos de Nivel de Servicio relacionados con el mismo
Proporciona al negocio los objetivos de servicio acordados y la gestión de la
información necesaria para asegurar que esos objetivos se han cumplido
Si los objetivos no se cumplen, SLM proporciona información sobre la causa del
incumplimiento y los detalles de las medidas adoptadas para prevenir los
incumplimientos recurrentes
SLM ofrece un canal de comunicación confiable y una relación de confianza adecuada
con los Clientes y los representantes del negocio a un nivel táctico
El SLA es un acuerdo entre el Proveedor de Servicios y el Cliente interno o externo en el que
se estipulan los objetivos y responsabilidades mutuas.
El OLA es un acuerdo entre el Proveedor de Servicios y otra parte de la misma organización
que asiste en la provisión de servicios al cliente.
4.13.5. Actividades, Métodos y Técnicas
Diseño de
marcos de trabajo de SLA:
SLA Clientes
SLA Multinivel
Revisión y Requisitos de Nivel
Ajustes de SLA de Servicios (SLR )
(Gestión de Cambios y Documentación
Configuración) Acuerdos con Clientes
Gestión de
Nivel de
Servicio Aumento de
Revisión y Mejora
de Servicios (SIP’s) Satisfacción de
Clientes (Cuestionarios)
Desarrollo de Contactos Elaboración

y relaciones Informes de Servicio
Cartera de Servicios (Reporting)
Determinación, documentos y acuerdos sobre requisitos de nuevos servicios y SLRs:

Creado el Catálogo de Servicios y definida la estructura del SLA se determinan los
SLRs en un borrador. Debe participar el cliente para que no se encuentre con un
hecho consumado.
Monitorización del rendimiento con respecto a la SLA y comunicación de
resultados: El SLA tiene que ser medible y alcanzable para evitar discrepancias y
pérdidas de confianza. Los resultados se deben comunicar al cliente de forma
periódica y acordada. Se deben registrar quejas y elogios y tratar con las partes
interesadas.

Aumento de la satisfacción del cliente: Se debe tener en cuenta la satisfacción del

cliente y para ello hay diseñar los cuestionarios de encuestas.
Revisión y ajuste de acuerdos de soporte: Los SPs dependen a veces del soporte de
terceros, por lo que hay que revisar los OLAs y los UCs periódicamente. Los acuerdos
deben de estar incorporados y autorizados por la Gestión de Cambios e incorporados
en el sistema de Gestión de la Configuración (CMS).
Elaboración de informes de servicio: Se deben diseñar y acordar los mecanismos de
informes y reporte periódicos y serán las entradas para las reuniones sobre servicios.
Deben contener información de los servicios, procesos y resultados con respecto a
los objetivos de negocio que se hayan acordado.
Revisión y mejora de servicios: Hay que mantener reuniones con el cliente sobre la
provisión de servicios haciendo foco en la mejoras para su negocio.
Revisión y ajustes de los SLAs: Todos los acuerdos actuales y los modificados deben
someterse a la Gestión de Cambios y de Gestión de la Configuración y Activos del
Servicio para garantizar que los cambios no invaliden tales acuerdos.
Desarrollo y contactos y relaciones: SLM tiene que infundir confianza en el negocio y
para ello el Catálogo de Servicios permite a SLM hacerlo de forma proactiva y para
ello se llevarían a cabo las siguientes actividades:
Informar y consultar a clientes y gestores sénior.
Mantener actualizada la información en la Cartera de Servicios y en el Catálogo
de Servicios.
Mantener una actitud equilibrada y resolutiva hacia las necesidades de los
clientes.
Impulsar un entendimiento completo del cliente y su negocio.
Realizar encuestas de satisfacción a los clientes y usuarios.
NEGOCIO A NEGOCIO B
3 6
2
proceso de
5 NEGOCIO
proceso de
Negocio 1 Negocio 4
SLR SLA Servicio D

SLA
Servicio B Servicio C
Servicio A Estandares y
Determinar, documentar Monitorizar el plantillas de
y acordar SLR para rendimiento del servicio Realizar revisiones documentos
nuevos o modificados respecto a SLA y y fomentar mejoras
servicios. elaborar informes del dentro del SIP general
Preparar SLAs servicio a la Gerencia
Contribuir al SC
y mantener
S
Desarrollar contactos y
relaciones, registrar y
Comparar, medir y
mejorar la satisfacción Informes de
plantillas de
documentos L
gestionar quejas y del cliente mediante los Servicio
elogios SLAM (Chart)
Catálogo de M
Servicio
Revisar SLAs,
OLAs ámbito del
CONTRATOS
servicio y UCs
Gestión de
Equipo de Soporte Suministradores Suministradores

Los cambios en la Cartera de Servicios, como los requerimientos de negocio

nuevos o modificados o servicios nuevos o modificados
Acuerdos nuevos o modificados, SLR, SLA, OLA o contratos
Reuniones de revisión y sus acciones
Incumplimiento de servicio o de amenazas de incumplimiento
Los elogios y quejas
Actividades periódicas, como la revisión, informes y encuestas de satisfacción del
cliente
Los cambios en la estrategia o en las políticas
4.13.7. Entradas
Información del negocio procedente de los planes de la organización y su

estrategia.
Planes financieros de la organización.
Requisitos del Negocio.
Cartera de Servicios y Catálogo de Servicios.
Información de Gestión de Cambios.
Sistema de Gestión de la Configuración (CMS).
4.13.8. Salidas
Informes del servicio.

Plan de Mejora del Servicio (SIP).
Plan de Calidad del Servicio (SQP).
Plantillas de documentos estándar.
SLAs, SLRs y OLAs.
4.13.9. Desafíos
Uno de los retos que enfrenta el Gestión de Nivel de Servicio (SLM) es el de la
identificación de representantes idóneos de los clientes con los que negociar. ¿Quién
posee el servicio en el lado del cliente?
En algunos casos un gerente único del cliente está dispuesto a actuar como firmante
del acuerdo. En otros casos, puede tomar un poco de negociación o engatusar para
encontrar a un representante como "voluntario” (hay que tener en cuenta que a
menudo los voluntarios quieren expresar su propio punto de vista personal y no
representan un consenso general), o puede que sea necesario llegar a varios
representantes de los clientes para firmar

4.13.10. Riesgos
La falta de precisión de las entradas, de la participación y el compromiso de la
empresa y los clientes
La falta de herramientas adecuadas y los recursos necesarios para documentar,
controlar, informar y revisar SLAs y SLRs
El proceso se convierte en un proceso burocrático, administrativo, en lugar de un
proceso activo y proactivo para entregar beneficios al negocio
El acceso y soporte de las actualizaciones del CMS y SKMS
Evitar el uso de los procesos de SLM
Las mediciones sobre el negocio y los clientes son muy difíciles de medir y mejorar,
por lo que no se registran
Inapropiado desarrollo de relaciones con el negocio de los clientes
Expectativas de los clientes de alta y baja percepción
Comunicación deficiente e inadecuada sobre los logros, con el negocio y los clientes
4.13.11. Métricas (KPIs)
Descenso en el porcentaje de objetivos de SLA no cumplidos.
Aumento en el porcentaje de satisfacción del cliente.
Descenso en el porcentaje de incumplimientos de SLA.
4.13.12. Aptitudes
Gestión de las relaciones interpersonales.
Buena comprensión de los servicios que brinda TI a los clientes.
Gran capacidad de comunicación y de negociación.
Excelente capacidad de tolerancia, flexibilidad y paciencia.
Experiencia en gestión de contratos y con proveedores.
Capacidades administrativas y buena gestión de comunidades de usuarios.
Buena comprensión de los principios y procesos estadísticos.
Capacidades óptimas de presentación.
Buen nivel de razonamiento numérico.
Capacidad de interactuar con toda la organización de TI y del Cliente.
Conocimientos técnicos razonables.
Innovación respecto de la calidad de servicios dentro de las posibilidades de la
organización.
Saber escuchar y saber comunicar los conocimientos.
Equidad y justicia en las relaciones con las otras partes.


4.14.Qué es un Acuerdo de Nivel de Servicio (SLA)

Acuerdo entre un Proveedor de Servicio de TI y un Cliente interno o externo. El SLA describe el
Servicio de TI, documenta los Objetivos de Nivel de Servicio (OLA) y especifica las responsabilidades
del Proveedor de Servicio de TI y del Cliente. Ayudándose del Catálogo de Servicios, Gestión de Nivel
de Servicios (SLM) debe de diseñar la más apropiada estructura de SLA garantizando que todos los
servicios y clientes se alineen a las necesidades de las organizaciones.

Cliente 1 Cliente 2 Cliente 3
Acuerdos a Nivel de Servicios
Gestión del Nivel de Servicios
Servicio Servicio Servicio Servicio Servicio

A B C D E
INFRAESTRUCTURA DE TI
4.14.1. Posibles Opciones de SLA:

SLA Basada en el Servicio
Aquí un SLA 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. Esto podría parecer bastante sencillo. Sin embargo, podrían surgir
dificultades si los requisitos específicos de diferentes clientes variaran para el mismo servicio, o si las
características de la infraestructura implicaran diferentes niveles de servicio (p. ej., el personal de la
sede principal podría conectarse a través de una Metro LAN de alta velocidad, mientras que puede
que las oficinas locales tengan que usar una línea WAN de baja velocidad).
En tales casos, es posible que sea necesario disponer de objetivos independientes dentro de un
acuerdo. También podrían surgir dificultades a la hora de determinar quién debe autorizar tal
acuerdo. Sin embargo, en el caso de que se proporcionen niveles comunes de servicio en todas las
áreas del negocio, p. ej., correo electrónico o telefonía, el SLA basado en el servicio puede
representar un método eficiente a utilizar. También se pueden utilizar múltiples clases de servicio, p.
ej., oro, plata y bronce, para mejorar la eficiencia de los SLAs basados en servicios.

SLA basada en el 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 que
cubran, por ejemplo, el sistema financiero, el sistema contable, el sistema de nóminas, el sistema de
facturación, el sistema de compras, y cualquier otro sistema de TI que usen.
En muchas ocasiones los clientes prefieren este tipo de acuerdos porque todos sus requisitos se
recogen en un único documento. Sólo se requiere normalmente una firma de autorización, lo que
simplifica este paso.
Podría ser conveniente aplicar una combinación de estas estructuras, especificando todos los
servicios y clientes que se cubren, sin solapes o duplicaciones.
SLA Multinivel
Un único SLA puede cubrir varios Servicios de TI o varios Clientes o a Nivel corporativo todos los
Clientes y Servicios. A su vez puede dividirse en tres tipos de SLA diferentes.
Nivel Corporativo
Cubre todos los aspectos genéricos de SLM apropiados para cada cliente en toda la
organización.
Nivel del Cliente
Cubre todos los aspectos de SLM pertinentes para un grupo individuales de clientes o
unidades de negocio, independientemente del servicio que se está usando.
Nivel de Servicio
Cubre todos los aspectos de SLM pertinentes para un servicio específico, en relación con un
grupo de clientes (uno para cada servicio cubierto por el SLA)

4.15.Contenido indicativo de un SLA

Aquí se expone un ejemplo de SLAs y OLAs y de sus contenidos. Como tal ejemplo no es obligatorio
que todos los SLA y OLA contengan todas las secciones que se muestran dentro de los siguientes
documentos de ejemplo. Estas áreas se consideran sugerencias al preparar plantillas de
documentos, ya que sólo se incorporarán en los documentos reales si fueran apropiadas y
pertinentes. Por lo tanto, lo que se incluye a continuación sólo debe considerarse como directrices y
listas de comprobación.
ACUERDO DE NIVEL DE SERVICIO (SLA - Ejemplo)
Este acuerdo se formaliza entre....................................................y………………………
El acuerdo recoge la provisión y soporte de los servicios ABC que... (Breve descripción del servicio).
Este acuerdo estará vigente durante 12 meses a partir de (fecha) hasta (fecha). El acuerdo se
revisará anualmente. Podrían registrarse cambios menores en el formulario al final del acuerdo.
Ambas partes deben firmarlos y gestionarlos siempre a través del proceso Gestión de Cambios.
Firmantes:
Nombre.....................................................................Nombre..........................................
Puesto……………………………..………………………………….....Puesto……..………………………………….
Fecha………………………………………………………………..……..Fecha…………………………………………..
Descripción del servicio:
El Servicio ABC consiste en... (Una descripción más detallada para incluir funciones de negocio clave,
entregable y toda la información relevante para describir el servicio y su escala, impacto y prioridad
para el negocio).
Ámbito del acuerdo:
¿Qué se recoge dentro del acuerdo y que se excluye?
Horario del servicio:
Una descripción del horario en el que los clientes pueden
24 horas x 365 días. 08:00 a 18:00 – (Lunes a Viernes)
Condiciones especiales para las excepciones (por ejemplo, fines de semana, días festivos) y
procedimientos para solicitar ampliaciones del servicio (a quién contactar, normalmente al Centro
de Servicio al Usuario, y cuáles son los periodos de notificación que se requieren).
Se puede incluir un calendario del servicio o hacer referencia a uno.
Detalles de franjas horarias pre acordadas de adecuación y mantenimiento, si éstas impactaran en el
horario de los servicios, junto con detalles sobre cómo deben negociarse y acordarse otras
interrupciones del servicio, por quienes y cuáles son los periodos de notificación, etc.
Procedimientos para solicitar cambios permanentes en el horario del servicio.
Disponibilidad del servicio:
Los niveles objetivo de disponibilidad que el Proveedor de Servicios de TI deberá proporcionar
dentro de horario acordado del servicio. Deben establecerse objetivos de disponibilidad dentro del
horario acordado del servicio expresados como porcentajes (por ejemplo, 99,5%), además de
periodos, métodos y cálculos de medida. Esta cifra puede expresarse para todo el servicio, Servicios
de Soporte, componentes críticos o para todos ellos. Sin embargo, es difícil asociar tales cifras de
disponibilidad en porcentaje con la calidad del servicio, o con las actividades del negocio del cliente.

Por lo tanto, en muchas ocasiones es mejor intentar medir la falta de disponibilidad del servicio en
términos de incapacidad del cliente para realizar sus actividades de negocio. Por ejemplo, 'las ventas
se ven inmediatamente afectadas por un fallo de TI a la hora de proporcionar un servicio de soporte POS
adecuado'. Este fuerte vínculo entre el servicio de TI y los procesos de negocio del cliente es un
signo de madurez en los procesos de SLM y de Gestión de la Disponibilidad.
También deben documentarse los detalles acordados de cómo y cuándo se medirá y se comunicará
y durante qué periodo acordado se hará.
Fiabilidad:
El máximo número de interrupciones del servicio que se pueden tolerar dentro de un periodo
acordado (podría definirse como el número de interrupciones, por ejemplo, cuatro al año, o como
un Tiempo Medio Entre Fallos (MTBF) o Tiempo Medio Entre Incidencias de los Sistemas (MTBSI)).
Definición de lo que constituye una 'interrupción' y cómo éstas se monitorizarán y registrarán.
Soporte al diente:
Deberán documentarse los detalles de cómo ponerse en contacto con el Centro de Servicio al
Usuario, el horario en el que estará disponible, el horario en el que el soporte estará disponible y
qué hacer fuera del horario para obtener asistencia (por ejemplo, soporte telefónico, asistencia
externa, etc.). El SLA también podría incluir la referencia a la Autoayuda por Internet/Intranet y/o al
registro de Incidencias. Deben incluirse métricas y medidas como por ejemplo objetivos de
respuestas por llamadas telefónicas (número de tonos, llamadas perdidas, etc.).
Objetivos para tiempos de respuesta de Incidencias (el tiempo que transcurrirá antes de que alguien
comience a ayudar al cliente, lo que podría incluir tiempos de desplazamiento, etc.).
Una definición de lo que es necesario 'responder' - ¿Es una llamada telefónica devuelta al cliente o
una visita al emplazamiento? - según sea oportuno.
Acuerdos para solicitar ampliaciones de soporte, incluyendo los periodos requeridos de notificación
(por ejemplo, la solicitud debe realizarse al Centro de Servicio al Usuario a las 12 del mediodía para
una ampliación por la noche, a las 12 del mediodía del jueves para una ampliación el fin de semana)
Nota: Tanto los tiempos de respuesta como los de resolución de incidencias se basarán en códigos
de prioridad/impacto de las incidencias. Aquí también deben incluirse detalles de la clasificación de
Incidencias.
Nota: En algunos casos, podría ser apropiado hacer referencia a contactos y contratos con terceros y
a OLAs, aunque esto no debe ser una forma de desviar la responsabilidad.
Puntos de contacto y escalado:
Detalles de los contactos dentro de cada una de las partes implicadas en el acuerdo y los procesos
de escalado y puntos de contacto. Esto también debe incluir la definición de una disconformidad y el
procedimiento para gestionar disconformidades.
Rendimiento del servicio:
Detalles de la capacidad de respuesta esperada del servicio de TI (por ejemplo, tiempos de respuesta
objetivo de la estación de trabajo para tiempos de respuesta medios o máximos de la estación de
trabajo, algunas veces expresados como un porcentaje, por ejemplo 95% en el periodo de dos
segundos), detalles del rendimiento esperado del servicio con respecto a los objetivos en los que se
basa, y cualquier umbral que invalidaría los objetivos.
Esto debe incluir la indicación de los volúmenes de tráfico probables, a través de la actividad,
restricciones y dependencias (por ejemplo, el número de transacciones que se procesarán, número
de usuarios concurrentes, y la cantidad de datos que se transmitirán en la red). Esto es importante
para que se puedan identificar los problemas de rendimiento que hayan sido provocados por unas
prestaciones excesivas, que superan de los términos del acuerdo.

Tiempos de procesamiento de lotes:

Si fuera apropiado, detalles de cualquier tiempo de procesamiento de lotes, tiempos de finalización
y entregables clave, incluyendo tiempos para la entrega de las entradas y el tiempo y lugar de la
entrega del resultado si fuera oportuno.
Funcionalidad (si fuera apropiado):
Detalles de la funcionalidad mínima que se proporcionará y el número de errores de tipos
particulares que se pueden tolerar antes de que se incumpla el SLA. Deben incluirse niveles de
severidad y el periodo de información.
Gestión de Cambios:
Breve mención y referencia a los procedimientos de Gestión de Cambios de la organización que
deben seguirse, como medio de reforzar el cumplimiento. Además, deben incluirse objetivos para
aprobar, manejar e implementar RFCs, normalmente basados en la categoría o urgencia/prioridad
del cambio, y los detalles de cualquier cambio conocido que impactará en el acuerdo, si hubiera.
Gestión de Continuidad del Servicio:
Breve mención y referencia a los Planes de Continuidad del Servicio de la organización, junto con los
detalles sobre cómo podría verse afectado el SLA o referencia a un SLA de Continuidad
independiente, que contenga detalles de cualquier reducción o modificación de los objetivos del
servicio si se produjera una situación de desastre. Detalles de cualquier responsabilidad específica
de ambas partes (por ejemplo, backup de datos, almacenamiento off-site).
Además, detalles de la invocación de planes y cobertura de cualquier problema de seguridad,
particularmente cualquier responsabilidad del cliente (por ejemplo, coordinación de actividades de
negocio, documentación del negocio, backup de PCs independientes y cambios de contraseña).
Gestión de Seguridad:
Breve mención y referencia a la política de Seguridad de la organización (que cubre problemas como
controles de contraseñas, violaciones de seguridad, software sin autorización, virus, etc.). Detalles
de cualquier responsabilidad específica por ambas partes (por ejemplo, Protección Anti Virus,
Firewalls).
Impresión:
Detalles de cualquier condición especial asociada con la impresión o con las impresoras (por
ejemplo, detalles de distribución de la impresión, notificación de grandes operaciones centralizadas
de impresión, o manejo de cualquier artículo de escritorio especial de alto valor).
Responsabilidades:
Detalles de las responsabilidades de las distintas partes implicadas dentro del servicio y sus
responsabilidades acordadas, incluyendo al proveedor de servicio, cliente y usuarios.
Imputación de costes (si fuera aplicable):
Deben incluirse los detalles de cualquier fórmula utilizada para la imputación de costes, periodos de
Imputación de costes, o referencia a documentos de la política de imputación de costes, junto con
procedimientos de facturación y condiciones de pago, etc.
Esto también debe incluir detalles de cualquier penalización financiera o bonificación que se pagará
si los objetivos del servicio no cumplieran las expectativas. Cuáles serán las
penalizaciones/bonificaciones y cómo se calcularán, acordarán y recopilarán/pagarán (más
apropiado para situaciones de terceros). Si el SLA incluyera una relación de externalización, los
costes deberán detallarse en un Apéndice ya que normalmente se recogen mediante provisiones
comerciales confidenciales.

Debe tenerse en cuenta que las cláusulas de penalización pueden generar sus propias dificultades.
Pueden generar una barrera con los socios si se invocaran injustamente basándose en un tecnicismo
y también pueden hacer que el personal del proveedor de servicio sea reacio a admitir errores por
temor a las penalizaciones que se están imponiendo.
Esto puede representar, a menos que se utilice adecuadamente, una barrera para desarrollar
relaciones eficaces y para resolver problemas.
Informes y revisiones del servicio:
El contenido, frecuencia, plazos y distribución de los informes del servicio, y la frecuencia de las
reuniones de revisión del servicio acordadas. Además, los detalles de cómo y cuándo se revisarán los
SLA y los objetivos asociados del servicio, incluyendo quién estará implicado y con qué capacidad.
Glosario:
Explicación de cualquier abreviatura o terminología utilizada para mejorar el entendimiento del
cliente.
Hoja de modificaciones:
Para incluir un registro de cualquier modificación acordada, con detalles de modificaciones, fechas y
firmantes. También debe incluir el histórico completo del cambio del documento y de sus revisiones.
Debe tenerse en cuenta que los contenidos del SLA incluidos anteriormente son sólo ejemplos. No
deben considerarse como exhaustivos u obligatorios, aunque proporcionan un buen punto de inicio.

4.16.Acuerdo de Nivel Operacional (OLA) - Ejemplo

Este acuerdo se formaliza entre....................................................y……………………………
El acuerdo recoge la provisión del servicio de soporte y proporciona... (Breve descripción del
servicio).
Este acuerdo estará vigente durante 12 meses a partir de (fecha) hasta (fecha).
El acuerdo se revisará anualmente. Podrían registrarse cambios menores en formato al final del
acuerdo siempre que se estén acordados por ambas partes y gestionados a través del proceso
Gestión de Cambios.
Firmantes:
Nombre.........................................................................Nombre...........................................
Puesto………………………… ……………………………………….…….Puesto……………….………………………...
Fecha. ...........................................................................Fecha…………………………………………
Detalles de modificaciones previas:
Descripción del servicio de soporte:
Explicación integral y detalles del servicio de soporte que se está proporcionando.
Ámbito del acuerdo:
¿Qué se recoge dentro del acuerdo y que se excluye?
Horario del Servicio:
Una descripción del horario en el que se suministra el servicio de soporte.
Objetivos del servicio:
Los objetivos para la provisión del servicio de soporte y los procesos de información y revisión y
frecuencia.
Puntos de contacto y escalado:
Detalles de los contactos dentro de cada una de las partes implicadas en el acuerdo y los procesos
de escalado y puntos de contacto.
Responsabilidades y tiempos de respuesta del Centro de Servicio al Usuario y ante incidencias:
Las responsabilidades y objetivos acordados para el progreso y resolución de Incidencias y de
soporte del Centro de Servicio al Usuario.
Responsabilidades y tiempos de respuesta ante problemas:
Las responsabilidades y objetivos acordados para el progreso y resolución de Problemas.
Gestión de Cambios:
Las responsabilidades y objetivos acordados para el progreso e implementación de cambios.
Gestión de la Entrega:
Las responsabilidades y objetivos acordados para el progreso e implementación de entregas.
Gestión de la Configuración:
Las responsabilidades para la propiedad, provisión y mantenimiento de información precisa de
Gestión de la Configuración.
Gestión de la Seguridad de la Información:
Las responsabilidades y objetivos acordados para el soporte de las Políticas de Seguridad y el
proceso de Gestión de la Seguridad de la Información.

Gestión de la Disponibilidad:
Responsabilidad para garantizar que todos los componentes dentro del dominio de soporte se
gestionen y se les dé apoyo para cumplir y continuar cumpliendo los objetivos de disponibilidad del
servicio y de sus componentes.
Gestión de la Continuidad del Servicio:
Responsabilidad para garantizar que todos los componentes dentro del dominio de soporte tengan
planes de recuperación actualizados y probados que den soporte a requisitos de negocio acordados
y documentados. Esto podría incluir la asistencia en la evaluación técnica del riesgo y de su gestión y
mitigación posteriores.
Gestión de Capacidad:
Responsabilidad para dar soporte a las necesidades del proceso Gestión de Capacidad en el ámbito
acordado de su dominio técnico.
Gestión del Nivel de Servicio:
Asistencia con la definición y acuerdo de objetivos apropiados dentro de SLAs, SLRs y OLAs,
concernientes a componentes en el ámbito de su dominio técnico.
Gestión de Suministradores:
Asistencia con la gestión de contratos y suministradores, principalmente en el ámbito de su dominio
técnico.
Provisión de información:
La provisión y mantenimiento de información precisa, incluyendo datos financieros para todos los
componentes en el ámbito acordado de su dominio técnico.
Glosario:
Explicación de cualquier abreviatura o terminología utilizada para mejorar el entendimiento de los
términos contenidos dentro del acuerdo.
Hoja de modificaciones:
Para incluir un registro de cualquier modificación acordada, con detalles de modificaciones, fechas y
firmantes. También debe incluir detalles de una historia del cambio completa del documento y de
sus revisiones.
4.16.1. Estructura de soporte de los SLAs

Contrato de Soporte (UC): Un Contrato entre un Proveedor de Servicio de TI y un Proveedor
de Servicios de Terceros. El Tercero proporciona bienes o Servicios que soportan la entrega de un
Servicio de TI a Clientes. El Contrato de Soporte define el alcance, los objetivos, las
responsabilidades y las dependencias que son requerirlas para alcanzar los Objetivos de Nivel de
Servicio en un SLA.
Acuerdo a Nivel Operacional (OLA): Consiste en el Acuerdo entre un Proveedor de Servicios
y otra parte de la misma Organización. El OLA contiene la descripción de los Servicios TI que se
ofrecen a los Clientes, e incluye la definición de los bienes y Servicios que se proveen, así como los
compromisos de ambas partes. Por ejemplo, podrá haber un OLA:
Entre la Unidad de TI y el departamento de Compras, para la obtención de hardware en
plazos previamente comprometidos.
Entre el Centro de Servicio al Usuarios y un Grupo de Soporte para la realización de la
Resolución del Incidente en plazos previamente acordados.

4.17. Plantilla para confeccionar un (OLA) y/o (SLA)

“Operating Level Agreement”
Consideraciones previas de este ejemplo
Esta plantilla está diseñada para representar todos los Acuerdos de Niveles de Operativos (OLA) de
sus siglas del inglés “Operations Level Agreement” entre departamentos internos de TI.
Se detallan responsabilidades y procedimientos que deberán seguir estos departamentos cuyo

propósito es proveer servicios de TI a todos los usuarios de la Organización.
El objetivo que esta plantilla es representar dichos acuerdos de manera clara y concisa y que sirva de
herramienta de apoyo para su implementación y seguimiento.
¿Cómo usar esta plantilla?

 Algunas secciones pueden no aplicar al tipo de acuerdo o servicio que quiera representar.
Habrá que eliminar aquellas que no se usen. Recuerde que tanto los SLAs como los OLAs
deben ser lo más sencillos posibles.
 El texto en negrita indica instrucciones.
 El texto en cursiva indica referencias cruzadas que en según qué casos habrá que
modificar o eliminar.
 El texto subrayado contiene ejemplos que deberán ser ajustados.
Introducción
En esta plantilla se asume que existen dos departamentos internos de TI uno el destinatario del
servicio (Departamento A) y otro el proveedor del mismo (Departamento B).
Este “Operating Level Agreement” (OLA) describe el servicio de soporte de TI provisto por
[Departamento B], <Servicio a proveer>. El principal objetivo de este OLA es documentar los
servicios a prestar y los procesos asociados al mismo para asegurar que éstos se presten en el
tiempo y la forma previstos.
Partes
Describa exhaustivamente las partes alcanzadas en este acuerdo. Recuerde que la omisión de
un elemento indica que está excluido del acuerdo.
Las partes afectadas en este acuerdo son:

<Oficina A del [Departamento A]>
<Departamento X del [Departamento A]>
<Sucursales K, Y, y Z del [Departamento A]>
No termine la lista con “y otros”, “etc.” No dejar lugar a ambigüedades.
Contexto
Describa el entorno operativo dentro del cual se desarrollara el <Servicio a prestar> indique
todo lo que a su criterio sea relevante para definir el ambiente sobre el cual está basado el
acuerdo.

Referentes
Liste las personas que intervienen en la definición y el establecimiento del acuerdo con todos
sus datos
[Departamento A]
<Nombre> <Nombre>
<Cargo> <Cargo>
<E-mail> <E-mail>
<Teléfono> <Teléfono>
[Departamento B]
<Nombre> <Nombre>
<Cargo> <Cargo>
<E-mail> <E-mail>
<Teléfono> <Teléfono>
Alcance - Términos y condiciones
Vigencia
Este acuerdo es válido desde la fecha de inicio indicada y hasta que una de las partes
[Departamento A] o [Departamento B] indiquen la necesidad de modificarlo o sustituirlo. En
ese caso la fecha de finalización de la vigencia del presente se establecerá oportunamente y de
común acuerdo.
Fecha de inicio: <Fecha de inicio>
Revisiones
Un representante de cualquiera de las partes puede solicitar de manera escrita la revisión del
presente acuerdo en cualquier momento. De no mediar una solicitud de revisión, se establece
una frecuencia Trimestral. La organización de la reunión de revisión estará a cargo del
<Departamento A o B> la cual deberá hacerse efectiva antes del quinto día hábil del mes
correspondiente. De las reuniones de revisión saldrá un Acta con lo acordado en las mismas,
también firmado por las partes e indicando la fecha propuesta para la próxima revisión.
Horario de cobertura
Días Horarios Exclusiones/excepciones

Lunes a Viernes De: <Hora desde> Feriados nacionales
A: <Hora hasta> De: <Hora desde>
A: <Hora hasta>
Sábados De: <Hora desde> Feriados nacionales
A: <Hora hasta>
Domingos De: <Hora desde> Feriados nacionales
A: <Hora hasta>

Nivel de Servicio
Meta
El [Departamento B] dará respuesta a los requerimientos del [Departamento A] solicitados del
software de registro y/o e-mail dentro de:
1 hora a los incidentes clasificados como urgentes

2 horas a los incidentes clasificados como de alta prioridad
4 horas a los incidentes clasificados como de media prioridad
8 horas a los incidentes clasificados como baja prioridad
Prioridad Tiempo de respuesta Tiempo de escalamiento

Urgente 1 hora 30 minutos
Alta 2 horas 1 hora
Media 4 horas 2 hora
Baja 8 horas 4 horas
Nota: Los tiempos están indicados dentro del horario de cobertura del servicio a excepción de los
de prioridad Urgente y Alta para los que la finalización del horario no implica la interrupción la
cuenta del tiempo de respuesta
Servicios soportados
Especifique todos los servicios comprendidos en el acuerdo, por ejemplo:
Detalle del hardware comprendido (un listado del mismo debe adjuntarse en el
Anexo A).
Detalle de los servicios centralizados.
Servicios del ambiente de escritorio (por ejemplo instalación, actualizaciones,
mudanzas)
La sintaxis del ítem puede ser la siguiente:
El [Departamento B] acuerda proveer el <Servicio a proveer> al [Departamento B] con el
siguiente detalle de actividades y alcances de las mismas:
Incluir el detalle completo de las actividades y sectores de usuarios comprendidos.
Responsabilidades de ambas partes

[Departamento A]
Describir todas las tareas y procedimientos que deben cumplir ambas partes, por ejemplo:
[Departamento A] acuerda lo siguiente:
Seguir/Cumplir los procedimientos correspondientes:
Determinar el adecuado grado de prioridad.
Requerir con anticipación definir cuál es el tiempo suficiente para una adecuada
programación de las tareas de servicios especiales (por ejemplo, instalación de
equipos nuevos, soporte fuera de horario)
Conocer y cumplir las políticas de uso de los recursos informáticos descriptos en
indicar la fuente donde se describe la Política de Uso.
Estar dispuesto y disponible para ampliar información crítica dentro de los <x>
minutos de reportado el incidente

[Departamento A]
Estas pueden ser categorizadas de acuerdo con las distintas funciones a desarrollar.
[Departamento B] acuerda lo siguiente:
Cumplir los tiempos de respuesta asociados con cada nivel de prioridad asignado.
Generar y entregar al [Departamento A] informes de gestión periódicos para
monitorear el avance del cumplimiento de los objetivos.
Mantener y disponer de personal entrenado técnicamente en la plataforma a
soportar.
Programar tareas de mantenimiento en momentos de baja o nula actividad de
usuarios. Ausencia de usuarios (entre 23 PM. y 5 AM)
Medición e Informes
Detallar la manera en que el servicio va a ser monitoreado, cómo se van a obtener los valores de
los indicadores establecidos, con qué frecuencia, cuál será el método de cálculo para comparar
con la meta establecida, cuál será la herramienta utilizada para dicha medición.
Especificar la manera en que los valores de la medición serán informados del [Departamento B] al
[Departamento A].
Informe Contenido Frecuencia Vía

Nivel de % de disponibilidad del sistema Mensual Impreso
Servicio % de incidentes resueltos E_mail
Tiempo de respuesta por tipo de criticidad
Tareas de mantenimiento realizadas
Cambios en el equipo de trabajo
Evaluación del Desvío detectados Trimestral Impreso
servicio Análisis de los desvíos E_mail
Propuestas de mejoras
Servicios Programados
Los servicios que se enumeran a continuación, son de carácter programado, es decir, deberán ser
solicitados por el [Departamento A] al [Departamento B] con un mínimo de <X> días de
anticipación. Asimismo [Departamento B] responderá con el acuse de recibo dentro de las
siguientes <X> horas.
Detalle las tareas comprendidas en este título, por ejemplo instalación de lotes de equipos nuevos
o mudanza física de equipos.
Circuito de tratamiento de incidentes

Describir en detalle los pasos que recorre el incidente desde los previos dados por el
[Departamento A] antes de la solución al [Departamento B] hasta el momento en que el incidente
es resuelto y el usuario notificado.
Incluir un diagrama donde se vea de forma muy gráfica el flujo de la información

Firmas
La firma del presente acuerdo implica el conocimiento y la aprobación de todos los términos y
condiciones incluidos en el documento.
[Departamento A]
............................................................. ........................................ .................................

............................ ............... ........
Firma y aclaración o sello Cargo Lugar y Fecha
[Departamento B]
............................................................. ........................................ .................................

............................ ............... ........
Firma y aclaración o sello Cargo Lugar y Fecha
Anexo A: Hardware y Software Soportados
Estructura y contenido de ejemplo
Hardware Soportado
PCs Desktops, Portátiles y Personal Digital Assistants (PDAs).
Impresoras y scanners.
Equipamiento de redes, cables de red, hub, switches y routers.
Servidores Intel.
Servicio asociados al hardware

Al equipamiento antes descripto se le brindará los siguientes servicios:
Asesoramiento (detallar alcance)
Instalación (detallar alcance)
Actualización (detallar alcance)
Mudanzas (detallar alcance)
Reparación (detallar alcance)
Hardware no soportado
Equipamiento no incluido dentro del presente acuerdo y que no será soportado:
Fotocopiadoras
Equipos de fax y telefonía
Cableado desde el Hub a la boca de red del puesto del usuario.
Software soportado
La siguiente lista detalla el software comprendido en el servicio:
Software de PC Desktop listar el software estándar
Servicios centralizados como Mail, File Server, Print services, Internet (detallar los
servicios)

Servicios de software
Al software antes descripto se le brindará los siguientes servicios:
Capacitación (detallar alcance)
Instalación (detallar alcance)
Actualización (detallar alcance)
Software no soportado
Software no incluido dentro del presente acuerdo y que no será soportado:
Mainframe
Software de PDAs
Software desktop no incluido dentro del estándar corporativo

4.17.1. Resumen de Gestión de Nivel de Servicios

Objetivos - Mantener y mejorar la calidad de los servicios de TI:
o Mediante un ciclo continuo de acuerdos, monitorización y reporte de logros de servicio
o Fomentar acciones para erradicar un servicio inmaduro
o En línea con la justificación de negocio y su repercusión en costes
- Desarrollar una mejor relación entre la organización de TI y sus clientes
- Encontrar el equilibrio entre la demanda de servicios TI (Cliente) y el suministro de TI mediante el
entendimiento de los requisitos del negocio y el entendimiento de las capacidades de TI
Procesos - Establecer el proceso
o Planificación del proceso
 Designar el Gestor de Nivel de Servicio y a cualquier otro personal de apoyo
 Establecer una misión y definir un objetivo y alcance
 Iniciar una campaña de concienciación para conseguir respaldo
 Definir roles, tareas y responsabilidades
 Cuantificar actividades, recursos, financiación y criterios de calidad
 Identificar riesgos
 Ayudar a Planificar un Catálogo de Servicios y una estructura de SLA
 Desarrollar un formato de SLA piloto
 Identificar herramientas de soporte
 Definir y acordar niveles de prioridad para los incidentes y vías de escalado
 Planificar las capacidades de monitorización
 Establecer la percepción inicial de los servicios
 Revisar los Acuerdos de Nivel Operacional (OLA) y Contratos de Soporte (UC)
o Implementación
 Generar un Catálogo de Servicios
 Establecer y gestionar las expectativas
 Plantear la estructura de los SLA
 Establecer los Requisitos de Nivel de Servicio (SLRs) y describir el Acuerdo de Nivel de
Servicio (SLA)
 Revisar y concretar los términos de los SLA
 Buscar un acuerdo
 Establecer las capacidades de monitorización
 Revisar OLAs y UCs
 Definir los procesos de reporte y revisión
 Publicitar la existencia de los SLA
- Implementar SLA
o Ayudar a generar el Catálogo de Servicios
 Formular las descripciones de los servicios
 Orientarlo a los clientes
 Utilizarlo como base para folletos comerciales
 Incluir los niveles generales de servicio
 Descripción y funcionalidad del servicio
 Tiempos del servicio
 Entregables
 Tiempos de mantenimiento
 Tiempos de soporte
 Objetivos de calidad
 Procedimientos de petición, cambio y continuidad
 Precio genérico y cargos por defecto / modificaciones adicionales
o Gestión de expectativas
 Gestionar las expectativas del cliente
 Recuerde: Los SLA son sólo documentos
 Desarrollar un grado de paciencia en cuanto a las expectativas
 La imputación de cargos debería modificar la demanda del cliente
o Plantear la estructura de los SLA
 Utilizar un catálogo como ayuda
 Opciones posibles: Basado en el servicio, Basado en el cliente, SLA de nivel múltiple
o Recoger SLRs y redactar SLA
 La hoja de Requisitos de Nivel de Servicio (SLR) recoge los requisitos del cliente sobre los
servicios técnico
 En esta fase del proceso:
 Evaluar oportunidades internas de la organización de TI
 Evaluar contratos con suministradores

o Buscar Acuerdos:
 Gestión de relaciones
 Contacto regular, el cliente quiere ser tratado como un VIP
 La relación es más importante que el SLA
 El Proveedor de Servicios TI es un socio de negocio
 Ayuda a desarrollar las oportunidades estratégicas de negocio
Acuerdos y contratos TI SUMINISTRADOR

CLIENTE
Catálogo de Servicios Requisitos de Nivel de Servicio (SLR)
Especificaciones del servicio (SSS)
Informes del servicio Programa de Mejora del servicio (SIP)
Acuerdo de Nivel de Acuerdo de Nivel Operacional (OLA) Contratos de
Servicio (SLA) Soporte (UCs)
o SLA: Lo conciso es bonito

 Escrito desde la perspectiva de los clientes, en sus términos, de tal manera que ellos sean
capaces de manejarlo
 Formular acuerdos medibles
 Debería ser muy formal frente a “lo mejor que se pueda”
 Presentación formal y contenido profesional
 Debería indicar las responsabilidades de ambas partes
 Nivel de expectativas realista
 Debería cubrir un ciclo de alrededor de 1 año
o Elementos de un SLA
 General:
 Introducción (partes, firmas y descripción del servicio)
 Reporte y revisión:
 Contenido, Frecuencia e incentivos y personalizaciones)
 Soporte:
 Horas de servicio, términos de soporte, procedimientos de cambio, escalado
 Provisión:
 Disponibilidad, Fiabilidad, Producto, Tiempos de respuesta de transacciones,
Continuidad y Seguridad Imputación de Cargos.
- Gestionar la marcha del proceso
o Procesos de Informes y Revisión
 Volumen de negocio (pedidos, contratos)
 Intervalos de tiempo (tiempo de respuesta-tiempo de ciclo-tiempo de entrega)
 Calidad (Errores-recepciones, quejas)
 Fiabilidad (tiempo medio entre fallos)
 Disponibilidad (Tiempo de atención, tiempo medio de reparación)
 Seguridad (Física, encriptados, vigilancia, confirmaciones,”loggin”)
 Satisfacción del cliente (cuestionario, periodo de formación, formación requerida)
o Publicitar el SLA (¿Por qué es tan importante?)
 Informar con detalle al Centro De Servicio A Usuarios y a otros grupos de soporte
 Recoger tablas de los objetivos claves de los SLAs
 Incluir objetivos como umbrales y alertas automáticas en las herramientas de soporte
 Hacerlos públicos para la comunidad de usuarios
o Plan de Calidad del servicio
 El Plan de Calidad del Servicio (SQP) es:
 Una descripción interna del servicio, de las responsabilidades y de los tiempos
de entrega internos para cumplir con el Nivel de Servicios acordado.
 Orientado al personal de TI
 Incluye detalles de las hojas de especificación del servicio (SSS)
- Realizar revisiones periódicas
o Informe del servicio
 Visión global integrada del soporte de los servicios
 Entradas desde otros procesos
 Tendencias y recomendaciones
 Resumen ejecutivo que debería ser conciso y escrito en lenguaje de cliente
 Frecuencia periódica fija (de acuerdo a los SLA)
o Discutir los resultados del servicio
 Asuntos:
 Evaluación de cambios y problemas
 Tendencias, expectativas y recomendaciones
 Resultados

 Momentos:
 Discusión de los informes del servicio
 Evaluación periódica de la relación cliente servidor
 Redacción del plan anual
 Tanto con la dirección del cliente como con los usuarios
Beneficios - Permite el establecimiento de relaciones más profesionales mediante SLA medibles y realistas
- Facilita el equilibrio entre los requisitos de servicio de los clientes y los costes y complejidad de la provisión de
tales servicios
- Mejora la especificación sobre los recursos de TI
- Se reduce la demanda no predecible
- Se recortan los costes de adquisición, mediante la mejora de la comunicación y la revisión con Gestión de
Suministradores
- Ayuda a establecer Líneas de Referencias (BL) para mejoras del servicio, lo que lleva una mayor satisfacción
del cliente
- Facilita la resolución de discrepancias de manera rápida y objetiva
Obstáculos - Que los clientes tengan dificultad para identificar requisitos
- Que TI tenga dificultad para identificar al cliente
- A menudo no están en funcionamiento las disciplinas necesarias, ni están integradas con la Gestión de Nivel
de Servicios
- Las diferencias entre control de costes e imputación de Cargos no son siempre apreciadas por los clientes
internos
- A menudo la inversión esta embebida en un amplio presupuesto y no se enfoca en un SLA especifico, lo que
dificulta la mejora
- A menudo los directivos son demasiado ambiciosos pero no están dispuestos a invertir en los procesos de
apoyo
- Falta de disciplina de los equipos de soporte
Indicadores - Criterios
claves del o Nivel de aceptación de objetivos medibles
rendimiento o Simplicidad, visibilidad y eficacia
(KPIs) o Que esté directamente relacionado con el objeto establecido
- La calidad se mide desde la perspectiva de cliente
- Los datos como los tiempos de reacción, tiempo de escalado y tiempos de soporte, deberían hacerse medibles
- Los informes deberían elaborarse regularmente (de acuerdo en los SLA)
- Los informes deberían incluir información que refleje los niveles de soporte actualizados y las últimas
tendencias
Mejores - Enfatizar la contribución al éxito del negocio, en contraposición a aspectos de TI
Practicas - Diferenciar claramente la Gestión de Nivel de Servicios (proceso) y los acuerdos de Nivel de Servicio
(Contrato)
- Basar la recuperación de costes en el SLA, en contraposición al cargo del informe
- Construir los SLA con y para las unidades de negocio, utilizando lenguaje común
- Implementar SLM para comenzar el diseño y finalizar con la medición de un servicio
- Establecer SLAs sólo dentro del contexto de una disciplina de Gestión de Nivel de un Servicio
- Formular relaciones contractuales con suministradores (internos y externos) que sean consistentes con los
SLAs
- Ayudar a crear y mantener el Catálogo de Servicios
responsabilidades
- Negociar y acordar con el cliente y Proveedor de Servicios TI cualquier Requisito del Nivel de Servicio
- Formular, acordar y mantener las estructura de Gestión de Nivel de Servicios (SLA,OLA, UC)
- Analizar, revisar y reportar el rendimiento y los logros del servicio
- Organizar y mantener reuniones regulares sobre el Nivel de Servicio con el cliente y el Proveedor de Servicios
Roles y
de TI
- Iniciar cualquier acción necesaria para mejorar y mantener el Nivel de Servicio
G.de Incidencias Reporte SLA
G. de Problema Reporte, Info de problemas SLA, info de servicio
G. de Cambios Reporte, Información sobre Cambios SLA, RFC Evaluación de
Impacto
G. de la Configuración y Activos del Servicio Reporte SLA, SLR
G. de Entregas y Despliegues Reporte SLA
G. de la Capacidad Reporte, Análisis de capacidad SLA, SLR
G. de la Continuidad Reporte SLA, SLR
G. de la Disponibilidad Reporte, , Estrategias de continuidad SLA, SLR
G. Financiera de Servicios de TI Reporte, Análisis de costes SLA

Gestión de la
Coordinador Disponibilidad
Del diseño Gestión del
Catálogo
Gestión
Financiera de los Gestión de
Servicios TI la Capacidad
Gestión de
Nivel de
Servicio
Gestión de
Incidencias
Gestión de Relaciones
Con el Negocio (BRM)
Gestión de
Seguridad
Gestión de la Gestión de
Continuidad Suministradores

4.18.Gestión de la Capacidad
4.18.1. Meta
Garantizar que en todas las áreas de TI haya siempre una capacidad a coste aceptable y que se
corresponda con las necesidades actuales y futuras del Negocio.
4.18.2. Objetivos
Crear y mantener un Plan de Capacidad que refleje las necesidades presentes y
futuras del negocio.
Fundamentalmente pone a disposición de clientes, usuarios y a los propios
departamentos internos de TI los recursos informáticos necesarios para desempeñar
de una manera eficiente sus tareas y sin incurrir en costes desproporcionados.
Tiene por encargo que todos los servicios de TI estén asegurados por capacidad de
proceso, de almacenamiento y de procesos en un momento justo.
Debe entender los Requerimientos actuales, futuros y cambiantes del negocio y los
actuales de la operación y documentarlos en el PLAN DE CAPACIDAD.
Desarrollar planes de capacidad acordes a los niveles acordados en los SLAs.
La sincronización entre Capacity Management (CM), Service Portfolio (SPM) y Service Level
Management (SLM) dentro de Diseño del Servicio es esencial.
4.18.3. Ámbito
La mayoría de las gestiones operacionales pasan por el soporte de redes y servidores y deben
proporcionar información valiosa a la Gestión de la Capacidad.
Gestión de Capacidad también hace foco en la capacidad de almacenamiento y entornos.
Podría participar también en algunos aspectos de recursos humanos en cuanto que la escasez de los
mismos en un determinado servicio puede llevarnos al incumplimiento del SLA u OLAs. Pero la
organización de los RRHH no es su responsabilidad, sería, en todo caso, del Jefe del Proyecto.
Debería tener una relación de entrada en la Cartera de Servicios ya que es en la Estrategia del
Servicio donde se trazan los planes de la organización. Tiene una estrecha relación con la Estrategia
del Servicio, pues Gestión de Capacidad se basa en planes de la organización que tienen su origen en
la estrategia
Otros procesos perderán eficacia si no consultan información a Gestión de la Capacidad, como es el
caso de Gestión de Cambios.
Es el punto central para todos los diseños que pasen por Capacidad, Procesamiento y
Rendimiento
Monitorización de los patrones de actividad empresarial a través del desempeño, la
utilización y el rendimiento de los servicios de TI
La realización de actividades de ajuste para hacer el uso más eficiente de los recursos
de TI
Influir en la demanda junto con Gestión Financiera de los Servicios de TI y el proceso
de Gestión de la Demanda
Ayudar con la identificación y resolución de las incidencias y los problemas asociados
con el servicio o la capacidad de los componentes o el rendimiento
La mejora proactiva de servicio o rendimiento de los componentes, siempre que sea
con un coste justificable


El proceso de Gestión de la Capacidad exige encontrar el equilibrio entre el suministro y la demanda
y costes frente a recursos necesarios.
Basándose en consultas a los clientes y a través de SLA puede desarrollar el Plan de Capacidad para
la Gerencia que responderá a las necesidades actuales y futuras de los clientes y los negocios.
Mejorar el rendimiento y la disponibilidad de los servicios según las necesidades del
negocio, ayudando a reducir incidentes y problemas sobre la capacidad
Garantizar la capacidad y desempeño requeridos con un coste efectivo
Contribuir a la satisfacción del cliente y la productividad del usuario, garantizando
que la capacidad y el desempeño respecto a los niveles de servicio se cumplen
Apoyar a un diseño eficiente y efectivo y a la transición de servicios nuevos o
modificados con actividades de gestión proactiva
Mejorar la fiabilidad de los presupuestos de capacidad relacionada con el uso de un
plan de visión de futuro
Mejorar la capacidad del negocio para seguir una estrategia de responsabilidad
ambiental mediante el uso de tecnologías verdes
4.18.5. Actividades, métodos y técnicas

Las actividades pueden ser:
Reactivas como:
Monitorización
Medición
Proactivas como:
Predicción de requisitos futuros
Generación de tendencias
4.18.6. Subprocesos
GESTIÓN DE LA
CAPACIDAD
DEL NEGOCIO
(BCM)
GESTIÓN DE LA ACTIVIDADES
CAPACIDAD ACTIVIDADES
DEL SERVICIO DE GESTIÓN
(SCM) ITERATIVAS TÉCNICAS DIMENSIONA- CONTINUADA
DE MIENTO
MODELADO DE
GESTIÓN DE LA
CAPACIDAD APLICACIONES
DE LOS COMPONENTES
(RCM)
Sistema de
ELABORACIÓN DEL PLAN DE LA Información para
CAPACIDAD Gestión de la
Capacidad
Cubriendo todos los aspectos de (CMIS)
BCM, SCM y RCM

4.18.7. Ciclo del Modelado
Mejorar la Planificar
Revisar la
capacidad Datos Nueva
Capacidad y
de servicios y Técnicos capacidad
rendimiento
componentes
BASEDE
BASE DE
DATOSDE
DATOS DELA
LA
CAPACIDAD
CAPACIDAD
(CDB)
(CDB)
Datos e
Informes de Plan de
capacidad y Capacidad Previsiones
rendimiento
4.18.8. Actividades Iterativas
AJUSTE
IMPLEMENTACIÓN ANÁLISIS
MONITORIZACIÓN
Umbrales de
Umbrales
utilización Informes
SLM Informes de
de recursos excepciones de
excepciones
SLM utilización de
Sistema de recursos
Informacion para
Gestión de la
Capacidad
(CMIS)
4.18.9. Dimensionado de Aplicaciones
Estimar los requerimientos de recursos para soportar una propuesta de cambio en una o en varias
aplicaciones y con ello asegurar que se alcanzan los niveles de servicio requeridos.
Contribuir al diseño de un nuevo SLA y SLR o en sus revisiones.
Determinar la capacidad del hardware necesaria para soportar las aplicaciones nuevas o actualizadas

4.18.10. Modelado
Regla simple (análisis del pulgar).
Proyección lineal (análisis de tendencias).
Modelo analítico.
Modelo de simulación.
Evaluación con Línea de Referencia (Benchmarking).
Utilizados para contestar preguntas de . . .
¿Qué ocurre si...?
4.18.11. Entradas al Plan de Capacidad
4.18.12. Actividades de soporte de la Gestión de la Capacidad

Las actividades ya sean reactivas o proactivas deben ejecutarse rápidamente por lo que se deben
incluir las siguientes.
Ajuste y optimización.
Monitorización de la utilización.
Monitorización de los tiempos de respuesta.
Análisis.
Implementación.
Explotación de nuevas tecnologías.
Diseño de capacidad de recuperación.
Gestión de umbrales.
Y gestionar la demanda caso de no haberse implementado en la fase de la Estrategia del Servicio el
proceso de Gestión de la Demanda.

Las actividades de la Gestión de la Capacidad pueden tener como disparadores:
Interrupciones de servicios.
Avisos de capacidad y rendimiento.
Servicios nuevos o modificados.
Cambios en los planes de negocio en las estrategias.
Ajustes de SLAs, OLAs y UCs.
4.18.14. Entradas
Información desde la Estrategia de TI de todos los servicios
Información del negocio actual y previsiones futuras de crecimiento
Información de rendimiento y capacidad de los componentes
Información financiera
Información de cambios y rendimiento
Sistema de Información para la Gestión de la Capacidad. (CMIS)
Información de carga de trabajo desde Operaciones de Servicio.
4.18.15. Salidas
Sistema de Información para la Gestión de la Capacidad. (CMIS)
Plan de Capacidad
Información e informes de rendimiento del servicio
Análisis e informes de la carga de trabajo
Umbrales, alertas y eventos
Previsiones e informes de predicción
4.18.16. Métricas KPIs

Se deberían incluir las siguientes
Porcentaje de precisión de tendencias de negocio
Elaboración proactiva de las cargas de trabajo.
Mejora de las habilidades para monitorizar el rendimiento y la respuesta de servicios
y componentes
Justificación a tiempo e implementación de nuevas tecnologías
Reducción controlada en el uso de tecnologías obsoletas
Reducción de incidencias y problemas relativos a capacidad inadecuada
Uno de los principales problemas es convencer al cliente para que nos informe de sus planes y
estrategias futuras a medio y largo plazo. Si obtenemos esa información seremos proactivos en la
adquisición de recursos y mejor garantizaremos al cliente la provisión eficiente de servicios y
componentes.
Esto es muy importante cuando los servicios están externalizados y hemos firmado UCs.
4.18.18. Factores Críticos de Éxito

Exactitud de las predicciones de negocio.
Conocimiento de tecnologías actuales y futuras.
Habilidad para demostrar la eficiencia en costes.
Habilidad para planificar e implementar la capacidad de TI idónea para satisfacer las
necesidades del negocio.

4.18.19. Desafíos y riesgos

La falta de compromiso del negocio con el proceso de Gestión de la Capacidad
La falta de información adecuada del negocio sobre los planes y estrategias futuras
La falta de compromiso de la alta dirección o la falta de recursos y / o presupuesto
para el proceso de Gestión de la Capacidad
Servicio de Gestión de la Capacidad y la capacidad de gestión de componentes
realizados en forma aislada, porque la capacidad de gestión de negocios es difícil, o
existe una falta de adecuada información de negocio
Los procesos son demasiado burocráticos o manualmente intensivos
Los procesos se centran más en la tecnología (componentes de Gestión de
Capacidad) y no lo en los servicios (gestión de servicios de capacidad) ni en el negocio
(capacidad de gestión empresarial)
Los informes proporcionados son demasiado grandes o demasiado técnicos y no dan
la información apropiada para los clientes y el negocio
4.18.20. Relación Principal con otros Procesos
Gestión
de Problemas Gestión del
Nivel de Servicio
Gestión de
la Demanda Gestión de
Capacidad Gestión
de Incidentes
Gestión de la
Continuidad
Gestión de la
Configuración
Gestión de la CMS
Disponibilidad

4.18.21. Resumen de Gestión de la Capacidad
Objetivos Determinar la capacidad de TI necesaria, en el momento adecuado a un coste justificable para

alcanzar los niveles de servicio acordados.
Para ello debe comprender:
- Los requisitos de negocio
- Provisión actual
- Componentes de provisión
Mantener el equilibrio entre Calidad y demanda del cliente
Gestión de Capacidad del Negocio:
- Determinar los requisitos futuros del negocio
- Planificar e implementar en plazos adecuados la capacidad suficiente para implementar los
servicios.
La Gestión de la Capacidad del negocio termina con la firma del SLA salvo que existan nuevos
requisitos de negocio.
Gestión de Capacidad del Servicio
Procesos (Sub-procesos)
- Identificar y entender los servicios de TI en términos de:

o Utilización de recursos
o Patrones de trabajo
o Tendencias de pico y valles de uso
- Garantizar el cumplimiento de los SLA
- Gestionar el rendimiento del servicio en producción
o Monitorización, análisis y reporte de los servicios
o Registro, análisis y reporte de la información obtenida
o Acciones para garantizar que el rendimiento del servicio cumple con los requisitos
del negocio
Gestión de Capacidad de los Recursos
- Identificar y entender la utilización de recursos (CI)
- Evaluar nuevas tecnologías
- Trabajar con gestión de la Disponibilidad para desarrollar soluciones con mayor capacidad de
recuperación
- Se enfoca a gestionar los componentes particulares de la infraestructura de TI
Actividades - Monitorización y Análisis
o Monitorización del servicio en general (tiempos de respuesta end-to-end) mediante la
implantación de robots y sondas
o Monitorización del recurso: Consumos de memoria, discos, tiempos de transacción y
diferentes funcionamientos del aplicativo
o Análisis: Mediante la identificación de tendencias para detectar y reportar excepciones,
predecir la utilización futura y comparar el crecimiento real del negocio respecto al
previsto.
- Ajuste (Tuning)
o Mejorar la utilización de los recursos
o Mejorar el rendimiento de un servicio
- Gestionar la demanda
o Influir en la demanda de recursos informáticos
o Influir en la utilización de los recursos
- Modelado: Planificar mediante tácticas de análisis de tendencias, modelado analítico o modelado
de simulación o pruebas en laboratorio los diferentes escenarios en función del negocio
- Dimensionamiento de las aplicaciones
- Creación del Plan de Capacidad
- CMIS (Base de datos Sistema de Información de Gestión de la Capacidad)
o Contiene:
 Datos de negocio
 Datos de servicio
 Datos técnicos
 Datos financieros
 Datos de utilización
o Genera:
 Previsiones de capacidad
 Informe de excepciones e informes de servicio y componentes

Entradas - Tecnología
- SLA, SLR y Catálogo de Servicios
- Estrategia y planes de negocio y de TI
- Requerimientos de volúmenes de Negocio y de TI
- Planificaciones operacionales, de desarrollo y de despliegue
- Lista de Cambios planificados (FSC)
- Detalles de incidencias y problemas relacionados con la capacidad
- Revisiones de servicio (por si hay que ampliar capacidad)
- Incumplimiento de SLA
- Planes financieros y de presupuestos
Salidas - Plan de Capacidad
- Base de datos de la Capacidad (CMIS)
- Líneas bases y perfiles
- Umbrales y alarmas
- Informes de Capacidad
- Recomendaciones para SLA, SLR y para políticas de costes e imputaciones de cargos
- Cambios proactivos y mejoras de servicio
- Planificación operacional revisada
- Revisiones de efectividad del proceso
- Informes de auditoria
Beneficios - Aumento de la habilidad para establecer y gestionar objetivos indicados en los SLA
- Disminución de los problemas por buena Gestión de la Capacidad
- Mejora la satisfacción del usuario final
- Mejora la disponibilidad de los sistemas y utilización de recursos
- Mejora el posicionamiento del negocio
- Incrementa la eficiencia y ahorra los costes
- Valor añadido del ciclo de vida de las aplicaciones
Desafíos - Expectativas idealistas
- Niveles inadecuados en la preparación del personal de Gestión de la Capacidad
- Complejidad en la integración de herramientas
- Dificultad para traducir los requisitos de negocio en requisitos de sistemas y carga de trabajo
- Dificultad para gestionar las expectativas del cliente respecto a la capacidad real y los costes
asociados
- Dificultad para traducir los resultados de la evaluación comparada del fabricante con las
características realistas de capacidad en el entorno de producción
Indicadores - Previsiones de recursos
claves del o Previsiones de requisitos de recursos realizadas a tiempo
rendimiento o Previsiones exactas de la tendencias de utilización de recursos
o Incorporación de planes de negocio en el Plan de Capacidad
- Tecnología
o Habilidad para monitorizar el rendimiento y el tráfico de todos los servicios y
componentes
o Implementación de nuevas tecnologías en línea con los requisitos de negocio
- Eficiencia en costes
o Reducción de compras por pánico (A última hora) y compras tempranas (Al principio)
o Previsiones exactas de los gastos planificados
o Ninguna sobre-capacidad significativa que no pueda justificarse en términos de
negocio
- Planificación e implementación de la capacidad de TI que corresponde a la necesidad de
negocio
- Reducción de incidencias, perdidas de negocio debidas a la capacidad inadecuada
- Los nuevos servicios se implementas ajustándose a las requisitos (SLR)
- Las recomendaciones hechas por Gestión de Capacidad son influyentes
Factores críticos - Previsiones de negocio exactas
de Éxito - Conocimiento de la estrategia y los planes de TI
- Entendimiento de las tecnologías actuales y futuras
- Habilidad para demostrar la eficiencia en costes
- Interacción con otros procesos de gestión del servicio
- Habilidad para planificar e implementar la capacidad de TI adecuada, que corresponda a la necesidad de
negocio

- Asegurar un uso óptimo de la capacidad

- Garantizar que se han establecido los niveles apropiados de monitorización de los recursos y
de rendimiento de servicio y que se ha actualiza la CMIS
Roles y responsabilidades
- Generar el plan de capacidad en línea con el ciclo de planificación del negocio

- Generar informes de gestión con regularidad
- Evaluar los sistemas actuales y las nuevas tecnologías en términos de rendimiento y
optimización en costes
- Realizar Pruebas de rendimiento
- Generar informes comparando rendimientos con SLA
Determinar los niveles de rendimiento del servicio que se pueden establecer y justificar en
términos de coste.
- Recomendar ajustes sobre sistemas tanto para la utilización como para la resolución de
problemas e incidencias
- Elaborar estudios de capacidad y rendimiento
G. de Incidencias Información de incidencias Alertas capacidad, Resolución
G. de Problema Información de problemas Errores conocidos referente a la
capacidad y su resolución
G. de Cambios Información de Cambios RFC, Evaluación de capacidad
G. de la Configuración Líneas de Referencia (BL) Informe de capacidad y rendimiento
y Activos del Sistema de CI
G. de Entregas y Verificación de requisitos de Identificación de requisitos de
Despliegues capacidad capacidad
G. de Nivel de Servicio SLR, SLA Criterios y Reportes
G. de Continuidad Opciones de recuperación Plan de Capacidad
G. Financiera de TI Utilización de recursos Información de costes de capacidad


4.19.Gestión de la Disponibilidad
4.19.1. Meta
La Disponibilidad tiene una directa influencia en la satisfacción del Cliente y en la reputación del
Proveedor de Servicios (SP), por lo que debe predecir, planear y gestionar la disponibilidad de los
servicios con un coste aceptable y que cumpla o supere lo acordado asegurando que:
Todos los servicios estén soportados por CIs confiables, suficientes y con un mantenimiento
adecuado.
Cuando los CIs no sean soportados internamente, que existan acuerdos apropiados con
cláusulas contractuales con los proveedores.
Proponer cambios para impedir la pérdida de la disponibilidad de servicios actuales,
cambiantes y del futuro
4.19.2. Objetivos
Determinar los requisitos de disponibilidad en términos del Negocio.
Optimizar la disponibilidad a través del monitoreo y el informe de los resultados.
Definir los objetivos de Disponibilidad, Confiabilidad y Mantenimiento para los componentes
de la infraestructura de TI, así como medirlos e informarlos.
Monitorizar y crear análisis del rendimiento de los CI con el objetivo de obtener tendencias
de la Disponibilidad, Fiabilidad y Mantenimiento de los componentes.
Revisar los niveles de disponibilidad de los CI para asegurar el cumplimiento de los SLAs,
OLAs y UCs.
Adoptar medidas proactivas para mejorar disponibilidad.
4.19.3. Ámbito
Incluye el diseño, la implementación, la medición, la gestión y la mejora de la disponibilidad de los
servicios de TI y de todos los componentes, incluidos los de terceros.
Debe entender la disponibilidad de los servicios y componentes en términos de.
Procesos de negocio actuales.
Planes y requisitos futuros de negocio.
Objetivos de servicio y operación además de la entrega de servicios existentes.
Infraestructura de TI, datos, aplicaciones y entorno.
Impacto y prioridades del negocio en relación a los servicios y su utilización.

Las principales actividades son:
Determinar los requisitos de disponibilidad del negocio.
Determinar las Funciones Vitales del Negocio (VBF).
Determinar el impacto de los fallos de componentes.
Determinar los objetivos particulares de disponibilidad, fiabilidad y capacidad de
mantenimiento de los componentes de TI.
Monitorizar y analizar componentes de TI.
Crear y mantener un Plan de Disponibilidad.
Establecer medidas e informes que reflejen las perspectivas del usuario del negocio y de TI.

4.19.5. Valor para el negocio

La disponibilidad y fiabilidad de los servicios de TI afecta directamente a la imagen y prestigio pues
tiene una enorme incidencia en la satisfacción de los clientes.
Fiabilidad:
Cuanto tiempo y bajo que circunstancias. Reliability
Mantenimiento: Maintainability
Si se rompe ¿Lo podemos arreglar?
Resistencia: Resilience and/or

¿Puede continuar TI si fallaran los
componentes? redudancy
Capacidad de Servicio.
Grado por el cual la provisión de servicios Serviciability
puede ser soportada por UC’s
Seguridad:
¿Podemos asegurar la confidencialidad, Security
integridad y disponibilidad de los servicios?
4.19.6. Proceso de Gestión de la Disponibilidad
Actividades
reactivas Monitorizar, medir, analizar
AMIS
Informar y revisar la
Disponibilidad de Sistema de
servicios y componentes Información
Para la Gestión de la
Disponibilidad
Investigar la falta de
Disponibilidad de servicios
y componentes e iniciar Informes de
Gestión de la
Actividades acciones de corrección
Disponibilidad
proactivas
Plan de la
Planificar y Disponibilidad
Evaluación y
diseñar
gestión del
Servicios nuevos
riesgo Y modificados
Criterios de
diseño para
Disponibilidad
Revisar todos los
Implementar servicios nuevos o
contramedidas cambiados y probar Planificación de
cuyo coste se los mecanismos de pruebas de
Disponibilidad Disponibilidad
pueda justificar y capacidad

4.19.7. Gráfico de Tiempos Medios
4.19.8. Tiempos Medios

Tiempo de Respuesta: Tiempo desde que ocurre un fallo hasta que TI tiene constancia del
mismo.
Tiempo de Detección: Tiempo desde que se detecta un fallo hasta su registro y diagnóstico
por Gestión de Disponibilidad.
Tiempo de Reparación: Tiempo que se necesita para la reparación del fallo hasta devolver el
CI o servicio a la situación anterior a la interrupción del servicio,
Tiempo de Recuperación: Tiempo que se necesita desde la reparación del fallo del CI hasta
devolver el sistema a la situación anterior a la interrupción del servicio,
Tiempo de Restauración: Tiempo que se necesita desde la recuperación del sistema hasta
devolver el servicio a la situación anterior a la interrupción del servicio,
Tiempo medio hasta avería: es el tiempo medio en que trabajará un CI antes de que falle
por primera vez
• MTTR = Mean Time to Repair
• MTBF – Mean Time Between Failures
• MTBSI – Mean Time Between System Incidents (MTTR+MTBF)
• MTTF - Tiempo Medio de la reparación del componente
4.19.9. Principios Rectores de la Disponibilidad

Gestión de Disponibilidad combina actividades reactivas y proactivas. Los clientes lo saben y hemos
de tener en cuenta lo siguiente:
La total disponibilidad de los servicios garantiza la satisfacción del cliente.
En caso de fallo, una respuesta eficaz aumenta la satisfacción del cliente si cabe.
Solo se puede aumentar la disponibilidad si los profesionales de TI ENTIENDEN lo que hacen
los servicios para facilitar las operaciones del cliente.
La capacidad para gestionar la disponibilidad depende del eslabón más débil de la cadena.
Lo mejor y más rentable es conseguir el nivel adecuado de disponibilidad desde el principio y
si no se ha conseguido, es preferible diseñarlo de nuevo y no parchear el servicio.
Algunas veces la falta de capacidad provoca falta de disponibilidad y aparecerá ante los ojos
del cliente como “falta de disponibilidad”.
El propietario del proceso a veces no tiene la suficiente autoridad o está compartida por
varios administradores de sistemas y ahí es donde falla la efectividad del procesos.

4.19.10. Análisis de Fallos del Servicio (SFA)
Seleccionar
oportunidad
Asignación
de ámbito
Asignación
(MIS)
Construir
hipótesis
Analizar
Datos Clave
Entrevistar a
Personal clave
Hallazgos y
conclusiones
Recomendaciones
Informes
Validación
Para maximizar el tiempo del personal asignado a la tarea del SFA y la calidad del informe entregado,
se requiere un método estructurado. Esta estructura se ilustra aquí y es un método similar a muchos
modelos de consultoría utilizados en la industria, y en muchos aspectos Gestión de la Disponibilidad
se puede considerar como una forma de consultoría interna proporcionada por el SFA.
4.19.11. Análisis del Árbol de Fallos
Servicio caído
Inhibir Fuera del horario

de servicio
Sistema caído
Or
Red caída
Servidor caído Aplicación caída

Línea Línea de
principal Conmutación
caída automática
FTA realiza la representación de una cadena de eventos mediante el uso de símbolos Booleanos.
Esta transparencia proporciona el ejemplo de un árbol de fallos.
Los eventos se pueden combinar utilizando operadores lógicos, es decir:
• Puerta AND - el evento resultante sólo se produce cuando todos los eventos de entrada se
producen simultáneamente
• Puerta OR - el evento resultante se produce cuando se producen uno o más eventos de entrada
• Puerta OR exclusivo - el evento resultante se produce cuando uno y sólo uno de los eventos de
entrada se produce
• Puerta inhibidora - el evento resultante sólo se produce cuando la condición de entrada no se
cumple.

Gestión de la Disponibilidad puede tener como disparadores:
Nuevas o modificadas necesidades del cliente.
Nuevos objetivos en los acuerdos en SLAs, OLAs o UCs.
Fallos del servicio.
Eventos y alertas de disponibilidad.
4.19.13. Entradas
Información de negocio, como estrategias de la organización, planes financieros, e
información de requisitos actuales y futuros de TI.
Análisis de Riesgo
Análisis de Impacto sobre el Negocio (BIA).
Estudios de Funciones Vitales del Negocio.
Información de servicios desde la Cartera de Servicios, Catálogo de Servicios y del SLM.
Calendarios de Cambios Planificados (FSC) desde la Gestión de Cambio.
4.19.14. Salidas
(AMIS) Sistema de Información para la Gestión de la Disponibilidad
El Plan de la Disponibilidad para la Gerencia
Criterios de diseño para disponibilidad y recuperación.
Informes sobre disponibilidad y fiabilidad.
Registro de riesgos actualizados.
Monitorización, gestión y reporte.
Programación de pruebas sobre disponibilidad.
Programación de mantenimientos preventivos planificados.
Paradas de Servicio Previstas(SPO Service Provisioning Optimization)
4.19.15. Métricas (KPI)

Porcentaje de reducción de falta de disponibilidad de servicios y componentes
Porcentaje de aumento de la fiabilidad de los servicios
Porcentaje de mejora de la disponibilidad de servicio medido de extremo a extremo
De reducción de los costes de la no disponibilidad
De mejora de la satisfacción de los clientes.
Frecuencia de fallos.
Impacto de fallos.
Duración de la no-disponibilidad.
Análisis de Impacto de Fallo de un componente (Component Failure Impact Analysis (CFIA)
Árbol de Fallos (FTA)
Análisis mediante el Método para la Gestión y Análisis de Riesgos de CCTA (CRAMM)
TI AMM
Los retos a los que hacer frente por parte de la Gestión de la Disponibilidad son.
Satisfacer las expectativas del negocio y de los clientes.
Integrar la información en un apropiada BBDD.
Convencer al negocio de invertir en medidas proactivas que aumenten la productividad.


Gestionar la disponibilidad y fiabilidad de los servicios de Ti.
Disponibilidad de la infraestructura según lo acordado en la SLA y a un coste aceptable.
Cumplimiento con el negocio en cuanto a accesos a TI.
4.19.18. Riesgos
Falta de compromiso de la gerencia con el proceso de la Gestión de la Disponibilidad.
Falta de recursos económicos y humanos.
Falta de información sobre planes y estrategias futuras.
Informes demasiados extensos y continuos.
La gestión sénior divide la responsabilidad entre muchas disciplinas
Cada gestor se siente responsable SOLO de su área y no hay coordinación
El nivel actual de disponibilidad creemos que es suficiente
No se apoya a un único responsable
El gestor del proceso no tiene la autoridad necesaria y no llega a ser el propietario
Infravaloración de los recursos
Falta de herramientas de medición eficientes
4.19.19. Mala gestión de AM tendremos posibles Problemas

Difícil definir los estándares de disponibilidad apropiados
Difícil guiar a proveedores internos y externos
Difícil comparar los costes de disponibilidad y de no disponibilidad
Puede disminuir la satisfacción del cliente y ejecutarse las penalizaciones
Al no cumplir los estándares de disponibilidad habrá dificultades para alcanzar los objetivos
comerciales.
Gestión de
Cambios
Gestión de
Gestión de
Incidencias
Seguridad
Gestión de la Gestión de la
Continuidad Disponibilidad Gestión del
AM Nivel de Servicio
Gestión de la
Capacidad
Gestión de
Gestión de Accesos
Problemas

4.19.21. Resumen de Gestión de la Disponibilidad
Objetivos - Predecir, planificar y gestionar la disponibilidad de los servicios asegurando que:

o Todos los servicios sean sustentados por suficientes CIs, fiables y mantenidos
adecuadamente
o Para los CIs que no tienen soporte interno existen contratos apropiados con
suministradores (proveedores)
o Se proponen cambios para evitar potenciales perdidas de la disponibilidad del servicio
o Los niveles de disponibilidad mínimos son los acordados con los clientes en los SLA.
- Optimizar la capacidad de la infraestructura de TI, los servicios y la organización de soporte, para
proporcionar un nivel eficiente y sostenible de disponibilidad, que permita al negocio alcanzar sus
objetivos
Diseño y 1. Definir los requisitos de disponibilidad del negocio
Fases 2. Análisis de infraestructura de TI y revisión de capacidades <-> Modelo de disponibilidades
3. Requisitos de disponibilidad acordados (SLA)
o Especificar requisitos de capacidad de servicio
o Negociar contratos (UC) de capacidad de servicio
o Especificar requisitos de fiabilidad y capacidad de mantenimiento
o Negociar en acuerdos internos (OLA)
4. Probar el cumplimiento de requisitos de disponibilidad
5. Monitorizar el cumplimiento de requisitos de disponibilidad
Actividades - Determinar los requisitos de disponibilidad del negocio
o Definir las condiciones bajo las cuales el negocio considera que el servicio de TI no está
disponible
o Analizar el impacto de la pérdida del servicio sobre el negocio
o Definir las horas de servicio requeridas
o Definir la importancia relativa de las diferentes franjas horarias de trabajo
o Especificar los requisitos de seguridad
- Determinar las Funciones Vitales del Negocio (VBT)
- Determinar el impacto producido del fallo de los componentes de TI
- Definir los objetivos de disponibilidad, fiabilidad y capacidad de mantenimiento
- Establecer medidas e informes de disponibilidad, fiabilidad y capacidad de mantenimiento
- Monitorizar y analizar las tendencias de disponibilidad, fiabilidad y capacidad de mantenimiento de
los componentes de TI
o Siempre frente al negocio y a los recursos de TI como los recursos humanos
- Revisar y analizar la disponibilidad del servicio y de los componentes de TI e identificar riesgos
tolerables y niveles inadmisibles
o Determinar Puntos Únicos de Fallos (SPOF)
o Modelo de análisis y gestión de riesgos de la CCTA (CRAMM)
 Fase Análisis del Riesgo: Relacionar el valor de los activos con las amenazas y las
vulnerabilidades
 Fase de Gestión del Riesgo: Establecimiento de contramedidas, plan para la caída
potencial y gestión de la caída
o Técnicas de análisis de Fallo
 Análisis del impacto de Fallo del componente (CFIA): Permite identificar donde
se puede implementar una capacidad de recuperación adicional a fin de evitar o
minimizar el impacto del fallo de un componente
 Análisis del Árbol de Fallos (FTA): Permite identificar la cadena de sucesos que
causan una interrupción del servicio además de los SPOF (Puntos únicos de fallos)
 Análisis de caída del sistema/servicio (SOA): Técnica diseñada para proporcionar
un planteamiento estructurado para identificar las causas subyacentes de
interrupción del servicio
 Ciclo de Vida Ampliado del Incidente: Permite desglosar y analizar el tiempo
total de caída del servicio para un incidente dado
 Puesto Técnico de Operación (TOP): Grupo preestablecido de personal técnico
de soporte, reunido para centrarse en aspectos específicos de disponibilidad de
TI

o Análisis de la caída del servicio (SFA)

 Seleccionar y acordar el objeto del análisis
 Determinar explícitamente el alcance y planificar la actuación de antemano
 Desarrollar hipótesis y escenarios posibles
 Analizar los datos y estadísticas
 Entrevistar al personal clave y a los representantes principales del negocio y de
sus usuarios
 Documentar y verificar descubrimientos y conclusión
 Formular recomendaciones
 Elaborar informe Final
 Verificar el análisis en relación con los objetivos
 Incorporar en el Plan de disponibilidad o en el programa de Mejora del servicio
las recomendaciones aprobadas, como actividades a desarrollar e implementar
- Investigar las razones subyacentes de un nivel de disponibilidad inadmisible
- Elaborar y mantener un Plan de Disponibilidad
o Planificar las iniciativas para mejorar la disponibilidad
o Niveles reales de disponibilidad comparado con los acuerdos (SLA, SLR y UC)
o Actuaciones para enfrentarse a las deficiencias de disponibilidad de los servicios
incluyendo análisis de costes
o Detalles de los requisitos de disponibilidad cambiantes para los servicios existentes y
nuevos para los nuevos servicios
o Lista de Análisis de Caída del Servicio (SOA) planificados
o Oportunidades de explotación de las actualizaciones tecnológicas previstas
- Análisis del coste de la disponibilidad: Siempre buscando un equilibrio entre coste y
disponibilidad.
o Con el mismo coste se pueden llegar a resultados distintos, basándonos en los
mantenimientos correctivos, preventivos y capacidad de recuperación.
o Coste de la indisponibilidad
 Pérdidas de productividad del usuario (Coste por hora por usuario afectado)
 Pérdida de productividad de la organización (Coste por hora del personal de TT
afectado)
 Pérdidas de ingresos más otras perdidas del negocio (Ingresos perdidos por hora
más costes de horas extras empleadas, materiales, multas por incumplimiento
etc.)
 Impacto sobre el servicio al cliente (que se pueda cuantificar)
- Recuperación: Elementos Claves
o Gestión de Incidencias y Centro de Servicio al Usuario:
 Involucrar al personal adecuado desde el principio,
 Invocar los procedimientos de recuperación adecuados desde el principio
o Métricas definidas en el ciclo de vida del incidente
 Crear y mantener métricas de la recuperación de cada componente de TI, que
cubran los diferentes escenarios
 Determinar requisitos para favorecer una recuperación rápida
o Gestión de sistemas
 Utilizar herramientas para detectar automáticamente fallos, ayudar en el
diagnóstico y realizar una recuperación automática
o Captura de datos para el diagnóstico: Perfeccionar técnicas y procedimientos de captura y
selección de datos para reducir el tiempo de investigación y diagnóstico.
o Backup y recuperación probados:
 Disponer de planes de recuperación a disposición de las partes implicadas
 Buscar y promover métodos de Backup y recuperación más rápidos ante
incidentes potenciales
o Restauración y verificado del servicio
 Comprobar que el servicio funciona correctamente una vez se ha restaurado
o La capacidad concede disponibilidad
- Creación y mantenimiento de la Base de datos Sistema de Información de la Gestión de la
Disponibilidad (AMIS)
- Planificación del servicio, junto con desarrollo, gestión financiera, Gestión de la Capacidad, Gestión
de Cambios no olvidando nunca a los recursos necesarios

Entradas - Requisitos de la disponibilidad del negocio (SLA)

- Evaluación del impacto sobre el negocio
- Requisitos de disponibilidad, fiabilidad y capacidad de mantenimiento
- Información de incidencias y problemas (Estudia tiempos de fallos y caídas en asociación con
incidencias y problemas)
- Información de configuración (CMDB) y monitorización
- Grado de consecución de los niveles de servicio (SLA)
Salidas - Criterios de diseño de disponibilidad y recuperación (Planes de disponibilidad y recuperación)
- Capacidad de recuperación adicional de la infraestructura de TI y evaluación del riesgo
- Objetivos acordados de disponibilidad, fiabilidad y capacidad de mantenimiento
- Informes de disponibilidad, fiabilidad y capacidad de mantenimiento
- Monitorización de la disponibilidad
- Plan de Disponibilidad para la mejora
Beneficios - Métricas de Líneas de Referencia más precisas, contribuyendo a unos SLA más prácticos y precisos
- Estadísticas más exactas, contribuyendo a mejorar la relación y soporte con el suministrador
- Mejora la calidad y capacidad de la gestión de la infraestructura de TI
- Mejora los niveles de servicio gracias a un planteamiento de problemas más proactivo que reactivo
- Mejora del servicio al usuario final gracias a un mejor diseño y cumplimiento de los objetivos
específicos de Disponibilidad
- Justifica los costes más fácil y mejora la eficiencia de los costes de TI
Obstáculos - El coste de la gestión de la disponibilidad a menudo se considera como un gasto no imputable y
demasiado caro
- Suele ser difícil cuantificar los requisitos de un usuario en costes y disponibilidad
- Dificultad para encontrar profesionales de TI con experiencia
- Necesidad de demasiadas herramientas para cuantificar los datos de la Línea de Referencia (BL)
- Dependencia en los suministradores para obtener datos de disponibilidad
- Falta de conocimiento de la infraestructura de TI
Indicadores - Impacto de la indisponibilidad del servicio de TI sobre el negocio.
claves del o Reducción de la indisponibilidad de los servicios y componentes
rendimiento o Reducción de fallos en momentos críticos
o Reducción del coste de la indisponibilidad
- Incremento de la fiabilidad de los servicios y componentes
- Mejora de la disponibilidad global (end-to-end) de los servicios
- Mejora del tiempo medio de incidencias de los sistemas (MTBSI)
- Mejora del tiempo medio entre fallos (MTBF)
- Reducción del tiempo medio de reparación (MTTR)
- Reducción del tiempo para elaborar los análisis de riesgos
- Reducción del tiempo para revisar la capacidad de recuperación de los sistemas
- Reducción del tiempo para elaborar el plan de disponibilidad
Métricas - Enfoque al negocio: Frecuencia , Alcance, fiabilidad, duración, capacidad de mantenimiento
- Basadas en:
o Porcentaje de disponibilidad (%)
o El tiempo perdido
o Frecuencia del fallo
Mejores - Separar los que diseñan de los que realizan las mediciones
Practicas - No separarlo de la planificación y control de la continuidad del servicio de TI (ITSMC)
- Trabajar coordinadamente con Gestión de la Capacidad, Gestión Financiera y Gestión de la
Continuidad
- Asegurar que los servicios de TI se diseñan para proporcionar los niveles de disponibilidad que el
negocio necesita
responsabilidades
- Garantizar que se miden y monitorizan de manera continua los niveles acordados disponibilidad,
fiabilidad y capacidad de mantenimiento
Roles y
- Ofrecer informes sobre la disponibilidad

- Optimizar la disponibilidad en la infraestructura de TI
- Reducir la frecuencia y duración de los incidentes de disponibilidad
- Garantizar la detección de deficiencias de disponibilidad e identificar y ejecutar medidas
correctivas apropiadas
- Generar y mantener el Plan de Disponibilidad


G. de Incidencias Registro de incidencias Mejoras y
recomendaciones
G. de Problemas Estado de problemas Mejoras y
recomendaciones
G. de Cambios Información de cambios (FSC, PSA) RFC, evaluación de
impacto
G. de la Configuración y Activos Información de atributos y estados Información de estado de
del Servicio de CIs disponibilidad
G. de la Capacidad Plan de capacidad CFIA, Capacidad de
recuperación necesaria
G. de Nivel de Servicios SLR, SLA Criterios, reportes y
mejoras
G. de la Continuidad BIA, VBFs Criterios y medidas de
disponibilidad
G. Financiera de TI Estudio coste disponibilidad Coste indisponibilidad

4.20.Gestión de Continuidad de los Servicios de TI (ITSCM)

Desastre: Un evento que afecta a un servicio o sistema y para el que es necesario un gran esfuerzo
para restaurar el nivel de rendimiento original. Un DESASTRE desemboca en una CRISIS
Gestión de Continuidad es el Proceso para manejar los desastres que afectan a uno o más servicios
de TI y mantenerlos para permitir que el Negocio siga operando de acuerdo a los SLAs.
Un Desastre no es un INCIDENTE, ni un PROBLEMA y no es una falta de DISPONIBILIDAD, es mucho
más.
Proceso responsable de gestionar los RIESGOS que podrían impactar a uno o más servicios de TI y
mantenerlos para permitir que el negocio siga operando de acuerdo al SLA
El objetivo básico es mantener la continuidad del Negocio (BCM).
La estrategia de la Gestión de la Continuidad del Servicio de TI (ITSCM) debe combinar
procedimientos:
Proactivos. Buscan impedir las consecuencias de una interrupción del servicio.
Reactivos: Buscan reanudar el servicio tan pronto como sea posible.
4.20.1. Meta
Debe soportar la Gestión de Continuidad del Negocio asegurando que todos los
requerimientos de tecnología y de facilidades para los servicios (computadora, redes,
aplicaciones, telecomunicaciones, soporte de servicio, entrega de servicio, service desk)
puedan ser recuperados según lo requerido y en los tiempos acordados a pesar de un
desastre natural, humano o técnico.
4.20.2. Objetivos
Debe reducir el tiempo y el coste en la recuperación.
Mantener el coste en relación con el Negocio del cliente y de TI.
Minimizar la interrupción de las actividades del Negocio.
Mantener planes de recuperación y continuidad.
Realizar análisis de impacto sobre el negocio (BIA).
Realizar estimaciones de riesgo.
Asesorar a todas las áreas de negocio y de TI en relación con la continuidad y recuperación.
Garantizar que los mecanismos de continuidad y recuperación están siempre listos para
cumplir los objetivos del negocio.
Evaluar el impacto de los cambios sobre los Planes de Continuidad.
Implementar medidas proactivas justificables en costos para mejorar la disponibilidad de los
servicios.
Negociar acuerdos con otros Proveedores de Servicios en lo relativo a recuperación de los
Planes de Continuidad.

4.20.3. Alcance
Dentro del alcance de ITIL® hay dos áreas:
Gestión de Continuidad del Negocio (BCM): Para reducir los riesgos a un nivel aceptable y
desarrollar planes para restaurar rápidamente el negocio si se interrumpe por un desastre.
Gestión de Continuidad de Servicio de TI (ITSCM): Manejar los desastres que afectan a uno o más
servicios de TI y mantenerlos para permitir que el negocio siga operando de acuerdo a la SLA.
En particular el soporte visible de la Alta Dirección y los Directores es crítico para la efectividad del
ITSCM
Determinación del alcance de (ITSCM):
Al iniciar ITSCM considerar la Organización como un todo.
Definición de las políticas:
Definidas las políticas se debe comunicar a toda la Organización.
La Gerencia debe mostrar su compromiso.
Definición del alcance y las áreas relevantes:
Requisitos de Seguridad y estándares como ISO 25999, ISO 22301 o ISO 27001
Asignación de recursos:
Invertir en personal y recursos para implementar los Requisitos y Recursos.
Establecer la organización del proyecto
Recopilar y mantener las opciones de recuperación
Es aconsejable métodos de gestión de proyectos. Ej.: PRINCE2
4.20.4. Ámbito
Acuerdos sobre el alcance de ITSCM
Análisis de Impacto sobre el Negocio, para cuantificar el impacto de los desastres.
Análisis de riesgos: Identificación y evaluación de riesgos.
Elaboración de una estrategia global de ITSCM.
Elaboración de Planes de Continuidad.
Pruebas de los planes.
Operación de continuidad y mantenimiento de los planes
Por la dependencia del negocio en TI.
Por la Supervivencia del Negocio.
Para reducir el tiempo y el coste en la recuperación.
Minimizar la interrupción de las actividades del negocio.
Si el negocio se “PARA” podríamos perder el cliente y ser penalizados de acuerdo a la SLA.
4.20.6. Organización y Planificación
Determinado el alcance de la ITSCM, analizados los riesgos y vulnerabilidades y definidos los
requerimientos de prevención y recuperación hay que elaborar los documentos sobre:
1º.- Plan de Prevención de Riesgos
2º.- Plan de Gestión de Emergencias
3º.- Plan de Recuperación

Plan de Prevención de Riesgos:

Almacenamiento de datos distribuidos (DFSs).
Sistemas de alimentación eléctrica de soporte (SAI).
Políticas de Back-Up.
Duplicación de sistemas críticos.
Plan de Gestión de Emergencias:
Las crisis suelen provocar "reacciones de pánico" que son más dañinas que las provocadas
por el propio incidente. Imprescindible estén determinadas las responsabilidades y
funciones del personal así como los protocolos de acción.
Informar a los usuarios y clientes de una grave degradación del servicio.
Procedimientos de contacto y colaboración con los proveedores involucrados.
Evaluación del impacto de la contingencia en la infraestructura TI.
Protocolos para la puesta en marcha del plan de recuperación correspondiente incluido la
vuelta al papel.
Asignación de funciones de emergencia al personal de TI
Plan de Recuperación:
Reorganizar al personal involucrado.
Reestablecer los sistemas de hardware y software necesarios.
Recuperar los datos y reiniciar el servicio TI.
Asignación de personal y recursos.
Instalaciones y hardware alternativos.
Planes de seguridad que garanticen la integridad de los datos.
Contratos de colaboración con otras organizaciones.

La ITSCM es un proceso cíclico que adapta los planes de recuperación y Continuidad del servicio a
los Planes de Continuidad del Negocio.

4.20.8. El proceso consta de cuatro fases
4.20.8.1. Iniciación
Definición de la política
Alcance y especificaciones de los términos de referencia
Asignación de recursos humanos, técnicos y financieros
Definición de la organización del proyecto
Acuerdo de los planes de calidad y del proyecto
4.20.8.2. Requisitos y estrategia

Los requisitos implican la realización de un Análisis de Impacto sobre el Negocio y de un Análisis
del riesgo
Requisito 1.- Análisis de Impacto sobre el Negocio (BIA)

El tipo de daño o pérdida
La forma de escalado del daño
Las competencias, instalaciones y servicios que se necesitan para dar continuidad a procesos
importantes
El plazo de tiempo en el que se deben de producir la recuperación de los servicios y en su
totalidad
Períodos de recuperación para cada servicio
Requisito 2.- Estimación del riesgo mediante un método como (MoR) Gestión del Riesgo.
Principios de MoR
Planteamiento de MoR
Procesos de MoR
Incorporación y revisión de MoR
Comunicación
Estrategia 1.- Medidas de reducción del riesgo. Se han de implementar junto a Gestión de
Disponibilidad, tales como Sistemas Tolerantes a Fallos, Clúster, NLB, DFS, Backups, etc.
Estrategia 2.- Opciones de recuperación de ITSCM

Workarounds manuales
Los Acuerdos Recíprocos se han hecho menos populares (con menos sistemas mantenidos
en mainframe) ya que dependen de configuraciones idénticas, procedimientos de gestión de
cambio integrados y tiempo de procesamiento compartido, que es menos práctico con
sistemas on-line.
La Recuperación Gradual es cuando reconstruimos una parte de la infraestructura a partir
de cero en un local que se acuerde por la dirección. Hay un almacén o podemos alquilar uno
inmediatamente y este local se equipa con luz, teléfonos y con facilidades de red. Tenemos
contratos con suministradores que instalarán hardware y software en menos de 3 días y
nosotros mismos instalaremos las aplicaciones y los datos inmediatamente después.
La recuperación rápida es un plazo de 24 horas y concentrada en los servicios esenciales y
con mínima pérdida de datos.
La Recuperación Inmediata es cuando tenemos más locales o construimos un segundo local.
En tiempos de desastre, podemos cambiar al otro local, a veces en minutos. Estos locales se
usan como locales de prueba cuando no hay un desastre (Que es lo normal).
Recuperación Intermedia es cuando no tenemos nuestro propio local pero alquilamos
capacidad y espacio de una compañía ad hoc que asumirá nuestros servicios.
4.20.8.3. Implementación
Una vez aprobada la estrategia podremos diseñarlos y debe estar concentrada en torno a
un alto directivo responsable, un coordinador y un equipo de recuperación y hay que
emplear diferentes tipos de pruebas.
Pruebas superficiales
Pruebas parciales
Pruebas completas
Escenarios de Pruebas
4.20.8.4. Operación continuada

Educación, concienciación y formación del personal
Revisión y auditoria
Realización de pruebas
Gestión de Cambios
Pruebas definitivas
Entrenamiento
4.20.9. Pruebas Extensivas

Inicialmente cada 6 o 12 meses y después de cada desastre.
Probarlo en circunstancias reales, hacerlo riguroso
Mover / Proteger cualquier servicio vital primero!!
Revisar y cambiar el Plan cuando se requiera. ¿Qué cambia? Nuevo, más, menos de:
– Clientes / Servicios / SLR / Riesgos /
– Dependencias / Activos / CI / Staff /
– Contratos / SLA / Medidas de control / …
TODO cambio a realizarse debe ser vía el Comité de Asesoramiento de Cambios (CAB)
4.20.10. Gestión de la Información

Hay que registrar en el CMS toda la información referente al mantenimiento de planes de ITSCM y
alinearlo con el pan de la información de BCM como:
Riesgos dentro de un registro de riesgos
Evaluación del riesgo
Posibles respuestas
La última versión de la estrategia de BCM y el Análisis de Impacto en el Negocio
Pruebas realizadas y sus resultados
Pruebas a realizar
Detalles de los planes de ITSCM y relacionados
Instalaciones de recuperación existentes así como de los búnkeres
Detalles sobre procesos de respaldo y restauración
Necesidades del negocio nuevas o modificadas
Objetivos particulares nuevos o modificados (SLAs, OLAs, UCs)
Incidencia muy crítica
Problemas críticos
Cese súbito de la disponibilidad sin predicción de vuelta en línea
Actividades programadas de parada o Análisis de impacto en el Negocio (BIA)

4.20.12. Relación con otros Procesos
4.20.13. Entradas
Planes y Estrategias de la Organización
Información de TI
Información financiera
Planes y estrategias de BCM
Información de Gestión de Cambios importantes
CMS
Programación de pruebas
4.20.14. Salidas
Políticas y estrategias de ITSCM
Informes de Análisis del Impacto sobre el Negocio
Revisiones e informes de Análisis y gestión de riesgos
Planes de Continuidad
Escenarios de pruebas
Revisiones e informes de pruebas

El resultado de las auditorías periódicas de los planes de ITSCM
El nivel de acuerdo y documentación de los objetivos de recuperación del servicio en las
SLAs
Los resultados de las pruebas de los planes de ITSCM
La revisión periódica de los planes de ITSCM

4.20.16. Posibles problemas

Proporcionar Planes de Continuidad cuando no exista un procesos de BCM
Si existe un proceso de BCM, que no esté integrado en el plan de ITSCM
Si existe, que no esté mantenido ni actualizado
Falta de medios técnicos apropiados al momento tecnológico
4.20.17. Riesgos
Falta de compromiso del Negocio
Falta de compromiso de la dirección
Falta de recursos y presupuesto
Importancia excesiva de la tecnología sobre los servicios y las necesidades de los clientes
Aislamiento de los análisis y la gestión de riesgos, que no se realizan y comparten con la
Gestión de la Disponibilidad y la Gestión de la Seguridad
4.20.18. Gestión del riesgo
Integrar y revisar (5)
Implementar (4)
Identificar (1)
Comunicar (6)
Planificar (3)) Evaluar (2)

Guía del Proceso de
Gestión de Riesgos
M_o_R Método
Dentro del proceso de Gestión de la Continuidad de los Servicios (ITSCM) existen diversos
métodos de Análisis y Gestión del Riesgo disponibles para el sector comercial y el sector
público. Análisis de Riesgo es la evaluación de los riesgos que pueden dar lugar a una
interrupción del servicio o a una violación de seguridad. Gestión del Riesgo se preocupa de
identificar respuestas adecuadas al riesgo o contramedidas justificables en coste para luchar
contra esos riesgos.
Debería emplearse una metodología estándar, como por ejemplo Gestión del Riesgo (MoR),
para evaluar y gestionar riesgos dentro de una organización. El marco de trabajo de MoR se
ilustra en esta presentación.

4.20.19. Resumen de Gestión de la Continuidad

Objetivos - Apoyar el proceso global de Gestión de la Continuidad del Negocio (BCM)
- Garantizar que se pueden recuperar los servicios de TI necesarios, dentro de los tiempos
requeridos y acordados por el negocio.
- Es posible definir dos tipos de alcance para la Gestión de la Continuidad
o Dentro del alcance: Los riesgos que pueden producir una interrupción severa de
los procesos de negocio, por ejemplo catástrofes naturales, terrorismo, errores
humanos, actos de Dios, etc.
o Fuera del alcance:
 Son riesgos a largo plazo como cambios en la dirección del negocio,
diversificación, reestructuración etc.
 Fallos técnicos menores, por ejemplo, fallo de un disco duro no crítico,
tratados por Gestión de Incidencias
Procesos - Etapa 1: Inicio
(Sub-procesos) o Establecer la política de la Gestión de la Continuidad en base a la continuidad
4 Fases del negocio comunicando con el personal de la organización implicado o
afectado
o Especificar los términos de referencia y el alcance
 Definir el alcance y las responsabilidades de gerencia y personal
 Puntos destacados de la inspección, requisitos legales o de cliente,
estipulaciones del asegurador, conformidad con las Normas.
o Asignar recursos
o Definir la organización del proyecto y la estructura de control
 Utilizar metodología de proyectos
 Nombrar un jefe de proyecto que reporte a un comité.
o Acordar los planes de calidad y de proyecto
- Etapa 2 : Requisitos y estrategia
o Análisis del impacto en el Negocio (BIA)
 Identificar los proceso críticos del negocio
 Identificar los daños o pérdidas potenciales que puedan impactar
negativamente en la organización causando la interrupción en los
procesos críticos de negocio
 Evaluar el impacto potencial respecto al coste de la recuperación, para
garantizar que los costes sean aceptables.
 Establecer los objetivos de recuperación de negocio en términos de:
 Plazo de tiempo dentro del que se deben recuperar un equipo
predefinido de personal clave y unas instalaciones mínimas
 Intervalo de tiempo para la recuperación del personal e
instalaciones restantes
 Requisitos mínimos imprescindibles para dar servicio al
negocio
o Evaluación del Riesgo (es posible utilizar CRAMM)
 Fase Análisis del Riesgo: Relacionar el valor de los activos con las
amenazas y las vulnerabilidades
 Fase de Gestión del Riesgo: Establecimiento de contramedidas, plan
para la caída potencial y gestión de la caída
o Estrategia de continuidad de negocio
 Establecer un equilibrio entre:
 Medidas de reducción de riesgo (Junto con Gestión de la
Disponibilidad)
 Recuperación de TI
 Opciones de Recuperación (Incluir planes para restaurar el servicio
normal):
 No hacer nada
 “Workarrounds” de tipo manual
 Acuerdos recíprocos
 Recuperación Gradual (Cold Stand-by > 72 horas)
 Recuperación Intermedia (warm Stand-by Entre 24 y 72 horas)
 Recuperación Inmediata (hot Stand-by < 24 horas)
- Etapa 3: Implementación
o Planificar
 Organización de la continuidad, ¿Quién es el responsable de qué?
 Implementación: Planificar como identificar y responder
 Plan de respuesta a emergencias
 Plan de evaluación de daños
 Plan de salvamento
 Plan de registros vitales
 Plan de gestión de la crisis y relaciones públicas
 Una vez se activa el Plan de Continuidad, iniciar:
 Plan de alojamiento de servicios
 Plan de sistemas informáticos, redes y telecomunicaciones
 Plan de seguridad
 Plan de personal
 Plan de administración y finanzas
o Implementar
 Medidas de reducción de riesgo (Actuaciones)
 Instalar UPS y suministro eléctrico supletorio
 Utilizar sistemas tolerantes antes fallos para todas las
aplicaciones críticas
 Realizar almacenamiento y archivado en un lugar externo
 Adquirir equipos y componentes de repuesto para ser
utilizados en caso de fallo
 Disposiciones de respaldo-(Actuaciones)
 Negociar con proveedores de respaldo las instalaciones de
recuperación externa
 Conseguir un acuerdo contractual
 Preparar y equipar la instalación de respaldo
 Adquirir e instalar sistemas informáticos de respaldo
 Negociar con proveedores de Outsourcing sus Planes de
Continuidad del servicio externalizado
o Desarrollar
 Crear planes de recuperación que incluyan:
 Todas las actividades necesarias para recuperar los sistemas
requeridos
 Todas las actividades necesarias para recuperar las
instalaciones requeridas
 Las dependencias entre sistemas e instalaciones
 Las pruebas necesarias antes de su entrega (de rendimiento,
funcionales, operativas y de aceptación)
 La verificación de la integridad y consistencia de los datos
 Crear procedimientos que cubran:
 La instalación y pruebas del hardware y redes de reserva
 La restauración del software y de los datos a un punto común
de referencia , consistente con todos los procesos de negocio
 Los diferentes usos horarios para una organización
multinacional
 Los puntos de interrupción y franjas horarias del negocio
o Realizar pruebas iniciales. Probar para confirmar:
 Los objetivos en el tiempo, es decir, recuperar servidores dentro de un
cierto número de horas
 La preparación, concienciación y capacidades del personal
 La duplicidad del personal y el potencial exceso de compromiso de los
recursos claves
 La receptividad, efectividad y concienciación de los proveedores
externos

- Etapa 4: Gestión Operativa

o Educación y concienciación a través de la organización
 Garantizar que todo el personal esté al corriente de las implicaciones
de ITSCM
 El personal debería considerar ITSCM como parte de su rutina normal
de su trabajo
o Adiestramiento, garantizando que el personal tenga el nivel de competencia
necesario
o Revisión y auditoria
 Revisar todos los entregables de ITSCM
 Garantizar que los entregables estén actualizados
o Pruebas regulares completas
 Activar un plan de pruebas periódicas
 Realizar las pruebas bajo circunstancias realistas
o Control de Cambio
 Todos los cambios de ITSCM están sujetos al Control del Cambio
 Considerar el impacto de todos los cambios sobre el Plan de ITSCM
o Aseguramiento regular
 Tener la seguridad de que los resultados de ITSCM resulten aceptables
para la alta dirección del negocio
 Tener la seguridad de que todos los proceso de gestión operacional
funcionen correctamente.
- Etapa 5: Otras etapas o actividades
o Estructura de Gestión de Crisis: Debe estar compuesta por áreas de negocio y el
gestor de continuidad con sus equipos correspondientes y liderados por el
Consejo director de BCM (Bussines Continuity Management) y el gestor de la
continuidad del negocio.
o Invocar el Plan de Continuidad
 Toma de decisiones de un equipo de gestión de crisis (Comité BCM),
compuesto por altos directivos del negocio y de los departamentos de
los servicios incluyendo TI
 Instrucciones detalladas del procedimiento de invocación incluyendo el
personal que es necesario contactar para iniciar los planes de
recuperación.
 Planes y procedimientos de recuperación disponibles para el personal
adecuado, en el momento necesario
 Comunicado a la organización, que todo el personal implicado en el
proceso de recuperación reciba el mensaje de invocación.
o Gestionar la recuperación
 Llevar un registro de todas las actividades realizadas
 Planificar los turnos y rotaciones para garantizar que se realiza el mejor
uso posible de las instalaciones disponibles
 Reconocer y recompensar el esfuerzo del personal
 Asegurar los controles habituales de negocio y tecnología durante el
proceso de invocación, la recuperación y la vuelta a la normalidad.
 El objeto final es volver al nivel normal de funcionamiento y desalojar la
instalación de emergencia en el menor tiempo posible, debiendo
planificar cuidadosamente dicha vuelta a la normalidad.
Beneficios - Se reduce el número de desastres e interrupciones de servicio
- Se reduce el impacto sobre los desastres que se materializan
- Mejora la habilidad para recuperarse ante los desastres, de una manera controlada
- Se reduce la cantidad de tiempo perdido y consecuentemente se proporciona una mayor
continuidad de servicio a los usuarios
- Se minimiza el interrupción del negocio
- Primas de seguro más baratas
- Cumplimiento de requisitos legales
- Mejor conocimiento de las necesidades de negocio y de la capacidad de la organización de TI
para satisfacerlas
- Publicidad positiva, credibilidad y reputación de la organización
- Ventaja competitiva

Obstáculos - Dificultad para lograr e integrar el compromiso del personal en un equipo de planificación de
la continuidad
- Restricciones para poder probar el plan sobre un sistema de producción
- Que la planificación de la continuidad no se incluya dentro de los presupuestos
departamentales
- Dificultad para obtener recursos y compromiso de la dirección
- Falta de integración de otros procesos de negocio de la Gestión de Servicios
Indicadores - Todos los objetivos de recuperación se acuerdan y documentan en los SLA y son alcanzables
claves del dentro del plan de ITSCM
rendimiento - Pruebas regulares y completas del Plan de ITSCM
- Auditorias regulares del plan de ITSCM
- Revisiones regulares del plan de ITSCM con las áreas de negocio
- Control de contratos con terceros para ITSCM
- Reducción global del riesgo y del impacto de posible fallos en los servicios de TI
- Concienciación en toda la organización de TI sobre el impacto , requisitos y necesidades de
negocio ante desastres potenciales
- Áreas y personal de servicios TI preparados y capaces de responder a una invocación del plan
de ITSCM
- Comunicación regular de los objetivos y responsabilidades de ITSCM a las áreas de negocio y
de TI apropiadas
Mejores Practicas - Utilizar las actividades probadas y eficaces de la evaluación y gestión de riesgos como base
para planificar ITSCM
- Aplicar el planteamiento de que si no merece la pena protegerlo no merece la pena tenerlo
- Implementar y mantener el proceso de ITSCM que se ajuste a las necesidades generarles del
proceso BCM de la organización.
- Ejercer de representante de TI dentro de BCM
- Desarrollar y gestionar el plan de ITSCM para garantizar que se pueden conseguir en todo
momento los objetivos de recuperación de negocio
- Asegurarse de que todas las áreas de TI están preparadas y pueden responder a una
invocación en los Planes de Continuidad
- Mantener un programa completo de pruebas de ITSCM
- Realizar revisiones periódicas de la calidad de todos los procedimientos, y asegurarse que se
incorporan al programa de pruebas.
- Comunicar y mantener informados sobre los procesos de ITSCM al negocio y a TI
- Realizar revisiones regulares de los Planes de Continuidad, al menos anualmente
- Negociar y gestionar los contratos con los Proveedores de Servicios de recuperación externos
- Gestionar la provisión de servicios de TI en situaciones de crisis:
o Coordinación del equipo de gestión de crisis
o Invocación del paso a las instalaciones de respaldo
o Gestión, dirección y arbitraje de los recursos
o Gestión del sitio de recuperación
G. de Incidencias Información de incidencias Procedimientos de
desastre
G. de Problemas Información problemas (Errores conocidos) Medidas
preventivas
G. de Cambios Info. Cambios RFCs, evaluación
de impacto
G. de la Configuración Líneas de Referencia, CIs Críticos, info. de
atributos relacionados con CIs
G. de la Disponibilidad Medidas disponibilidad Medidas
continuidad
G. del Nivel de Servicio SLR, SLA Procesos de
recuperación
G. Financiera de TI Estudios de costes ITSCM Estrategia de
ITSCM

4.21.Sistema de Gestión de Seguridad de la Información

Information Security Management System (ISMS)
4.21.1. Meta
Alinear la seguridad de TI con la del negocio y garantizar una gestión eficaz de seguridad en todos los
servicios y actividades de Gestión de Servicios
4.21.2. Objetivos
Garantizar la confiabilidad de las transacciones y el intercambio de información
La información es observada por o revelada sólo a aquellos que tienen derecho a saber
(confidencialidad)
La información es completa, exacta y protegida contra modificaciones no autorizadas
(integridad)
La información está disponible y utilizable cuando sea necesario, y los sistemas que la
proporcionan pueden resistir y recuperarse de los ataques o prevenir fallos (disponibilidad)
Las transacciones de negocios, así como el intercambio de información entre las empresas,
o con sus socios, son totalmente confiables (autenticidad y no repudio)
ISO 27001 Autenticación

Confidencialidad y non-repudio
Trabajar en la Information
concienciación Security Incidentes de Seguridad
de la seguridad Management
Disponibilidad Integridad
Sección de seguridad
en el SLA
4.21.3. Ámbito
La Seguridad no es realmente un paso en el Ciclo de Vida de los Servicios. Es un proceso continuado
e integra a todos los componentes como:
Asignar los recursos necesarios.

Generar la documentación de referencia necesaria.
Instalar y mantener las herramientas de hardware y software necesarias para garantizar la
seguridad.
Colaborar con la Gestión de Cambios y Gestión de Entregas para asegurar que no se
introducen nuevas vulnerabilidades en los sistemas en producción o entornos de pruebas.
Proponer RFCs al CAB que aumenten los niveles de seguridad.

Colaborar con la Gestión de la Continuidad del Servicio para asegurar que no peligra la
integridad y confidencialidad de los datos en caso de desastre.
Establecer las políticas y protocolos de acceso a la información.
Monitorizar las redes y servicios en red para detectar intrusiones y ataques
4.21.4. Valor
Gestión de la Seguridad de la Información se asegura de que una política de seguridad de la
información es mantenida y reforzada y que cumpla con las necesidades de la política de
seguridad del negocio y las del gobierno empresarial
Aumenta la conciencia de la necesidad de seguridad en todos los servicios de TI y activos
en toda la organización, asegurando que la política es apropiada para las necesidades de la
organización
Gestiona todos los aspectos de las TI y seguridad de la información en todas las áreas de TI
y las actividades de ITSM
Proporciona la seguridad de los procesos de negocio mediante la aplicación de controles de
seguridad apropiados en todas las áreas de TI y gestión de riesgos de TI, en línea con el
negocio y la organización

Las prácticas prudentes de negocios requieren que los procesos de TI y las iniciativas se
alinean con los procesos de negocio y objetivos. Esto es crítico cuando se trata de seguridad
de la información, que deben estar estrechamente alineado con la seguridad empresarial y
las necesidades del negocio
Todos los procesos dentro de la organización de TI deben incluir consideraciones de
seguridad
La dirección ejecutiva es en última instancia responsable de la información de la
organización y se encarga de responder a los problemas que afectan a su protección
De la alta dirección se espera que la seguridad de la información sea una parte integral de
la gestión empresarial
Todas las organizaciones Proveedores de Servicios de TI deben asegurarse de que tienen
una Gestión de Seguridad de la Información que integra las políticas y los controles de
seguridad necesarios para supervisar y aplicar las políticas
4.21.6. Marco de Trabajo de Seguridad

Actividades
Políticas de seguridad de la información específicas que tratan cada aspecto de la estrategia,
de controles y de la regulación
Sistemas de Gestión de la Seguridad de Información (ISMS), conteniendo los estándares, los
procedimientos de gestión y las pautas apoyando las políticas de seguridad de la
información
La estrategia comprensiva de la seguridad más cercana a los objetivos, a las estrategias y a
los planes del Negocio
Estructura de organización de la seguridad eficaz
Sistema de controles de seguridad para apoyar las políticas

Gestión de riesgos para la seguridad o Procesos de la supervisión para asegurar conformidad

y para proporcionar la regeneración en eficacia
Comunicaciones de la estrategia y plan para la seguridad
Entrenamiento y plan del conocimiento a toda la organización
4.21.7. Directivas de Seguridad para la Información

Las actividades de la Gestión de Seguridad de la Información deben centrarse en la política de
seguridad total de la información y un sistema de políticas de seguridad de específico para su
soporte.
Las políticas deben estar extensamente disponibles para todos los clientes y usuarios y su
conformidad deben de estar documentadas en todo el SLRs, SLAs, contratos y acuerdos.
Las políticas se deben autorizar por el Negocio y TI de sus respectivos gestores del alto nivel
(y la conformidad se debe conformar de forma regular por repasado y revisado anualmente.
Las políticas deben ser apropiadas, cubrir las necesidades del Negocio y cubrir todas las
áreas de la seguridad como por ejemplo:
Utilice una política del control de accesos

Uso erróneo de TI sobre política de los activos
Una política del email
Una política de control de contraseñas
Una política de antivirus
Una política de acceso a Internet
Una política de clasificación de documentos
Una política de clasificación de la información
Una política con respecto al acceso remoto
4.21.8. Marco de Gestión de Seguridad

Los ISMS proporcionan una base del desarrollo de un programa de la seguridad de información
para apoyar los objetivos del Negocio.
Implicará las cuatro P’s (personas, procesos, tecnología de los productos y outsourcings de los
socios) para asegurar niveles de la seguridad.
4.21.9. ISO 27000 (Marco para la Gestión de Seguridad)

El estándar contra el cual las organizaciones pueden obtener la certificación independiente de sus
ISMS (normalización para diseñar, para ejecutar, para manejar, para mantener y para hacer cumplir
procesos y controles de la seguridad de información, sistemática y constantemente). Los ISMS
demuestran un acercamiento ampliamente utilizado, también incluido en ISO/IEC 20001.
Se ha actualizado en Diciembre 2011 y se denomina ISO/IEC 27000-1:2011
4.21.10. Gestión de la Seguridad de TI basada en la ISO 27001

Control.
Organiza y crea un marco de gestión y asigna responsabilidades.
Planificación.
Políticas de SLAs, UCs, OLAs.
LOPD y legislación de los países donde tengamos oficinas.
Implementación.
Concienciación, Procedimientos, Formación, Incentivos,
Gestión de Seguridad de hardware y de software.

Implementación
Concienciación
Formación
Incentivos
Procedimientos
Incidentes de seguridad
Seguridad Hardware
Gestión de Derechos
Gestión de Permisos
Evaluación y Auditoria.
Interna, externa y autoevaluación.
Ingeniería Social.
Mantenimiento.
Aprender, planificar, implementar y mejorar
PLANIFICACIÓN
MANTENIMIENTO OLA’s
Aprender SLA’s
Planificar UC’s
Mejorar Declaraciones de
Implementar directivas
CONTROL
Organizar
Crear marco de trabajo
Asignar responsabilidades
IMPLEMENTACIÓN
Concienciación
Procedimientos
EVALUAR Formación
Auditorías internas Incentivos
Auditorias externas Incidentes Seguridad
Auto evaluación Seguridad hardware
Ingeniería social Gestión de derechos
Gestión de permisos
4.21.11. Gobierno de Seguridad

El gobierno de la seguridad de la información, cuando se está ejecutado correctamente, debe
proporcionar seis resultados básicos:
Alineación estratégica
Entrega de valor
Gestión de riesgos
Gestión del rendimiento
Gestión de recursos
Aseguramiento del proceso de Negocio

4.21.12. Control del Riesgo

Un riesgo se puede convertir en una amenaza que puede causar incidencias que causan daños por
lo que hay que tomar medidas
Medidas Preventivas (Gestión de Accesos)

Medidas Reductivas (Backups y pruebas)
Medidas Indagadoras (Detectar efectos)
Medidas Defensivas (Bloqueos)
Medidas Correctivas (Retirada)
4.21.13. Métricas
Porcentaje de disminución de incumplimiento de seguridad
Porcentaje de disminución del impacto de las incidencias e incumplimiento de
seguridad
Aumento de la concienciación sobre los procedimientos de seguridad en la
organización
4.21.14. Entradas
Información del Negocio (planes y Estrategias)
Políticas y directrices del gobierno corporativo
Información de servicios de las SLAs
Procesos e informes de análisis de riesgos
Detalles de eventos e incumplimiento de seguridad
Información de cambios desde Gestión de Cambios
CMS
Detalles del acceso a asociados y proveedores de terceros

4.21.15. Salidas
Políticas de seguridad corporativas
ISMS
CMS
Procesos e informes de evaluación de riesgos de seguridad revisados
Controles, auditoria e informes de seguridad
Programación adelantada de pruebas de seguridad
4.21.16. Posibles Problemas

Según Edward Deming el problema de la Gestión de Servicios de Calidad comienza en la Dirección
no en los empleados.
La seguridad aumenta la calidad.
Falta de compromiso.
Actitud humana, desconocimiento en el uso de la tecnología.
Ausencia de concienciación y comunicación.
Nivel de ambición fuera de lo real.
Falta de sistemas de detección de intrusos (IDSs).
Hackers internos.
Gestión de Cambios excesivamente dinámico y sin relación con ITSM.
Excesiva rotación de personal.
"Una cadena es tan resistente como el más débil de sus eslabones”
4.21.17. Éxito
Del éxito de la Gestión de Seguridad de la Información el beneficio será que:
La empresa esté protegida contra violaciones de seguridad

Que las políticas de seguridad estén bien definidas y adaptadas a las necesidades de
la organización
Existan procedimientos de seguridad justificados y apoyados por la alta dirección
La organización promueva y explique los requisitos de seguridad
Exista un mecanismo de mejora continua
4.21.18. Desafíos
En algunas organizaciones, la percepción empresarial es que la seguridad es una
responsabilidad de TI, y por lo tanto, la empresa asume que será responsable de
todos los aspectos de seguridad de TI así que estén adecuadamente protegidos. Sin
embargo, sin el compromiso y apoyo de la Gerencia y del personal de la empresa, el
dinero invertido en los controles de seguridad y procedimientos se habrán en gran
parte perdido, y que en su mayoría serán ineficaces.

4.21.19. Las 10 Leyes Inmutables de la Seguridad

(Para escapar del león no hay que correr más que el león, hay que correr más que la última gacela)
Las 10 Leyes inmutables de Seguridad. Standart NIST 800-30

Ley 1: Si una mala persona puede persuadirle de ejecutar un programa en su equipo, ese equipo
jamás será suyo.
Ley 2: Si una mala persona puede alterar su Sistema Operativo, ese equipo jamás será suyo.
Ley 3: Si una mala persona tiene acceso físico a su equipo, que lo tenía restringido, ese equipo
jamás será suyo.
Ley 4: Si una mala persona puede descargar un programa en su sitio Web, ese sitio Web jamás
será suyo.
Ley 5: Contraseñas débiles rompen la seguridad fuerte.
Ley 6: Un Sistema es tan seguro como la confianza que tenga la organización en su Administrador.
Ley 7: Los datos cifrados son solo tan seguros como segura esté la llave de descifrado.
Ley 8: Un antivirus no actualizado es mejor que ningún antivirus.
Ley 9: El anonimato absoluto es imposible, como en la vida real.
Ley 10: La Tecnología no es una panacea.
Gestión de
Capacidad Gestión de
Gestión de
Cambios
Continuidad
Gestión de
Gestión de Incidencias
Accesos Gestión de
Seguridad Gestión del
Gestión de Nivel de Servicio
Problemas
Gestión
Financiera de los
Gestión de la Servicios TI
Disponibilidad
Gestión de la
Configuración
Gestión de la
CMS
Proveedores


4.22.Gestión de Suministradores o Proveedores

4.22.1. Meta
Gestionar los suministradores y los servicios que ellos proporcionan para conseguir una calidad
consistente para el negocio y garantizando un precio adecuado
4.22.2. Objetivos
Obtener la optimización de recursos del suministrador y de los contratos.
Proporcionar ayuda para los SLAs, contratos, acuerdos, etc. de los suministradores o
de terceros, asegurando que se alineen con el Negocio.
Asegurar que los servicios de soporte estén documentados y las relaciones y
dependencias entre los suministradores sean lo convenido.
Coordinar y ayudar a que todos los encargados del suministro y del contrato de TI
tengan un Propietario nominado para cada proceso.
Mantener la Base de Datos del proceso (SCMIS–Supplier Contract Management
Information System) cuando esto sea requerido. Debe de estar integrada en el CMS
Asistir a las reuniones del CAB cuando es requerido.
Revisar y asesorar del riesgo con suministradores y SP de terceros...
Mantener un procedimiento para ocuparse de conflictos contractuales y asegurar de
que cualquier discrepancia está tratada eficientemente y de manera incluso eficaz.
4.22.3. Ámbito
Cuanto mayor sea la contribución de un suministrador, más esfuerzo deberá hacer el Proveedor de
Servicios para gestionar su relación con él.
Implementación y fortalecimiento de la política de los suministradores

Mantenimiento de la BBDD de suministradores y contratos (SCMIS)
Categorización de suministradores y contratos
Evaluación de riesgos con suministradores críticos
Desarrollo, negociación y acuerdos de contratos
Revisión, renovación y terminación de contratos

Obtener una buena relación precio-valor de suministradores y contratos para garantizar los
objetivos de los SLA. Así lograremos una consistencia de extremo a extremo.
Los principales objetivos del proceso de Gestión de Suministradores son de
proporcionar un valor para el dinero de los proveedores y los contratos, y asegurar
que todos los objetivos en los contratos con proveedores están alineados con las
necesidades del negocio y los objetivos acordados en los SLAs
Esto es para asegurar la entrega al Proveedor de Servicios, de extremo a extremo,
de TI con la calidad que se ajusten a las expectativas del negocio
El proceso de Gestión de Suministradores debe estar alineados con todos los
requisitos del negocio y los requisitos de todas las TI y procesos de gestión de
servicios, en particular, ISMS y ITSCM
Por ello es muy importante que SLM y SM se reúnan periódicamente para revisar los UCs.

4.22.5. Conceptos Básicos y Definiciones

El proceso de actividad de la Gestión de Suministradores se debe conducir por una estrategia y una
política de proveedores desde la Estrategia de Servicio
La Figura siguiente ilustra porqué un suministrador y una base de datos de los contratos (SCMIS)
deben ser establecidos para alcanzar consistencia y eficiencia en la puesta en práctica de la política,
de los roles y de las responsabilidades:
SS: Clasificación de suministradores y mantenimiento de los mismos y de la base de
datos de los contratos (SCMIS)
SD: Evaluación y disposición de nuevos suministradores y contratos
ST: Establecer nuevos suministradores
SO: Suministradores y contratos, gestión y funcionamiento
SO: Renovación y terminación de contratos
(Los dos primeros se cubren en la etapa del Diseño del Servicio, el tercero es parte de
Transición del Servicio y los dos últimos son parte de la etapa del Operación del Servicio)
Políticas y Estrategias
con Suministradores SS
Evaluación de SD
Contratos y
Suministradores
Establecer nuevo
Suministradores ST
Categorización de y Contratos
Suministradores y
Mantenimiento de la SCD
Gestión rendimiento
de suministradores SO
Sistema de y contratos
Información de
Gestión de los
Suministradores y
Contratos (SCMIS) Renovación SO
Terminación de
Contratos
Informe de los
Suministradores
4.22.6. Actividades
Identificación de las necesidades de la empresa y preparación del caso de negocio:
Elaborar un planteamiento de requisitos.
Garantizar que es conforme a la estrategia y a la política de la organización.
Preparar un caso de negocio inicial.
Evaluación y aprovisionamiento de nuevos suministradores y contratos:
Identificar el método para las adquisiciones.
Establecer los criterios de evaluación
Seleccionar
Negociar
Acordar y adjudicar el contrato.
Establecer nuevos suministradores y contratos
Dar de alta los suministradores y contratos en la SCMIS.
Realizar la transición del servicio.
Establecer los puntos de contacto y las relaciones.
Categorización de suministradores y contratos:

Evaluar o reevaluar suministradores y contratos.
Garantizar el progreso de los cambios en la Transición del Servicio.
Categorizar suministradores
Actualizar y mantener la SCMIS
Gestión del rendimiento de suministradores y contratos.
Gestionar y controlar la operación y entrega del servicio.
Monitorizar y reportar.
Revisar y mejorar.
Gestionar las relaciones con suministradores.
Revisar anualmente al menos el alcance del servicio respecto a las necesidades del
negocio, los objetivos particulares y los acuerdos.
Planificar los potenciales cierres.
Terminación de contratos.
Revisar.
Renegociar, renovar y terminar contratos.
Nuevas o modificadas directrices de Gobierno de la Empresa
Nuevas o modificadas estrategias de TI, políticas o planes de negocio
Nuevas necesidades de negocio o servicios nuevos o modificados
Requisitos nuevos o modificados dentro de los acuerdos, como los SLRs, SLAs, OLAs
o contratos
Examen y revisión de diseños y estrategias
Actividades periódicas, como la revisión o la presentación de informes, incluyendo la
revisión de las políticas de Gestión de Suministradores, informes y planes
Las solicitudes de otras áreas, en especial el BCM y la Gestión de Seguridad de la
Información, para obtener ayuda con problemas de proveedor
Los requisitos para los nuevos contratos, la renovación del contrato o la terminación
del contrato
Re-categorización de los proveedores y / o contratos el negocio nuevos o
modificados o cambios en los servicios.
4.22.8. Entradas
Información del negocio sobre planes y estrategias.
Estrategias de suministradores y contratos.
Detalles de planes de negocio.
Acuerdos y Contratos y objetivos
Información Financiera de los Servicios de TI
Información de TI
Información desde SLM
CMS
Información de Rendimiento por el Gestor Sénior de Operaciones de servicio
Detalles de los Contratistas y Suministradores

4.22.9. Salidas
Informes de investigación de suministradores actuales o futuros.
Una Sistema de Información de la Gestión de Contratos y Suministradores (SCMIS)
que contiene toda la información de contratos y proveedores y / o subcontratas
Planes de Mejora de los Servicios (SIP) para con los suministradores
Encuestas de satisfacción de los usuarios en cuanto a suministradores
Informes de rendimiento de Suministradores
Informes a la Gerencia de suministradores por volumen de compras, rendimiento,
fiabilidad, etc.
4.22.10. Métricas
El rendimiento de la Gestión de suministradores se puede medir en función de:
Aumento del número de suministradores que cumplen los acuerdos contractuales.
Aumento del número de objetivos contractuales que están alineados con SLA y SLR.
En la SCMIS hay que conservar toda la información y sus resultados para incluirlos
en la Cartera de Servicios.
4.22.11. Desafíos
Trabajar con un modelo no ideal del contrato, con pobres objetivos en los términos
y condiciones, o una definición mala o inexistente en el servicio o los objetivos de
desempeño de los proveedores
Los problemas heredados, en particular con servicios subcontratados
Insuficiente conocimiento dentro de la organización
Estar atados a contratos a largo plazo, sin posibilidad de mejora, que tienen
penalizaciones por el abandono prematuro
Las disputas por penalizaciones
La interferencia de cualquiera de las partes en el funcionamiento del otro
Falta de comunicación. No interactúan lo suficientemente rápido
Los conflictos de personalidad y / o los conflictos culturales
Una de las partes con el contrato en detrimento de la otra parte, dando como
resultado ganar-perder los cambios en lugar de articular los cambios de ganar-ganar

Cambios constantes en las necesidades de TI y del negocio.
Imperfección en los contratos.
Poca experiencia de la organización.
Duración excesiva de los contratos.
Para superar los posibles problemas hay que prestar la debida atención a:
Procesos de Gestión de Servicios bien definidos y perfectamente documentados.
Relaciones entre ambas partes.
Roles bien definidos.
Buena comunicación y empatía.

4.22.13. Éxito
Dependerá de la protección ante bajo rendimiento del suministrador.
También de que los objetivos del servicio estén ajustados a los requisitos del
negocio.
Y de la claridad de los contratos y de la cultura corporativa de los suministradores.
4.22.14. Riesgos
Acuerdos contractuales impracticables y de difícil cumplimiento.
Falta de compromiso del negocio y la alta gerencia con el proceso de Gestión de
Suministradores y los procedimientos
La falta de políticas de información apropiada sobre los futuros negocios y de TI,
planes y estrategias
La falta de recursos y / o el presupuesto para el proceso SM
El legado de los contratos está mal escrito y no sustentan ni apoyan las necesidades
de negocios o SLA y objetivos SLR
Los proveedores fallan o son incapaces de cumplir con los términos y condiciones
del contrato
El personal o la cultura del Proveedor no están alineados con el de prestador de
servicios o negocios
La falta de claridad y de la integración de proveedores con los procesos de gestión
de servicios, políticas y procedimientos del proveedor de servicios
Los proveedores no cooperan y no están dispuestos a participar y apoyar el proceso
de Gestión de Suministradores necesarios
Los procedimientos de contratación son excesivos y muy burocráticos
4.22.15. Roles de Gestión de Suministradores
Propietario del Proceso de Gestión de Suministradores

Sus responsabilidades son:
SLAs, contratos, acuerdos, etc.
Proveer ayuda en el desarrollo y la revisión de SLAs, de UCs, de acuerdos o de cualesquiera otros
documentos para los suministradores de terceros
Asegurar que los contratos, los acuerdos, SLAs estén alineados con el negocio
Asegurar que los Servicios de Soporte sean amplios y que estén documentados y
que los interfaces y/o dependencias entre los suministradores sean claras y
soportadas entre ellos
Se acuerden y se documenten los procesos
Asegurar de que los roles y las relaciones entre el núcleo de TI y los suministradores
subcontratados estén documentados, mantenidos y contractualmente convenidos
Coordinar y ayudar a todas las personas de TI del suministrador y los encargados de
contratar
Asegurar de que cada uno de los suministradores tenga un dueño nominado
SCMIS–Supplier Contract Management Information System
Mantener y revisar los suministradores y la (SCMIS)
Actualización de Contratos/SLAs cuando sea requerido, según el proceso de la
Gestión de Cambios
Asegurarse que los cambios estén determinados por su impacto en suministradores,
Servicios de Soporte y contratos

Asistir a las reuniones del CAB cuando sea apropiado

Revisión & Evaluación de riesgos
Revisión regular del riesgo de todos los suministradores y contratos
Repasar los procesos de los suministradores contratistas para asegurarse de que los
suministradores subcontratados cumplen sus requisitos contractuales
Realizar las revisiones de contratos/SLAs para asegurar consistencia con los
requisitos y condiciones estándar
Asegurarse de que la optimización de recursos sea obtenida por todos TI de los
suministradores y los contratos
Asegurarse de que todos los procesos TI de los suministradores sean constantes e
interconecte a todas las estrategias corporativas de subcontratistas, procesos y
condiciones estándar
Conflictos
Mantener un proceso para ocuparse de conflictos contractuales. Asegúrese de que
cualquier conflicto sea tratado de forma eficiente y con efectividad
Mantenga un proceso para ocuparse del final previsto, del final adelantado o de la
transferencia de un servicio
Revise, supervise e informe del rendimiento de los suministradores contra objetivos
marcados
Gestión de
Seguridad Gestión de
Nivel de Servicio
Gestión
Financiera de TI
Gestión de
Gestión de
Suministradores la Cartera
Gestión de la
Continuidad Gestión de
Gestión de la Cambios
Disponibilidad
4.22.17. Relaciones complejas

4.23.Actividades dentro del Diseño del Servicio

Además de los Ocho procesos anteriores hay TRES actividades importantes.
1. Desarrollo de Requisitos
2. Gestión de la Información y los Datos
3. Gestión de Aplicaciones
4.23.1. Desarrollo de Requisitos:

Se distinguen tres tipos diferentes de requisitos:
Requisitos funcionales: Describe asuntos para crear un servicio y sería una tarea
o función para la que hay que desarrollar un componente. Se usan diferentes
modelos como:
Diagrama de contexto del sistema
Modelos de casos de uso.
Requisitos de gestión y operación: Describen asuntos NO funcionales de los
servicios como es la estimación de costes. Se relaciona con aspectos de la calidad
como:
Capacidad de gestión
Capacidad y rendimiento
Capacidad de control
Capacidad de mantenimiento
Capacidad de operación
Capacidad de medida y comunicación
Seguridad
Instalación
Eficiencia
Requisitos de usabilidad: Garantizan que los usuarios verán cumplidas sus
expectativas en términos de facilidad de uso.
Desarrollar estándares de rendimiento para evaluaciones.
Definir escenarios de prueba
4.23.2. Investigación de requisitos

Los usuarios suelen dudar de cuáles son los requisitos, lo que implica un desarrollador de
requisitos hábil ya que al entrevistar a los usuarios puede parecerles que es un técnico informático
el que va a decidir los requisitos. De otra manera, tiene que tener tacto. Posibles métodos de
investigación.
Entrevistas
Reuniones de trabajo
Observación
Análisis de protocolos
Prototipos
Análisis de escenarios

4.23.3. Problemas en el desarrollo de requisitos

Falta de claridad
Terminología extremadamente técnica y por ello confusa
Duplicidad de requisitos
Falta de relevancia para los objetivos del servicio
Incertidumbre por parte de los usuarios
Conflictos entre requisitos
Niveles de detalle inconsistentes
4.23.4. Documentación de requisitos

En el centro de este desarrollo debe de haber un documento de requisitos en una plantilla estándar
y debe de estar formulado según el modelo SMART (Singulares, Medibles, Adecuados, Realistas y
ligados al Tiempo).
Es necesaria una revisión de los requisitos para verificar que sean claros, inequívocos y razonables.
Esta revisión tiene que formar parte del catálogo de requisitos en la Cartera de Servicios.
4.23.5. Gestión de la Información y de los Datos

Los datos son uno de los aspectos más importantes que hay que controlar para que:
Los usuarios puedan acceder a los datos para su trabajo
Se puedan compartir los datos dentro de la organización
La calidad de los datos sea a nivel aceptable
Se tengan en cuenta los aspectos legales sobre Seguridad, privacidad y
confidencialidad
Esta gestión comprende cuatro áreas.
Gestión De Fuentes De Datos: las fuentes y las responsabilidades tienen que ser
muy claras y cubre las siguientes responsabilidades
Definir necesidades de la información

Desarrollar un inventario de datos
Desarrollar un modelo de datos
Detectar deficiencias y ambigüedades
Mantener un catálogo
Evaluar los costes y recompensas de los datos
Gestión de tecnología de información y datos: está relacionada con la gestión de
TI y cubre aspectos como la gestión de BBDD.
Gestión de procesos de información: Controla el Ciclo de Vida de los Datos
(Proceso de creación, recolección,, modificación, acceso, almacenamiento,
eliminación y archivo de datos)
Gestión de estándares y política de datos: Se deben definir estándares y políticas
para la gestión de datos.

4.23.6. Clasificación de los datos

Hay tres niveles:
Datos operativos: Los necesarios para el funcionamiento de la organización.
Datos tácticos: Necesarios para la gestión de línea o superior.
Datos estratégicos: Definen estrategias a largo plazo por comparación con
informes externos.
4.23.7. Gestión de Aplicaciones

Hay dos enfoques:
Ciclo de Vida de Desarrollo del Servicio (SDLC) y consta de los siguientes pasos:
Estudio de viabilidad
Análisis
Diseño
Realización de pruebas
Implementación
Evaluación
Mantenimiento
Mantenimiento de aplicaciones
4.23.8. Desarrollo Rápido de Aplicaciones (RAD)

RAD es la introducción de incrementos e iteraciones en el proceso de desarrollo para la gestión de
los riesgos asociados con requisitos cambiantes y ambiguos. Es necesario afrontar el cambio ya
que, de no hacerse, podría significar una actitud irresponsable con respecto al negocio
Los métodos RAD aceptan que el cambio es inevitable e intentan minimizar los costes a la vez que se
mantiene la calidad requerida
El uso de incrementos implica que un servicio se desarrolla pieza a pieza, y cada pieza podría dar
soporte a una de las funciones de negocio que el servicio necesita
El desarrollo iterativo implica que el diseño atravesará más de una vez el ciclo de vida. Se emplean
técnicas como la creación de prototipos para entender mejor los requisitos (mediante actividades de
prueba, funcionales, de gestión y operativas y a través de la comunicación con los usuarios)
Se debe empezar con la especificación de requisitos para todo el servicio, seguido por el diseño y
desarrollo incremental de la aplicación
Extreme Programming y Scrum son claros ejemplos


4.24.Organización – Roles y Responsabilidades

4.24.1. RACI (Responsible-Accountable-Consulted-Informed)
Modelo RACI es beneficioso para la toma de decisiones con confianza.
Aclara a todos los participantes las actividades que se esperan de ellos.
Se identifican las lagunas en el proceso de entrega y las responsabilidades.
RACI es un acrónimo de
Responsible (Responsable de ejecutar o Encargado) - La persona responsable de conseguir que el
trabajo esté hecho. Se puede compartir la Responsabilidad.
Accountable (Alto responsable) – Aquella única persona que es responsable final de cada tarea.
Consulted (Consultado) - Las personas expertas a las que se recaban opiniones.
Informed (Informado) - Las personas que se mantienen al tanto de progresos
Ocasionalmente una versión ampliada de RACI se utiliza llamado RACI-VS con 2 nuevas funciones de
la siguiente manera:
• Verifies - La persona o grupo que comprueba si los criterios de aceptación se cumplen
• Signs off - La persona que aprueba la decisión V y entrega el producto. Este podría ser el de
persona A
Ejemplos
Director de Director Gestor de Gestor de Empleados
Gestión de Servicios Problemas Proveedores de la
Servicios Web organización
Actividad 1 A R C C I
Actividad 2 A C R I C
Actividad 3 I R A C C
Actividad 4 I A R R I
Actividad 5 AR C C C I
LAS “A”:
• Una “A” para más de una persona. En la práctica no funciona.
• Ninguna “A”. Al menos una se debe asignar a cada actividad
Las “R”
• Muchas “R”s: ¿no es demasiado para una función? La responsabilidad puede ser
compartidas pero sólo si los roles están claros.
• Ninguna “R”. Debe haber al menos una persona responsable
LAS “C”:
• Muchas “C”: ¿Son necesarias ? ( ojo carga de trabajo )
• Ninguna “C” ni “I”. Analizar los canales de comunicación
Para crear el sistema RACI necesita que la organización haga los siguientes pasos:
Identificar actividades y procesos
Identificar roles funcionales
Delegar los códigos RACI
Identificar carencias y posibles solapamientos
Comunicar el esquema y tener en cuenta la retroalimentación
Verificar que se siguen las asignaciones de funciones

4.24.2. Aptitudes
Tener conocimiento de los objetivos del negocio y sus prioridades
Tener aptitudes de servicio al cliente
Conocer a fondo el rol que desempeñan las tecnologías de la información
Tener los conocimientos y las competencias para desempeñar la función

Más de una persona responsable = nadie responsable
Delegación de la responsabilidad sin autoridad necesaria
Centrarse en los procesos y actividades con los departamentos
Falsa división y/o combinación de funciones
Agendas o metas en conflicto
4.24.4. Roles más destacados a incluir en una matriz RACI

I. Propietario del Proceso
Es responsable que el proceso se implementa según lo acordado y que se cumplen los objetivos
establecidos y de obtener unos resultados. Debe de:
Documentar y registrar el proceso.
Definir los KPIs y revisarlos.
Aumentar la eficacia y la eficiencia del proceso.
Pasar la información necesaria para el Plan de Mejora de Servicio (SIP).
Revisar de forma continua el proceso, los roles y las responsabilidades.
II. Gestor del Diseño del Servicio
Es el coordinador general y facilita los diseños del servicio. Sus tareas básicas son:
Garantizar que la Estrategia del Servicio se corresponde con el proceso de diseño
y que estos satisfacen los requisitos establecidos.
Diseñar los aspectos funcionales de los servicios
Preparar y mantener la documentación de diseño
Evaluar la eficacia y la eficiencia del proceso de diseño
III. Gestor del Catálogo de Servicios
El Service Catalogue Manager es responsable de producir y mantener el Service Catalogue,
incluyendo:
Asegurándose de que todos los Servicios operacionales y todos los servicios que
son preparados para el funcionamiento en vivo estén registrados dentro del
Catálogo del Servicio.
Asegurándose de que toda la información dentro del Catálogo del Servicio sea
exacta y hasta el más mínimo detalle de los datos.
Asegurándose de que toda la información dentro del Catálogo del Servicio sea
constante con la información dentro de la Lista de los Servicios.
Asegurándose de que la información dentro del Catálogo del Servicio esté
protegida y soportada adecuadamente.

IV. Gestor del Nivel de Servicio

Es responsable en general de:
Diseñar, acordar y mantener los SLAs con los clientes.
Comprobar que se han identificado todos los requisitos presentes y futuros del
cliente.
Negociar y alcanzar con los clientes acuerdos para proveerles de servicios.
Garantizar que lo acordado en las SLAs se cumplan por parte de TI.
V. Gestor de la Disponibilidad
Es el responsable de la disponibilidad de los componentes, servicios y procesos de negocio y entre
sus tareas están:
Garantizar que los servicios existentes estén disponibles según lo acordado.
Colaborar en la investigación y diagnóstico de todos los incidentes y problemas.
Contribuir al diseño de la infraestructura de TI.
Mejorar de forma proactiva la disponibilidad de los servicios.
VI. Gestor de la Seguridad
Desarrollar y mantener la política de seguridad de la información y las políticas favorables que
aseguren la Confidencialidad, Integridad y disponibilidad (CIA) de los datos. Las responsabilidades
incluyen
Comunicar y publicar las políticas de seguridad de la información a todos los
departamentos apropiados.
Diseñar los controles de seguridad y sus planes.
Convertir los procedimientos en documento para el funcionamiento y los
controles de seguridad que se han de mantener.
Ayudar con Análisis de Impacto en el Negocio sobre lagunas de seguridad.
Realizar el análisis y la gestión del riesgo para la seguridad con Gestión de
Disponibilidad y de Continuidad en ITSCM.
Realizar las pruebas de seguridad y entrenamiento del personal de TI.
Supervisar y manejar todas las brechas de la seguridad y tomar las medidas
remediadoras para prevenir la repetición donde sea posible.
Información, análisis y reducción del impacto y de los volúmenes de todos los
incidentes de la seguridad en colaboración con la Gestión de Problemas


4.25. Métodos, técnicas y herramientas

Para el Diseño del Servicio son muchas las herramientas que hay en el mercado que sirven de
soporte a los procesos Y NO AL REVÉS. Estas no solo hacen posible los diseños de software y
hardware, sino de entornos, procesos y datos con los beneficios de:
Desarrollar modelos y prototipos
Más rapidez en el proceso del diseño
Consideraciones como (¿Qué ocurriría si . . .?
Cumplir con los estándares y leyes reguladoras
Se sugiere adquirir y usar herramientas que esté totalmente integradas en el Ciclo de Vida de la
Gestión de Servicios. Se aconseja emplear una Declaración de Requisitos (SoR) y antes hacer un
análisis MoSCoW
M (must): Indispensable
S (should): Recomendable
C (Could): Optativo
W (won’t): Descartado (ahora no pero quizás en el futuro)

Porcentaje de requisitos del Diseño del Servicio especificados en plazo
Porcentaje de requisitos del Diseño del Servicio especificados en presupuesto
Porcentaje de paquetes del Diseño del Servicio preparados en plazo
Precisión del diseño del Servicio
Precisión de los SLAs, OLAs y UCs
4.25.2. Desafíos
Resistencia a trabajar de manera sistemática
Uso de muy diversas tecnologías y aplicaciones
Sincronización entre arquitectura, estrategias y políticas
Falta de claridad en los requisitos del cliente
Uso poco eficiente de los recursos
4.25.3. Riesgos
Falta de tiempo asignado al diseño del servicio
Falta de claridad en los requisitos del negocio para el personal de Ti
Si un proceso tiene un grado de madurez bajos afectará a los relacionados

4.26.El Gran Cuadro
Nuevos
requerimientos
Estrategia Paquete de Transición Operación Nuevos

Estrategias y del del
del Servicio Diseño del servicos
(SP) limitaciones Servicio (SDP) Servicio (PR) Servicio operacionales
Arquitectura Métodos de medición Diseño del Servicio
Análisis de requerimientos Diseño de la Evaluación de Procurar la Desarrollar la

Documentación y acuerdos Solución del servicio soluciones alternativas solución preferida solución
Gestión de Coordinación del Diseño de los Servicios
Capacidad: Disponibilidad: ITSCM: Seguridad: Sumi9nistradores:

SLM: Planes, Políticas, Políticas, Políticas,
Cartera Informes,
Planes,
planes, AMIS, planes, BIA,
planes, Políticas,
Políticas, Análisis de planes,
De Directivas,
Informes,
Análisis de BCP, SCP, riesgos, contratos,
SIP, SLR, riesgos, informes, Informes,
Servicios Modelado Informes, análisis de Control de informes, SCD
OLA, SLA programación riesgos
riesgos
CM IS
Catálogo
de Gestión
Servicios Catalogo SLM Capacidad Disponibilidad ITSCM ISMS Proveedores
Entradas a los procesos desde otras áreas: Eventos, Incidencias, Problemas, Peticiones de Servicio, Accesos, Cambios,
Configuración, Conocimiento, Entrega y Despliegue (Planeamiento, Evaluación, Construcción y Pruebas, Aceptación),
Financiero, Cartera, Demanda, etc.
En este gráfico se muestra que al diseñar soluciones, las entradas de muchas y diversas
áreas necesitan ser consideradas dentro de las varias actividades implicadas en el Diseño
del Servicio.
Hay que identificar y analizar los requisitos antes de construir una solución y un SDP para
entregar a la Transición del Servicio de modo que este pueda ser operacional.

Transición del Servicio .5
5.1. Transición del Servicio en el Ciclo de Vida de los Servicios

5.1.1. Meta
La gestión y coordinación de procesos, sistemas y funciones para empaquetar, estructurar, probar
y desplegar un “lanzamiento” en un entorno de producción y establecer los Servicios especificados
en los requerimientos de la SLA.
Reducir las variaciones previstas y actuales de los servicios en transición.

Reducir los errores conocidos y minimizar los riesgos de los servicios en transición nuevos
o cambiantes dentro del entorno de producción.
Dar soporte al proceso del cambio del Negocio.
Garantizar que el servicio satisface las especificaciones requeridas.
Aumentar la satisfacción del cliente y fomentar el uso correcto de los servicios y de la
tecnología
5.1.2. Objetivos
Gestionar y coordinar procesos, sistemas y funciones para empaquetar, estructurar,
probar y desplegar una versión de un servicio o parte de él (CI) en un entorno de
producción.
Establecer los Servicios especificados en los requerimientos del SLA.
Asegurarse de que se puede gestionar, operar y soportar el servicio.
Permitir la integración del lanzamiento de los procesos y de los servicios en el Negocio.
Evitar el Big Bang.
Proporcionar conocimiento de calidad sobre la Gestión de Cambios y Gestión de Entregas
y Despliegues.
Reducir las variaciones previstas y actuales de los servicios en transición, tanto en la
introducción como en su retirada.
Reducir los errores conocidos y minimizar los riesgos de los servicios en transición, nuevos
o cambiantes dentro del entorno de producción
Asegurar que el Servicio se pueda utilizar de acuerdo a los requisitos contratados con el
cliente o Interesados

¿Qué es el Valor para el Negocio en Transición del Servicio?
Capacidad de adaptarse rápidamente a los nuevos requisitos y progresos del mercado.

La gestión de la transición facilita la administración de fusiones y de alianzas definitivas o
temporales de negocios y la transferencia de servicios.
Aumenta el índice de éxitos de cambios y de lanzamientos para el Negocio.
Mejora las predicciones de los porcentajes de disponibilidad y de las garantías para los
nuevos y cambiantes servicios.
Confianza en el grado de conformidad con SLRs del Negocio durante cambios
Disminuye la variación de real contra planes estimados y aprobados de recursos y
presupuestos.
Cancelación o cambios oportunos de Contratos de Mantenimiento cuando se disponen o
se desarman los componentes de hardware y software
5.1.4. Ámbito
Transición del Servicio proporciona una guía para el desarrollo y la mejora de las
capacidades para la transición de servicios nuevos y modificados en los entornos de
soporte, incluida la planificación de Entregas y Despliegues, construcción, pruebas,
evaluación e implementación
Esta fase considera la retirada de servicios y la transferencia de servicios entre
Proveedores de Servicios (SP)
Esta fase también se centra en cómo garantizar que los requisitos de la Estrategia de
Servicios y su desarrollo en Diseño del Servicio, son llevados a la práctica para su puesta en
Operaciones del Servicio a un entorno de producción
Su ámbito también llega a lo relacionado con minimizar el riesgo de los fracasos en la
puesta en marcha de los servicios

Gestión de Cambios
RFC1 RFC2 RFC3 RFC4 RFC5 RFC6
Gestión de Configuración y Activos del Servicio (SACM)

BL BL BL BL BL BL
Planificación y Soporte de la Transición del Servicio
Gestión de Cambios en la organización y las partes interesadas
Evaluación de un cambio de servicio

E E E
Operación
Estrategia del
del Revisión y Servicio
Servicio Planificación Pruebas y Planificación Transferencia
Construcción Cierre de la
y Preparación Pilotos de y Preparación Despliegue y
y pruebas Transición del
de versiones servicios de despliegue retiro Servicio
Diseño
del
Servicio Gestión de Versiones y Despliegues Soporte Post Implementación
Validación y pruebas del servicio

Gestión del Conocimiento (SKMS)

La Transición del Servicios es eficiente si dentro de los límites propios de la organización produce
lo que requiere la empresa en términos dinerarios. Por ello es muy importante conocer hasta qué
punto los resultados de la Transición responden a las especificaciones del Diseño del Servicio.
Las diferencias pueden afectar al tiempo, el dinero, la calidad y los riesgos.
5.1.5. Actividades
1. Definición de la estrategia de transición.

2. Preparación de la Transición del Servicio.
3. Planificación y coordinación de la Transición del Servicio.
4. Soporte
1. Definición de la estrategia de transición.
Propósito, metas y objetivos.
Contexto y alcance.
Estándares aplicables, acuerdos legales, regulatorios y contractuales.
Organizaciones y grupos de interés implicados en la transición del servicio.
Marco de trabajo para la transición del servicio.
Criterios de éxito y de fallo.
Roles y responsabilidades.
Planteamientos tales como modelo de transición, planes para gestionar cambios,
activos y KPIs.
2. Preparación de la Transición del Servicio.
Revisión y aceptación de entradas desde otras fases del Ciclo de vida del servicio.
Verificación de las entradas que se reciben (SAC) (SDP) e informes de evaluación.
Identificación, registro y programación de (RFCs)
Verificación de las entradas en la CMDB antes de comenzar la Transición del Servicio.
3. Planificación y coordinación de la transición del Servicio.
Entorno de trabajo e infraestructura
Programación de hitos.
Actividades de tareas que se realizarán.
Personal, recursos, presupuesto y plazos en cada etapa.
Tiempo total de entregas y contingencias.
Revisiones de calidad dentro de la planificación y coordinación:
¿Están los planes de Transición del Servicio y los planes de entrega actualizados,
autorizados y se conocen las fechas de entrega?
¿Se han tenido en cuenta los riesgos que pueden afectar a los costes, organización y
tecnología?
¿Son compatibles entre sí y con el entorno los nuevos CIs?
¿Ha recibido el personal de TI implicado la formación necesaria’
¿Se han tenido en cuenta los posibles cambios en el negocio del cliente’
4. Soporte del proceso de transición
La Transición del Servicio da soporte y asesora a todos los Interesados
Se monitorizan las actividades comparando la implementación de actividades con las
previstas.

5.1.6. Disparadores
El disparador de la Transición del servicio es un RFC aprobado.
5.1.7. Entradas
RFCs autorizadas
SDP
Definición del paquete de entrega y requerimientos del diseño.
SAC
5.1.8. Salidas
Estrategia de transición.
Colección integral de planes de transición del Servicio.
5.1.9. Métricas
Número de entregas implementadas que cumplen los requisitos acordados con el cliente.
Descenso en el número de desviaciones respecto al ámbito, calidad, costes y recursos
previstos.
Mayor satisfacción del cliente y usuarios con los planes y la comunicación.
Descenso en el número de problemas, riesgos y retrasos por una mejor implementación.
5.1.10. Políticas para la Transición de Servicios en una organización

Definir e implementar una política formal para la Transición del Servicio
Implementar todos los Cambios a través de Transición del Servicio
Adoptar un marco de trabajo común y estándares
Maximizar la reutilización de procesos y sistemas establecidos
Alinear los planes de Transición del Servicio con las necesidades del Negocio
Establecer y mantener relaciones con los Interesados
Establecer controles y políticas eficaces
Proporcionar sistemas para la transferencia de conocimiento y para el soporte de las
decisiones
Planear entregas y distribución por paquetes. Evitar el big bang
Anticipar y gestionar cambios de alcance
Gestionar proactivamente los recursos a través de las transiciones de los servicios
Garantizar la implicación anticipada en el Ciclo de Vida del Servicio
Asegurar la calidad de los nuevos o modificados servicios
Mejorar de forma proactiva la calidad durante la Transición del Servicio

5.1.11. Línea de Referencia (Baseline) (BL)

Configuración de un CI, sistema o servicio en un momento específico.
Contiene todos los datos para volver a otro momento. (Back-outs)
Es una foto instantánea que se registra de un CI o de un grupo de CIs que se utilizará como
referencia y posterior comparación.
La CMDB contiene la trazabilidad de todas Líneas de Referencia.
5.1.12. Criterio de Aceptación del Servicio (SAC)

SAC - Service Acceptance Criteria. Conjunto de criterios utilizados para asegurar que un
Servicio de TI cumple con su Funcionalidad y Requisitos de Calidad y que el Proveedor de
Servicio de TI está preparado para operar el nuevo Servicio de TI una vez ha sido
Implementado.


5.2. Procesos y otras Actividades
Planificación y Soporte de la Transición

Gestión de Cambios
Gestión de Configuración y Activos del Servicio
Gestión de Entregas y Despliegues
Evaluación del Cambio
Validación y Pruebas del Servicio
Gestión del Conocimiento (SKMS).


5.3. Planificación y Soporte de la Transición

Realización de un plan documentado de lo especificado en Design Service, asegurando la
identificación, gestión y minimización de riesgos que pudieran interrumpir el servicio durante la
transición e incluye:
A. Especificaciones de diseño y requisitos del departamento de producción.
B. Gestión de:
Planeamiento
Actividades de ayuda y soporte
Progreso en el tiempo de la transición
Cambios
Problemas
Riesgos
Desviaciones
Procesos
Herramientas y sistemas para soporte
Monitorización del rendimiento
Comunicación con clientes, usuarios e interesados
C. Y las actividades de:
Definición de la estrategia de la transición.
Preparación de la Transición del Servicio.
Planificación y coordinación de la Transición del Servicio.
Soporte.
5.3.1. Ámbito
Coordinar actividades de ayuda y soporte
El mantenimiento de las políticas, normas y modelos para las actividades de Transición
del Servicio y sus procesos
Dirigir cada gran cambio de un servicio nuevo o modificado, a través de los procesos de
Coordinar los esfuerzos necesarios para permitir a múltiples transiciones al mismo
tiempo
Fijar las prioridades en conflicto por los recursos a través de Transición del Servicio
Planificar el presupuesto y los recursos necesarios para cumplir con las necesidades
actuales y futuras de los servicios
Revisar y mejorar el rendimiento de la Planificación y Soporte de la Transición y apoyar
sus actividades
Asegurar que la Transición de Servicios es coordinado con gestión de proyectos, Diseño
de Servicios y actividades de desarrollo
5.3.2. Disparadores
El disparador para la planificación de una sola transición es un cambio autorizado
Planificación a largo plazo puede ser desencadenada por la recepción de una propuesta
de cambio de la Gestión de la Cartera de Servicios
El presupuesto para las necesidades futuras de la transición se iniciará a través del ciclo
presupuestario de la organización

5.3.3. Roles
El Propietario del PROCESO es responsable de que todas las actividades se llevan a cabo e
interviene en la Estrategia del Servicio y ayuda al Diseño del Servicio.
Asegura que existen las documentaciones de los procesos, directrices, procedimientos
y su aplicación.
Garantiza que se dispone de los recursos adecuados.
El Propietario del SERVICIO tiene las responsabilidades ante el cliente para la iniciación y
transición de un servicio nuevo o cambiante.
Actúa como el primer contacto con el cliente para todo lo relacionado con ese Servicio
y mantiene investigaciones y ediciones para mejoras.
Se asegura de que todo lo que esté en curso y para la entrega del Servicio cumple los
requisitos del cliente.
Se comunicará con los propietarios de los procesos apropiados del Ciclo de Vida a
través de Gestión a Nivel de Servicios (SLM).
Solicitará los datos, estadísticas e informes para el análisis y facilitará la supervisión y el
funcionamiento eficiente del Servicio.
Será el responsable ante el Director de TI para la entrega del servicio.
5.3.4. Desafíos y Factores Críticos de Éxito
Para lograr la eficacia de la Transición del Servicio hay que hacer frente a los
siguientes desafíos:
Tener en cuenta a las partes interesadas.
La falta de armonización e integración de procesos y disciplinas que afecten a la
transición del Servicio.
Conseguir el equilibrio entre un entorno de operación estable y la capacidad de
responder flexiblemente a cambios en los requisitos del negocio.
Encontrar un equilibrio entre burocracia y pragmatismo.
Crear un entorno para la estandarización y el intercambio de conocimientos.
Garantizar que la calidad de los servicios responde a la calidad de los negocios.
Encontrar el equilibrio entre “asumir riesgos” y “evitar riesgos”.
Definir claramente los roles y responsabilidades.
Disponer de las herramientas adecuadas que hay en el mercado.
Desarrollar sistemas de calidad, herramientas, procesos y procedimientos para la
Transición del Servicio.
5.3.5. Riesgos
Falta de motivación del personal como consecuencia de cambios en sus roles y
responsabilidades.
Gastos no previstos.
Oposición cultural al cambio.
Falta de intercambio de conocimientos.
Integración defectuosa entre procesos.
Falta de madurez empresarial e integración de sistemas y herramientas.
Falta de presupuesto.
Problemas políticos.

5.4. Gestión de Cambios

Un CAMBIO es la adición, modificación o eliminación aprobada y soportada o
inclusive el retorno a la Línea de Referencia de cualquier servicio o de uno o varios
CIs y su documentación asociada.
5.4.1. Objetivos:
Asegurar que se usen procedimientos y métodos estandarizados para el manejo de todos
los cambios asegurando en todo momento la calidad y continuidad del servicio TI.
Garantizar que los cambios se registran en la CMDB.
Minimizar el riesgo que conlleva un cambio.
Realización de cambios con éxito al primer intento.
Que los cambios se puedan deshacer mediante back-outs en caso de incorrecto
funcionamiento.
5.4.2. Hay dos autoridades en la Gestión de Cambio:

El Gestor del Cambio y
El Consejo Asesor del Cambio (CAB).
5.4.3. Actividades más importantes

Planificación y gestión de cambios.
Planificación de versiones.
Autorización o denegación de cambios
Comunicación
Definición de planes de back out.
Generación de informes a la gerencia.
Evaluación de impactos.
Estandarización de determinados cambios.
Presidir el CAB
Mejora continua en los cambios.
5.4.4. Actividades más específicas de Gestión de Cambios

Registro de la solicitud del cambio (RFC)
Revisión de la RFC
Valoración y evaluación del cambio.
Justificación del cambio.
Autorización o denegación del cambio.
Planificación de actualizaciones.
Coordinación de la implementación de los cambios.
Monitorización después del cambio (PIR).
Cierre del cambio

Registro y
I ÓN Análisis y evaluación
Filtrado
C de impacto, coste,
MA
Cierre beneficio y riesgo
del RFC
F O R Gestión de
I N
Monitorización
de la implementación
Cambios
Justificación y
desarrollo del
Cambio
PIR
Aprobación
Coordinación
Presidir de la Lista de Cambios
CAB y ECAB Planificada
Los cambios en los servicios pueden tener un impacto negativo en los negocios por
interrupciones y retrasos en la identificación de requisitos.
Por ello una buena Gestión de Cambios ahorrará paradas inesperadas y así añadir valor al
negocio como por ejemplo:
Cambios relacionados con normativas financieras.

Cambios rápidos para cumplir los plazos del negocio.
Reducción del número de cambios fallidos.
Reducción del Tiempo Medio de Restauración del Servicio (MTRS).
5.4.6. Políticas
Las políticas favorecedoras de la Gestión de Cambios son:

Cultura de tolerancia cero para cambios no autorizados.
Priorización efectiva.
Establecer roles y responsabilidades finales.
Establecimiento de un punto único para controlar los cambios.
Integración en otros procesos de Gestión de Servicios.
Definición de ventanas de cambio, KPIs de rendimiento y evaluaciones de riesgo.
5.4.7. Diseño y planificación
Gestión de Cambios se planifica en conjunción con Gestión de Entregas y Despliegues y

Gestión de la Configuración y Activos del Servicio y se debe incluir:
Requisitos relativos a normas legales y leyes del país.
Método de eliminación de cambios no autorizados.
Identificación y clasificación.
Organización, roles y responsabilidades.
Interesados.
Procedimientos.
Interfaces con otros procesos de Gestión de Servicios.
5.4.8. Conceptos Genéricos y Definiciones

Cambio: La adición, modificación o eliminación aprobada y soportada o inclusive el retorno a
la Línea de Referencia de cualquier CI.
Solicitud de Cambio (RFC): Forma o pantalla usada para registrar los detalles de una
solicitud de cambio (RFC) de cualquier CI o de cualquier procedimiento asociado con la
infraestructura.
CAB: El Comité de Asesor de Cambio lo preside siempre el Gestor De Cambios. Puede haber
consultores externos, representantes de los usuarios y de los proveedores de TI, así como
los Gestores de otros los Procesos.
ECAB: Comité de Asesoramiento de Cambios de Emergencia. ECAB Autoriza los cambios que
tengan que ser instalados más rápidos que los normales.
Programa Adelantado de Cambios (FSC – Forward Schedule of Change): Programa que
contiene los detalles de todos los Cambios aprobados para implementar así como las fechas
de implementación propuestas por el Gestor de Entrega.
Revisión Post-implementación (PIR): Revisiones que se realizan después de un cambio para
saber inicialmente, si el cambio ha sido implementado con éxito y posteriormente si se han
obtenidos los beneficios esperados
5.4.9. Las 7 Rs de la Gestión de Cambios

Las preguntas siguientes se deben contestar para todos los cambios. Sin esta información, el
impacto no puede ser determinado y el equilibrio entre riesgo y la ventaja de mantener el
servicio vivo no será entendido.
Esto podría dar lugar a cambios que no se entregan con toda las posibles ventajas del Negocio o
que tiene un efecto perjudicial o inesperado sobre el servicio activo:
Quién PRESENTA el Cambio? (Reclamación)
¿Cuál es la RAZÓN del Cambio? (Razón)
¿Cuál es el RETORNO requerido del Cambio? (Resultado)
¿Cuál es el RIESGO que implica el Cambio? (Riesgo)
¿Qué RECURSOS se requieren para entregar el Cambio? (Recursos)
¿Quién es el RESPONSABLE de probar e implementar el cambio? (Responsabilidad)
¿Cuál es la RELACIÓN entre este cambio y otros? (Relación)

5.4.10. Tipos de Cambio

Estándar (1): - Normal. El Gerente de Cambio lo PRE-AUTORIZÓ previamente según el
procedimiento escrito en el que se asegura que los riesgos son mínimos. Si se basan en
plantillas de rutina no es necesaria la autorización.
Categoría (2) – Menor: Poco impacto en servicios actuales. El Gerente de Cambios es
convocado a autorizar el RFC. No es necesario el CAB.
Categoría (3) – Sustancial: Claro impacto en los servicios. El RFC debe ser discutido en el
Comité de Asesoramiento de Cambio (CAB). El Gerente de Cambios solicita el
asesoramiento sobre autorización y programación a Gestión de Entrega.
Categoría (4) – Grave: Impacto significativo en los servicios y al Negocio. Se necesita
personal y /o recursos considerables. La Dirección está involucrada en el proceso de
decisión. Se convoca al CAB
5.4.11. Prioridades en los Cambios

Inmediato (0) (corregir manual)
Cambio Urgente y necesario ahora, de otra forma el impacto en el Negocio es severo,
incluso producir lesiones a los usuarios. Puede venir priorizado por el Gestor de
Problemas.
Desencadena un proceso llamado Cambio de Emergencia.
Aprobación por el Comité de Asesoramiento de Cambios de Emergencia (ECAB)
Alta o grave (1)
Cambio requerido cuanto antes (potencialmente dañino). Está asociado a errores
conocidos y afecta a muchos usuarios.
El CAB debe evaluar el cambio en la próxima reunión.
Media o normal (2)
El Cambio resolverá errores recurrentes o funcionalidad que hace falta (se puede
programar)
.Baja (3)
El Cambio suele ser conveniente junto a otros (que no son contractualmente necesarios)
como ciertos paquetes de software.
5.4.12. Cambio de Emergencia

Los cambios realizados mediante procedimientos de emergencia son resultado de una
planificación deficiente pero a veces es inevitable.
Cualquier interrupción del servicio de alto impacto, ya sea por los usuarios afectados o
porque se ven involucrados sistemas o servicios críticos para el Negocio, debe encontrar
una respuesta inmediata.
Es frecuente que la solución al problema requiera un cambio y que éste haya de
realizarse siguiendo un procedimiento de urgencia.
El procedimiento en estos casos debe estar previsto. Se deben establecer protocolos de
validación de los cambios urgentes que requieran:
La reunión urgente del ECAB si esto fuera posible.
Una decisión del Gestor del Cambio si es imposible demorar la resolución del problema o
éste sucede durante un fin de semana o periodo vacacional.
Como el objetivo en estos casos es restaurar el servicio, es frecuente que los procesos
asociados sigan un orden inverso al usual; tanto los registros en la CMDB como su
documentación se realicen a posteriori.

Es esencial que al cierre del cambio de emergencia se disponga de la misma información

como un cambio normal.
Si esto no fuera así se provocarán situaciones de cambios futuros incompatibles,
configuraciones registradas incorrectas, etc. que serían fuente de nuevas incidencias y
problemas.
Los Cambios de emergencia son Cambios normales.
Los Cambios de emergencia implican riesgos mayores.
Los Cambios de emergencia implican que tiene que haber un procedimiento estándar.
Los Cambios de emergencia no tienen que comprometer la gestión habitual o los
controles del proceso.
Es OBLIGATORIA la aprobación previa del Cambio.
ECAB Autoriza los Cambios que tengan que ser instalados más rápidos que los normales y
cuando no haya tiempo para convocar al CAB
Gestión de
Gestión la Cartera
del Catálogo Gestión de
la Continuidad
Gestión de la Gestión de
Disponibilidad Gestión de la
Cambios Capacidad
Gestión Financiera
de TI Gestión
de Incidencias
Gestión de
Problemas Gestión de
Gestión de
Entregas y Gestión de Suministradores
Despliegues Configuración y
Activos
5.4.14. Diagrama de Rummler – Brache (Calles de piscina)
Evaluar y
Revisar RFC Iniciar RFC
Valorar
el Cambio
Construir Autorizar el Cambio

Denegación
Planificar
Probar actualizaciones
Gestion de
Entrega
Coordinar la Soporte Post Implemanción
Implementación y cerrar el registro de cambio
de cambios
Backout
Retroceso

5.4.15. Relación de Gestión de Cambios con la CMDB y CMS
Gestión de Cambios
Planteamiento Cambio Aprobado o Implementación Revisión

y registro de Rechazado Cierre del
de y coordinación del Cambio
solicitud el Cambio Cambio
Activo del Cambio
de Cambio
Entrega y
Despliegue
de nuevos y
Cambiados CI’s
Gestión de Configuración - CMDB

Identificación Captura de la
Auditoria Verificación
Informes CI’s Actualización Entrega y
CI’s de registros
Auditoria afectados de registros Entorno de
Línea base actualizados
Sistema de Gestión de Configuración (CMS)
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.
El CMS también podría identificar activos/CI asociados que se verán afectados por el cambio, pero
que no están incluidos en la solicitud original, o Cl/activos similares que se beneficiarían de un
cambio similar.
5.4.16. Gestión de Programas / Proyectos
MONITORIZACIÓN DEL CAMBIO
Gestión del Gestión de programas

Cambio y Proyectos
Registro Autorización Monitorización

Y Aprobación e Evaluación Desarrollo Pruebas Implementación
Y planificación
Implementación
Clasificación

5.4.17. Interacción de Gestión de Cambios con Configuración,

Capacidad y Entregas
Gestión Gestión de
Gestión del Cambio
del Cambio Versiones y
Evalúa el Impacto Autoriza el Despliegues
Cambio
Gestiona la
difusión de nuevas
versiones de
software o
Gestión de la Gestión de la Gestión de la hardware si es
Capacidad Configuración Configuración necesario para la
Evalúa el Impacto implementación de
sobre el negocio y Identifica Actualiza un Cambio
el funcionamiento áreas
de TI Registros
impactadas
5.4.18. Modelo de Autorización de Cambios
Todos los cambios requieren una autorización formal de una Autoridad de Cambios,
puede ser una persona o un grupo. Dependerá del tipo de cambio.

5.4.19. El Comité de Asesoramientos de Cambios CAB
PRESIDENTE Gestión de Gestión de

Gerente del Cambio Seguridad Nivel de Servicio
Gestión de la
Gestión de
Disponibilidad
la Continuidad
Gestión Financiera Gestión de la
CAB
Capacidad
Gestión de Difusión Gestión de la

(Release) Demanda
Gestión
Gestión del Problema del Incidente
Representante Representantes
Proveedores Senior del Negocio De los trabajadores
Abogados . . .
Su membresía no está limitada y está delimitada.
5.4.20. Actividades del CAB

Debatir los riesgos posibles e importantes sobre el negocio durante un cambio.
Generar el soporte para el cambio.
Evaluación y aprobación del cambio.
Sus miembros convocados se tienen que involucrar en la toma de decisiones para
recomendar sobre:
Autorización.
Determinación del impacto
Determinación de la prioridad
Determinación de la asignación de recursos
5.4.21. Agenda del CAB

Cambios fallidos, cambios deshechos mediante un back-out, o cambios aplicados sin
la referencia de otros procesos.
RFCs muy importantes para evaluarlos el CAB.
RFCs muy importantes que hayan sido evaluados por el CAB.
Revisión de cambios.
Autorización.
Revisiones de los procesos de Gestión de Cambios.
Determinación de la prioridad
Logros del procesos de Gestión de Cambios

5.4.22. Disparadores del proceso de Gestión de Cambios

Cambios estratégicos
Cambios que afecten a uno o más servicios.
Cambios operativos
Cambios para la Mejora Continua del Servicio.
Cambio legal y/o regulatorio
El cambio organizativo
Cambios de Políticas y de las normas
Cambio después de analizar negocios, clientes y patrones de actividad de los
usuarios
La adición de un nuevo servicio para un espacio de mercado o un nuevo LOS
Las actualizaciones de la Cartera de Servicios, cartera de clientes o cartera de
contratos con el cliente
Cambio del modelo de aprovisionamiento
Cambios debidos a la innovación tecnológica
5.4.23. Entradas
Políticas y estrategias de cambios y entrega
RFCs
Programación Adelantada de Cambios (FSC)
Paradas de Servicio Planificadas (PSO)
Activos y elementos de configuración.
Las políticas y la estrategia para cambios y entregas
Planes, cambios, transición, entregas, prueba, evaluaciones y remediación
Cambio de horario actual y la interrupción del servicio proyectada (PSO)
Los informes de evaluación intermedios y los definitivos
Activos circulantes o elementos de configuración, por ejemplo, línea de referencia
(BL), Paquete de Servicio (SP), Paquete de Entrega
Resultados de las pruebas, informes de pruebas e informes de evaluación
5.4.24. Salidas
RFC aprobadas o rechazadas.
Servicios, CIs y activos nuevos o modificados.
PSO ajustadas.
Programación de Cambios actualizada.
Decisiones, acciones, documentos, registros e informes de cambios.
Cambio en los servicios o infraestructura desde RFCs aprobadas
Activos o CIs nuevos, modificados o eliminados
Planificación de cambios
Interrupción del Servicio proyectada (PSO) o revisada
Planes de cambios autorizados
Documentos y registros de cambios

5.4.25. Métricas – KPIs

Número de cambios implementados cumpliendo las especificaciones del cliente y
del Negocio.
Beneficios de cambios comparándolos con costes.
Reducción del número de interrupciones del servicio.
Reducción del número de cambios no autorizados.
Reducción del número de Back out.
Reducción del número de cambios no planificados.
Tasa de éxitos de cambios después de la evaluación con respecto a cambios
solicitados.
Número de análisis de impacto incorrectos.
Número de especificaciones incorrectas de cambios.
Número de interrupciones a causa de los cambios.
Número de incidentes a causa de los cambios.
Número de problemas a causa de los cambios.
Comparación de costes contra presupuesto.
5.4.26. Factores Críticos de Éxito.
Programar los Cambios usando:

Tablas, hojas y herramientas de planificación (FSC)
La estrategia de entregas definidas en la SLAs.
Usar herramientas para:
Monitorizar las acciones.
Tener una visión clara y global de los cambios pendientes.
Tener una percepción de:
Disponibilidad de recursos humanos.
Disponibilidad de recursos económicos.
Coste de los cambios.
Mandar la Lista Adelantada de Cambios (FSC) a:
Centro de Servicio al usuario y Gestores de Servicios.
Clientes vía Gestión de Nivel de Servicios.
Usuarios vía Centro de servicio al Usuario.
Desarrolladores y personal de soporte (Help Desk).
A proveedores implicados.

5.4.27. Riesgos
La falta de compromiso con Gestión de Cambios por la empresa, y la falta de
patrocinio empresarial, así como del personal de TI
La aplicación de cambios sin consultar a Gestión de Cambios
La evaluación del cambio se reduce a hacerlo “ya”, sin tener en cuenta los riesgos,
costes y beneficios
La falta de tiempo que permita una evaluación adecuada de los cambios por la
presión de los proyectos o de la empresa
El poco tiempo permitido en una ventana de cambios
La falta de recursos para la evaluación, planificación y ejecución de cambios
requeridos por el negocio
La falta de claridad sobre cómo la Gestión de Cambios debe interactuar con otros
procesos de Gestión de Servicios, con la Gestión de Proyectos o actividades del
Diseño de Servicios
Excesiva burocracia en los procesos de Gestión de Cambios
5.4.28. Desafíos
El mayor desafío para la Gestión del Cambio es asegurarse de que cada cambio se
registra y se controla
La comunicación regular, el alcance y el valor de la Gestión del Cambio ayudará a
asegurar que el personal de TI comprende el alcance y el valor de la Gestión del
Cambio y no eluden el proceso
Una manera muy importante para ayudar a manejar este desafío es asegurarse de
que hay apoyo activo y visible para la Gestión del Cambio de los ejecutivos y altos
directivos
5.4.29. Beneficios
Más eficiencia en la productividad de los clientes y sus usuarios así como el personal
de soporte TI.
Menos interrupciones en los procesos de negocio.
Más capacidad para absorber un mayor número de cambios con menos errores.
Menos backouts que hay que hacer junto a la mejora de la capacidad de las
regresiones.
Más ajustada evaluación de costes y riesgos de los cambios propuestos antes de
implementarlos.
Mejora de la información de gestión a la gerencia.
5.4.30. Costes y posibles Problemas

Costes de Herramientas: Al introducir muchos procesos hay que integrar la Gestión
de Incidentes, la de Configuración y la de Cambios con herramientas de terceros.
Cuando se manejan ámbitos de TI complejos, es imposible controlar procesos
administrativos sin tales herramientas.
No está clara la propiedad del proceso.
Resistencia al paraguas de autoridad de Gestión de Cambios.
Intentos de cambio sin seguir los procesos habituales.
Procedimientos de cambio muy burocráticos.
Falta de compromiso de la Gerencia.
Contratistas reacios a alinearse con el proceso.

Contramedidas:
Control de todos los CIs conviniendo a Gestión de la Configuración.
Incorporar contratos con condiciones específicas para proveedores externos.
5.4.31. Construcción, pruebas e implementación de los Cambios

Los RFCs autorizados se enviarán a los equipos técnicos implicados.
Los RFCs podrían requerir:
Construir un módulo nuevo de producción
Adquirir nuevos equipos o contratar servicios externos.
Modificación de hardware.
Desarrollar una nueva versión de software.
Crear o modificar documentación de hardware y software.
Preparar modificaciones de formación de usuarios.
Tener una visión clara y global de los cambios pendientes.
Gestión de Cambios tiene la responsabilidad de la coordinar y supervisar los cambios
para garantizar que se asignen los recursos necesarios y que se desarrollan las
actividades de acuerdo a la FSC.
Los procedimientos de backouts deben de estar preparados, probados,
documentados y autorizados y antes de la implementación de los cambios.
Probar siempre los cambios antes de su implementación
5.4.32. Actividades del Rol del Gestor del Cambio

Después de considerar el consenso del CAB y del ECAB autorizar los cambios.
Distribuir el FSC vía Centro de Servicio al usuario.
Relacionarse con todas las partes interesadas para coordinar la construcción,
pruebas e implementación del cambio.
Actualizar los registros del cambio en la CMDB.
Revisar todos los cambios implementados.
Revisar todos los RFCs pendientes de estudio.
Identificar tendencias o problemas posibles que puedan surgir mediante el análisis
de los registros.
Cerrar los RFCs.
Generar los informes regulares a la gerencia.
Recibir, registrar y asignar prioridades las RFCs.
Rechazar RFCs que sean impracticable.
Crear la agenda del CAB para que previamente sus miembros hagan su análisis y
catalogar los RFCs
Convocar a los miembros delimitados del CAB que sean expertos en los RFCs a tratar
y a qué reuniones.
Convocar al ECAB para las RFCs urgentes y presidir siempre el CAB y el ECAB.

5.4.33. Actividades del rol del Comité de Asesoramiento de Cambios

Revisar los RFCs presentados con anterioridad a la reunión.
Proporcionar detalles de sus posibles impactos, los recursos necesarios para su
implementación y sus costes.
Asistir a todas las reuniones pertinentes del CAB y si es necesario al ECAB.
Participar en la programación de todos los cambios.
Estar localizable todos los miembros del ECAB para ser consultado ante una
emergencia.
Asesorar al Gestor de Cambios en todos los aspectos de cambios urgentes
propuestos.
5.4.34. Informes de Gestión
Del proceso de Gestión de Cambios:

Nº Implementados
Nº Planificados
Nº Rechazados
Nº Evaluados
Nº Horas por recursos humanos consumidas
Del cambio en sí:
Nº Regresiones
Nº CIs implicados
Nº Problemas resueltos
Nº Quejas
Nº Horas por recursos humanos consumidas
5.4.35. Mejores Prácticas

Designar y dar autoridad al Gestor del Cambio.
Decidir sobre el sistema de Gestión de Cambios.
Tomar la decisión sobre herramientas, documentación en carpeta compartida o
híbrido.
Revisión de las interrelaciones de Gestión de Cambios con la Gestión de la Capacidad
y Gestión de la Configuración.
Plan de implementación
Diseñar e integrar la concordancia con Gestión de Entregas y Despliegues y Gestión
de la Configuración y Activos del Servicio.
Aparte del entorno de operaciones incluir los entornos de sistemas e
infraestructuras de desarrollo.
Separar la gestión del proceso con la Dirección del Proceso.
Asignar la propiedad del proceso independientemente de la jerarquización de los
departamentos de la Organización.
Planificarse para cambios urgentes en vez de crear cambios de emergencia


5.5. Gestión de Entregas y Despliegues

Se ocupa de construir, probar y suministrar capacidades para proporcionar los servicios
especificados en el Diseño del Servicio, cumpliendo los requisitos de los grupos de interés
y proporcionando los objetivos planteados.
5.5.1. Objetivos
Establecer claramente los planes comprensivos del lanzamiento y del despliegue de servicios,
software y/o de hardware especificados en el Diseño del Servicio que permitan a los proyectos de
cambios del cliente y del Negocio alinear sus actividades con los planes de TI de manera eficiente.
Garantizar que un Paquete de Entrega (PR) pueda construirse, instalarse, probarse y
desplegarse eficiente y satisfactoriamente en un grupo de despliegue o entorno
objetivo, pero de forma planificada y desplegado eficientemente a un ambiente de
producción con éxito y a tiempo
Que un nuevo o cambiado servicio y sus sistemas, tecnología y organización sean
capaces de entregar los requisitos convenidos del servicio (utilidades, garantías y
porcentajes de disponibilidad)
Asegurar de que haya transferencia del conocimiento para permitir a los clientes y a
los usuarios optimizar el uso del servicio soportar sus actividades económicas.
Asegurar de que las habilidades y el conocimiento estén transferidos a Operaciones
del Servicio y al personal de soporte para permitir entregar, apoyar y mantener con
eficiencia el servicio según garantías y porcentajes de disponibilidad requeridos en la
SLA.
Reducir al mínimo el impacto imprevisto en los servicios de producción, las
operaciones y la organización
Satisfacer a los clientes, usuarios y personal de la Gestión de Servicios de TI con las
prácticas de la Transición del Servicio y la documentación y la formación de usuario
Garantizar que existen planes de la entrega y del despliegue claros y exhaustivos
que permitan, a los proyectos de cambio del negocio y del cliente, alinear sus
actividades con estos planes

El método de implementación es más coherente y hay más trazabilidad para la
auditoría, normas gubernamentales y leyes del país.
Entregando el cambio de forma rápida, a un coste aceptable y con el mínimo riesgo
Garantizando que los clientes y usuarios puedan utilizar el servicio, nuevo o
modificado, de forma que dé soporte a los objetivos de negocio
Mejorando la consistencia en el método de implementar a través del cambio del
negocio, equipos del servicio, suministradores y clientes
Contribuyendo al cumplimiento de requisitos que se puedan auditar para obtener la
trazabilidad a través de Transición del Servicio

5.5.3. Conceptos Genéricos y Definiciones

ENTREGA es un conjunto de Elementos de Configuración (CIs), nuevos o modificados
que son probados e implantados conjuntamente en un entorno de producción.
Un PAQUETE de ENTREGA es una sola unidad o una colección de unidades de
ENTREGA.
Una UNIDAD DE ENTREGA es una porción del servicio o infraestructura que está
incluida en la entrega, de acuerdo a las directrices de la organización.
Las Unidades de Entrega se definen dentro de un Paquete de Entrega
SOPORTE POST IMPLANTACIÓN provee recursos para resolver asuntos operativos y
de soporte durante las Entregas y Despliegues
5.5.4. Big Bang vs. Fases
Opción de Big-Bang – El nuevo o cambiado servicio se despliega a todas las áreas de la organización
y a todos los usuarios en una sola operación, cuando la consistencia del servicio a través de la
organización se considera importante
Fase de acercamiento – El servicio se despliega a una parte básica de usuarios inicialmente y
entonces esta operación se repite para las partes subsecuentes de usuarios vía un programa
adelantado de cambios
Push and Pull: Para desplegar vía acercamiento del Push, los datos sobre todas las
localizaciones del usuario deben estar disponibles.
Los acercamientos del Pull no se basan tan pesadamente sobre datos de configuración
exactos y pueden accionarse una actualización a los equipos de usuarios.
Puesto algunos usuarios nunca quieren el Pull, un lanzamiento puede ser apropiado
dentro de un límite de tiempo especificado y si se excede este tiempo habrá que lanzar
un Push. P.ej: Para una actualización del antivirus.
Push: Se utiliza un acercamiento del Push donde el componente de servicio se
despliega desde una localización centralizada y se lanza a las localidades objetivo.
En términos de despliegue del servicio, la entrega de componentes de servicio
actualizados a todos los usuarios constituye el Push, puesto que el nuevo o
cambiado servicio se entrega en el ambiente de usuarios a la vez y no a elección de
usuarios.
Pull: Un acercamiento del Pull se utiliza para las revisiones de programas donde el
software está disponible en una localización central; pero los usuarios son libres de
tirar y actualizar su software a su propia localización a la vez de elegir la hora o al
reinicio de su equipo.
El uso del Pull en cuanto a actualizaciones vía Internet ha hecho este concepto muy
popular. Un buen ejemplo son las actualizaciones de antivirus, que se descargan
típicamente a los PCs y a los servidores dando mejor juego a los clientes, no
obstante en tiempos de riesgo extremo de virus esto se puede cambiar por un
lanzamiento Push a todos los usuarios conocidos.

5.5.5. Automático vs. Manual
Sea por la automatización u otros medios, los mecanismos de lanzar y de desplegar los componentes
de servicio perfectamente configurados se deben establecer correctamente en la fase de diseño del
lanzamiento y probados en etapas de construcción y de prueba por terceros del nuevo o cambiado
servicio.
La automatización ayudará a asegurar la capacidad de repetición y de consistencia. El
tiempo requerido para proporcionar un mecanismo automatizado bien diseñado y
eficiente puede siempre no ser disponible o viable.
Si se utiliza un mecanismo manual es importante supervisar y medir el impacto si son
muchas las actividades manuales repetitivas pues es muy probable que sean
ineficientes, inefectivas y con errores. Demasiadas actividades manuales retrasarán el
lanzamiento del equipo de técnicos encargados del mismo y crearán problemas de
recursos y de capacidad que afectarán a los porcentajes de disponibilidad.
5.5.6. Prueba de las Entregas & Paquetes de Entrega
Este gráfico Ilustra el despliegue de paquetes desde el nivel más alto
La versión V1.0 es operacional y

Entorno de Desarrollo su master está en la DSL.
RFC Autorización para el desarrollo.
La V1.1a esta basada en la V1.0
V 1.1 a-d
X
COPIA
V 1.0
Autoriza?
aún no es confiable. Se
encuentra en Desarrollo
La V1.0 es operacional y su
Entorno de Desarrollo master está en la DSL.
y Pruebas Construir La V1.1d aún no es confiable y se
y encuentra en pruebas.
V 1.1 d probar el
Entrega V 1.1 La V1.0 es operacional y su
Software master está en la DSL.
La V1.1 se libera y distribuye
primero a la DSL para test de
Prueba de la
Entorno de Pruebas construcción
construcción de la versión.
de la versión La V.1.0 es operativa y su master
está en la DSL
Distribución (actualización programada)
¿Se libera
Entorno de Producción la versión? La V1.1 resultó confiable en la
DSL (BETA 2)
Se autoriza la liberación de la
Implementar versión.
Distribución
La V1.1 es operativa y su master
está en la DSL.
La V.1.0 es archivada en la DSL
Archivar
5.5.7. Actividades
I. Planificación.
II. Preparación de la construcción, pruebas y despliegues.
III. Construcción y pruebas.
IV. Pruebas y pilotos de servicios.
V. Planificación y preparación de despliegues.
VI. Transferencia, despliegues y retiro.
VII. Verificación del despliegue.
VIII. Soporte post-Implantación.
IX. Revisión y cierre.

El primer paso dentro de las actividades es la planificación pero debemos conocer antes el
Modelo en V
5.5.8. El Modelo en V de los Servicios

El Modelo en V es útil para identificar los niveles en los que debe efectuarse la construcción y
pruebas de las versiones.
Se asocia tradicionalmente con el Ciclo de Vida en cascada, pero es de hecho aplicable a los
ciclos de vida de todos los demás, incluidos los ciclos de vida iterativos como prototipos.
Lado Izquierdo: La especificación de los requisitos de servicio hasta el diseño detallado del
servicio.
Lado Derecho: Se concentra en la validación de las actividades que se realizan contra las
definidas en el lado izquierdo.
Cada etapa de la izquierda, es la participación directa de la parte equivalente de la derecha.
Dentro de cada ciclo de desarrollo iterativo, el Modelo en V establece requisitos de aceptación
contra las que las necesidades y el diseño pueden solicitar, en la que cada iteración del diseño
que se están considerando justifique la entrega al cliente para prueba y evaluación.
En el Centro están los criterios de prueba y validación
Definir Plan/Criterio de Revisión del Servicio Validar Paquetes

Requerimientos de Servicios,
Cliente / negocio ofertas y contratos
Nivel 1 Paquetes de Servicios, Contratos, SLP
1A 1B
Definir Plan/Criterio de Aceptación del Servicio Pruebas de
Requerimientos de
Servicios Aceptados
Servicios
Nivel 2
2A SLR y pilotos SLA 2B
Diseñar Pruebas de
Soluciones de Plan/Criterio Operación del Servicio
Predisposición
Servicios Operativas del Servicio
Nivel 3
3A 3B
Plan/Criterio prueba de versiones de Servicio
Diseñar Entrega Prueba de Paquete de
del Servicio Entrega del Servicio
Nivel 4
4A 4B
Desarrollo Solución SAC Pruebas del
de Servicio Componente del
Conjunto
Nivel 5 5A 5B
Componentes
Nivel de Construidos y
configuración probados
Entregables de
y pruebas suministradores
internos y externos
Suministradores
Línea de internos y externos
Referencia

5.5.9. Acrónimos usados en el gráfico del MODELO EN V

Paquete de Nivel de Servicio (SLP): (Estrategia del Servicio) define un nivel de Utilidad y
Garantía de un Paquete de Servicio (SP). Cada SLP está diseñado para satisfacer las
necesidades de un determinado Patrón de Actividad de Negocio (PBA)
Paquete de Diseño de Servicio (SDP): (Diseño de Servicio) Documento (s) de todos los
aspectos de un Servicio TI y sus requisitos a través de cada etapa de su Ciclo de Vida. Un
Paquete de Diseño de Servicios se produce para cada uno de los nuevos servicios de TI,
cambios importantes o de Servicios Retirados.
Interfaz de Proveedor de Servicios (SPI): (Estrategia del Servicio) Interfaz entre el
Proveedor de Servicios de TI y un usuario, cliente, proceso de Negocio o de un
Suministrador. El análisis de las interfaces de Proveedor de Servicios le ayuda a coordinar
de extremo a extremo la Gestión de Servicios de TI.
Requisito de Nivel de Servicio (SLR): (Diseño de Servicio y Mejora Continua del Servicio)
Requerimiento de un cliente para un aspecto de un Servicio de TI. Las SRL se basan en los
objetivos de la empresa y se utilizan para negociar acuerdos sobre los objetivos de Nivel
de Servicio.
(Los colores del Modelo en V del gráfico no guardan relación con los colores de las Fases del Ciclo
de Vida de los Servicios)
5.5.10. Detalles de las Actividades

I. Planificación
Los planes deben de incluir:
Alcance, contenido, riesgo, responsabilidades y partes interesadas en la versión.
Responsable del equipo para la entrega.
Método de colaboración con todas las partes interesadas.
Criterios de pasa/falla
Planes de construcción y pruebas.
Planificación de pilotos
Planificación de paquetes de entrega (compilación) y construcción.
Gestión de Cambios y comunicación con los interesados
Formación de personal transferencia del conocimiento y evaluación de la preparación
de los usuarios finales.
Uso de recursos de Gestión de Servicios.
Transferencia de sistemas y usuarios al nuevo servicio.
Planificación del despliegue teniendo en cuenta
¿Qué es lo que se va a desplegar?
¿Quiénes son los usuarios?
¿Cuál es la situación local?
¿Dónde están los usuarios?
¿Quién más ha de ser notificado?
¿Por qué se realiza el despliegue?
¿Cuáles son los Factores Críticos de Éxito?

Planificación logística y de la distribución teniendo en cuenta

Cuando y como se van a distribuir los componentes del servicio
Qué se debe hacer si se producen retrasos
Gestionar las costumbres de las distribuciones internas
Planificación financiera y comercial
Antes que se produzca el despliegue hay que revisar los aspectos financieros y comerciales.
II. Preparación de construcción (compilación), pruebas y despliegue
Antes de aprobar el paso a la construcción y pruebas, el diseño de la versión y servicio se
compara con los requerimientos. Si se detectan riesgos o problemas éstos se han de priorizar y
se emprenden las acciones oportunas para resolverlos. Los resultados de la validación se
documentan en el informe del Proceso de Evaluación del Servicio.
III. Construcción y pruebas
Gestión de infraestructura y servicios generales
La infraestructura y los servicios comunes hay que gestionarlos con cuidado pues tienen vital
importancia para la construcción y pruebas.
Uso y documentación de versiones y construcción
Deben de haberse diseñado plantillas, procedimientos y manuales que formarán parte de la
documentación y en este contexto es importante la comprobación de licencias de los distintos
componentes.
Adquisición, compra y pruebas de componentes para la versión
Las actividades de compra tienen que incluir:
Registro y actualización de todos los CIs en el CMS.
Comprobación de presentación de Licencias cuando sea requerido.
Comprobación de calidad y legalidad de los componentes.
Requisitos de etiquetado y su nomenclatura.
Compilación de la versión (empaquetado de la versión)
Ensamblaje e integración de los componentes
Preparación de la documentación de compilación y entrega
Instalación y revisión del paquete de entrega
Definición de una referencia para la composición del paquete
Estructura y control de los entornos de prueba
Los entornos de prueba tienen que ser estables y fáciles de controlar.
IV. Pruebas y pilotos del servicio
La gestión de pruebas coordina las actividades de planificación y control de la implementación.
Lo veremos con más detalle en “Validación y Pruebas del servicio”
Prueba de entrega del servicio
Comprueba que los componentes del servicio funcionan correctamente y que la versión se
puede compilar, instalar y probar en el entorno de destino.
Prueba de preparación para la Operación del Servicio
Garantiza que la infraestructura, servicio y aplicaciones funcionan correctamente y se puede
transferir al entorno de producción.
Pilotos
Permite comprobar si hay elementos del servicio que no cumplen los requerimientos o pueden
ser un riesgo para el negocio.

V. Planificación y preparación del despliegue

Se requiere atender a los aspectos de:
¿Están preparados para la implementación del paquete de entrega?
¿Han preparado el plan de actividades?
¿Se han identificado los riesgos potenciales?
¿Todo el personal ha recibido la formación necesaria’
¿Se ha introducido a última hora algún cambio en las especificaciones?
VI. Transferencia, despliegue y retirada
Durante el despliegue se requieren las siguientes actividades
Transferencia de activos financieros: Transferencia de costes de soporte,
mantenimiento, licencias y reservas de facilidades a terceras partes
Transferencia y transición del negocio y la organización: Al transferir un servicio a una
unidad de servicio habrá que adaptar la propia organización (roles, autoridades,
responsabilidades, etc.)
Publicación de documentación: Hay que distribuir la documentación del nuevo o
modificado servicio al personal involucrado.
Transferencia de “capacidades de Gestión del Servicio”: Transferir sistemas,
herramientas e información del proceso al equipo que va a ser responsable.
Transferencia del servicio:
Análisis de rendimiento en el servicio, riesgos y problemas
Configuración de auditoría de activos del servicio
Actualización del Catálogo de Servicios
Distribución de notificaciones de servicio
Despliegue del servicio: Todas las actividades necesarias para distribuir e instalar el
servicio.
Cancelación de servicios: Se cancelan los servicios redundantes
Retirada de activos redundantes: Se retiran los activos no necesarios para el servicio
nuevo o cambiante.
VII. Verificación del despliegue
Una vez ejecutadas todas las actividades de despliegue, verificar que los usuarios, clientes y los
interesados pueden utilizar los servicios como estaba previsto.
VIII. Soporte post-Implantación - Early Life Support (ELS)
El propósito de Soporte Post-Implantación es ofrecer un soporte adicional después del
despliegue de un nuevo servicio o modificado. Permite resolver problemas operativos y de
soporte con la mayor rapidez posible, lo que se traduce en que los usuarios no sufran
interrupciones del servicio. Permite detectar “problemas de crecimiento” y mejorar la
estabilización del servicio.
Ayuda a cumplir los criterios de salida como.
Todos los usuarios pueden utilizar el servicio de manera efectiva y eficiente.
Los propietarios de los procesos y los servicios pueden gestionar el servicio.
Se han alcanzado los niveles acordados de servicio y rendimiento.

IX. Revisión y cierre

Comprobar que:
La formación y transferencia del conocimiento son adecuados.
Se han documentado las experiencias de todos los usuarios.
Se han realizado todos los arreglos y cambios y se han documentado los problemas y
KEs y workarounds.
Se han alcanzado los niveles de calidad
Se cumplen las SACs
El servicio está preparado para transicionarlo desde ELS a producción.
El despliegue finaliza cuando el soporte se transfiere a Operaciones de Servicio.
Gestión de Cambios lleva a cabo el PIR.
5.5.11. Relaciones entre Gestión de Cambios y Gestión de Entregas
Gestión de la Entrega Gestión del Cambio

Verificar RFC Software
Nuevo
Software Autorizar por el
Proveedores NO
¿OK? CAB
SI NUEVO Desarrollo
Construcción
Registro Pruebas
COPIA
COPIA Autorizada
DML
la prueba
Construir Producción
Entrega
Autorizada Prueba a
Plan de la entrega producción
implantación
Autorizada la
implementación Implementación
Distribución
5.5.12. Entradas
RFCs aprobados.
Paquetes del Servicio.
SLP, SDP, SAC.
Planes de Continuidad.
Políticas, diseño y modelado de versiones.
Modelos de construcción.
Ciclo de vida del Proyecto
Entregables
Políticas de Entrega
Visión global de las necesidades del negocio
Restricciones y dependencias

5.5.13. Salidas
Planes de versiones y despliegues.
RFCs completados.
Notificaciones de servicio.
Catálogo de Servicios actualizado.
Modelo de servicios actualizado
Criterios de Aceptación del Servicio (SAC)
Informes de servicio y su documentación.
Entornos y capacidades de servicio probadas.
SLA, OLA y Contratos.
Plan de Capacidad del servicio
Informe completo de la Transición del Servicio.
Lista completa y concisa de todos los CIs usados con su trazabilidad para auditoría.
Lista de la configuración del servicio e infraestructuras.
5.5.14. Diseño, Construcción y Configuración
5.5.14.1. Entradas:
Definición de la entrega
Planes de la entrega
5.5.14.2. Salidas:
Instrucciones detalladas de construcción y ensamblaje de la entrega
Órdenes de compra, licencias y garantías de hardware y software distribuidos por
terceros
“Scripts” de instalación automática y planes de pruebas
Copias originales de los medios y las instrucciones de instalación a la DSL
Procedimientos de regresión
5.5.15. Aceptación de la Entrega
5.5.15.1. Entradas:
Un entorno de pruebas controlado
Definición y planes de la entrega
Planes de pruebas
Criterios de aceptación
Copias de los medios de instalación
Instrucciones de instalación
Planes de pruebas para los “scripts” de instalación
Procedimientos de regresión documentados

5.5.15.2. Salidas:
Procedimientos de instalación y de regresión probados
Componentes de la entrega probados
Se conocen los defectos que van a pasar al entorno de producción
Resultados de las pruebas
Documentación de soporte
Instrucciones de operación y administración
Planes de contingencia y regresión
Plan de formación
Autorización para implementar la entrega
5.5.16. Planificación del paso a Producción
5.5.16.1. Ampliar los planes de entrega con:

Detalles de instalación exactos.
Programa de eventos detallado y exacto.
Plan de recursos (Quien hará las cosas).
Detalle de los CIs que se vayan a retirar con detalles del método para ubicar
equipos o SW redundante.
Plan de acción para emplazamientos descentralizados.
Plan de comunicación.
Planes de compras.
Notificaciones e informes a los usuarios finales de la entrega.
Procedimientos para el almacenamiento del SW y HW y su seguimiento.
Programa de reuniones para el personal de Dirección y los grupos implicados en la
entrega.

5.5.17. Cuadro de Difusiones
Responsabilidad Desarrollo Entorno de prueba controladas Entorno de Actualizar

de la entrega producción
Tipo de objeto Desplegado Aceptado por Autoridad Aceptado y Registro de

desde para entrega respaldado por control
a producción
Paquete Responsable de Responsable Gerente de Responsable CMDB

adquirido desarrollo de pruebas Cambios operaciones
Módulos Responsable de Responsable Gerente de Responsable CMDB

personalizados desarrollo de pruebas Cambios operaciones
Cambios físicos Responsable de Admin BBDD Gerente de Admin BBDD CMDB-BBDD

de la BBDD desarrollo Cambios Script en la DSL
Servidor Gerencia de Responsable Gerente de Responsable CMDB

Servidores de Servidores Cambios Servidores
Herramienta de Responsable Responsable Gerente de Responsable de CMDB

trabajo (nueva desarrollo de de pruebas Cambios soportes PCs DSL
aplicación) Herramientas de
trabajo
PC de Logística Soporte a PCs Responsable Responsable de CMDB

sobremesa de soporte a soporte a PCs DSL
PCs
Based On Cabinet Office ITIL® Material. Reproduced Under License From The Cabinet
Office
5.5.18. Métricas
Claves de Rendimiento relacionados con el cliente
Mejora del rendimiento del servicio.
Reducción del número de incidentes y problemas.
Aumento de satisfacción del cliente y de los usuarios.
Claves de Rendimiento relacionados con el suministrador:
Costes más bajos para diagnosticar incidencias y problemas.
Reducción del número de discrepancias en las auditoría con respecto a CIs de terceros.

El nuevo o modificado servicio se ejecuta en el entorno final y se compara con respecto
al Diseño del Servicio.
El servicio nuevo o modificado se ha probado en un piloto.
Los modelos de prueba se pueden reutilizar para backout de futuras entregas.


Desarrollo de mediciones de rendimiento.
Métodos de estandarización para proyectos y suministradores.
Dependencia de proyectos externos y de suministradores claves.
Comprender los riesgos que conlleva la Transición del Servicio.
Comprender los puntos de vista y los puntos de partida de todos los interesados.
Desarrollar medidas y métodos de medición estándares del rendimiento a través de
proyectos y suministradores
Contactar con proyectos y suministradores si las fechas estimadas fueran imprecisas y
se produjeran retrasos en las actividades de Transición del Servicio
Entender a los interesados, los cuales apoyan una Gestión del Riesgo eficiente para las
actividades de prueba y evaluación del impacto del cambio
Lograr que haya un entendimiento profundo de los riesgos que, han impactado o
podrían impactar en el éxito de una Transición del Servicio
5.5.21. Riesgos
Falta de claridad en las expectativas y objetivos de los interesados.
Mala definición de roles, responsabilidades y tareas.
Gestión sin empatía
Pocos recursos financieros.
Falta de control.
Mala Gestión de Cambios.
Relaciones deficientes con los Partners y SPs.
Alcance mal definido en las etapas anteriores del Ciclo de Vida de los Servicios
El uso de personal que no se dedica al lanzamiento y a las actividades de
implementación
No usar el proceso de Gestión de Entregas y Despliegues y de ITSM para gestionar el
retiro de los servicios
5.5.22. Roles en la Gestión de Entregas
A. Gestor de Entregas y Despliegues
Responsable de manejar todos los aspectos del proceso de extremo a extremo del lanzamiento. El
Gestor del lanzamiento y del despliegue informará al Gestor de la Transición del Servicio como el
Gestor de Prueba de Servicio; no obstante estos papeles se deben emprender siempre por la
personas separada, es decir nunca combinado, para asegurarse de que hay siempre una prueba
independiente y su verificación de la prueba.
El Gestor del lanzamiento y del despliegue es responsable así mismo del planeamiento, diseño,
estructura, configuración y prueba de todo el software y hardware para crear el paquete del
lanzamiento para la entrega, o cambio del servicio
Se encarga de implementar y focaliza en la calidad de todo el software y hardware
instalado. El Gestor de Cambios focaliza en los riesgos.
Asegura que toda la información de hardware y software está actualizada en la CMDB y
en la DML. Se focaliza en el software.
Protege el entorno de Producción y de sus Servicios a través de procedimientos
formales y aprobados.
Tiene una visión general de cambios en los servicios de TI, asegurando que todos los
aspectos técnicos y no técnicos sean tenidos en cuenta.
Colabora estrechamente con Gestión de Cambios y Gestión de Configuración.
Establece la política de implementación de nuevas versiones.
Lógicas y Físicas
5.5.22.1. Lógicas:
Manejo de todos los aspectos del proceso de extremo a extremo del lanzamiento
Puesta al día del SKMS y del SACM
Asegurar la coordinación de la estructura, el equipo del entorno de prueba y d
equipo del lanzamiento
Proporcionar informes a la gerencia de los progresos del lanzamiento
5.5.22.2. Físicas:
Mantener el lanzamiento y política y planeamiento del despliegue
Lanzar el diseño, la estructura y la configuración de paquetes
Lanzar la aceptación del paquete incluyendo la aprobación por el Negocio
Mantener el planeamiento del desarrollo incluyendo el método de despliegue
Lanzar la prueba del paquete a los criterios de aceptación predefinidos (SAC)
Aprobar el paquete del lanzamiento para la puesta en práctica
Comunicar, preparar y entrenamiento
Intervenciones del soporte físico y del software antes y después de la puesta en
práctica de los cambios del paquete
Instalación del hardware nuevo o actualizado
Capacidad de almacenaje y de la rastreabilidad de la intervención del software
controlado en sistemas centralizados y distribuidos
Lanzar, distribuir e instalar el software empaquetado
B. Gestor de la Construcción y Lanzamiento de Paquetes
La gestión del empaquetado y de la estructura del lanzamiento es el flujo de trabajo

(establece los requisitos, diseño, construcción, prueba, despliegue, funcionamiento y
optimización) para entregar las aplicaciones y la infraestructura que cumplan los requisitos
de Diseño del Servicio.

Establecer la configuración del lanzamiento final (p.ej. conocimiento, información,
soporte físico, software e infraestructura)
Construir la entrega del lanzamiento final
Probar la entrega final antes de la prueba independiente
Establecer y divulgar los errores y soluciones conocidos y los excepcionales
Proporcionar la entrada al proceso de aprobación de la puesta en práctica final

C. Gestor de Despliegues
Responsabilizarse de la entrega física final de la puesta en práctica del
servicio
Coordinar la documentación y las comunicaciones del lanzamiento, incluyendo el
entrenamiento en TI y en el cliente y las notas técnicas del lanzamiento
Planear el despliegue coordinándose con el Gestor del Cambio y actualizando la
SKMS y SACM
Proporcionar la dirección y las ayudas técnicas a través del proceso del
lanzamiento, incluyendo errores y soluciones alternativas conocidas
Proporcionar la regeneración en la eficiencia del lanzamiento
Registrar las métricas para que el despliegue asegure lo convenido en la SLA
5.5.23. Definitiva Media Library (DML)
Biblioteca Definitiva de Medios
Es la biblioteca segura donde se almacenan y protegen las versiones definitivas y autorizadas de

todos los elementos de configuración de medios y/o CIs de software.
Almacena las copias maestras de las versiones que han pasado los controles de garantía de calidad y
puede consistir en una o más librerías de software / archivo de las zonas de almacenamiento,
independiente de desarrollo, prueba y/o de producción
Las copias maestras de la documentación para el control de un sistema también se almacenan en la

DML en forma electrónica.
5.5.24. Relaciones entre la DML y la CMDB-CMS
CI físicos
CMDB
Información
Sobre los CI
DML
CI Electrónicos
Registro de
Entregas
Construcción
de nuevas
Entregas
Desplegando nuevas
Entregas en producción
Probando
nuevas
Entregas

Gestión de la
Configuración
CMS
Gestión de
Cambios
Gestión de
Entregas y
Despliegues
Validación
Planeamiento y
y Pruebas del
Soporte de la
Servicio
Transición


5.6. Gestión de los Interesados (Interesados Management)

La Gestión de los Interesados (Interesados) es un Critical Success Factors en la Transición
del Servicio y se desarrolla en Diseño del Servicio y debería de responder:
¿Quiénes son los Interesados?
¿Cuáles son sus intereses?
¿En qué tienen ellos influencia?
¿Cómo y en que han sido ellos incluidos en el Proyecto o Programa?
¿Qué información comparten entre ellos?
Estrategia de Cambios Relación con Posición ante

INTERESADOS FINANCIERO Seguridad
La Dirección Operacionales Clientes la competencia
Asociados del
Negocio ● ● ● ●
Equipos del
Proyecto ●
Clientes ● ● ●
Medios de
Prensa ●
Sindicatos ●
Dirección ● ●
Cuerpos
Reguladores ● ●
Para Transición del Servicio será útil que se elabore un listado de interesados bajo
categorías como por ejemplo 'usuarios/beneficiarios' o 'proveedores'. A continuación cada
categoría podría descomponerse con mayor detalle si fuera necesario.
Las categorías deben ser grupos reconocibles en lugar de grupos abstractos; por ejemplo,
los 'empleados situados en una ubicación geográfica' formarían un grupo rápidamente
identificable, mientras que no lo sería el grupo 'miembros del público que respaldan los
derechos humanos'.
Algunas categorías podrían identificar a los mismos individuos, pero con frecuencia es útil
diferenciar entre interesados 'con roles diferentes',

Alta
Gobierno
Dirección
Suministra-
Áreas de
dores
(servicios) Negocio
Socios de Personal
negocio Operaciones
Gestión de los
Interesados
Prensa y
Sindicatos
medios
Equipos de
Clientes Programas y
proyectos
Suminis-
tradores Auditoría Interesados
(productos)
Para Transición del Servicio será útil que se elabore un listado de interesados bajo
categorías como por ejemplo 'usuarios/beneficiarios' o 'proveedores'. A continuación cada
categoría podría descomponerse con mayor detalle si fuera necesario. Las categorías deben
ser grupos reconocibles en lugar de grupos abstractos; por ejemplo, los 'empleados situados
en una ubicación geográfica' formarían un grupo rápidamente identificable, mientras que no
lo sería el grupo 'miembros del público que respaldan los derechos humanos'. Algunas
categorías podrían identificar a los mismos individuos, pero con frecuencia es útil diferenciar
entre interesados 'con roles diferentes',
Key players Not No Helps it Makes it

Committed resistance happen happen
Departing director X O
of customer
Chair of board of
O X
service provider
New director of OX
service provider
Customer O X
Your managers O X
Your staff O X
Service Strategy OX
team
Suppliers O X
Services Operations O X
Los interesados tienen inevitablemente diferentes áreas de interés en el cambio global; por
ejemplo, algunos estarán preocupados por cómo afectará el cambio a su entorno de
trabajo; otros desearán influir en los cambios con respecto a la forma en la que se gestionan
los clientes.
Una matriz de interesados como la que se muestra en esta diapositiva representa una forma
útil para hacer corresponder los diferentes interesados con sus intereses en la Transición del
Servicio, sus actividades y resultados. Transición del Servicio debe trabajar con Diseño del
Servicio para garantizar que exista una correspondencia precisa y relevante de interesados o
equivalente.

5.7. Service Asset & Configuration Management (SACM)

Gestión de la Configuración y Activos del Servicio
Todas las Organizaciones necesitan controlar todos los componentes que soportan un servicio para
asegurar la calidad, eficiencia y economía de la operación.
Este proceso provee un modelo lógico de la infraestructura y servicios.
Identifica, controla, mantiene y verifica las versiones de los componentes.
No se puede gestionar lo que NO se conoce
5.7.1. Objetivos
Define y controla los componentes de los servicios y la infraestructura y mantiene la actualización
en la configuración de los registros tanto de TI interno como de suministradores. El MODELO tiene
que ser único para toda la Organización
Esto permite a una organización:
Cumplir con los requisitos de gobierno corporativo
Control de su base de activos
Optimizar sus costos
Gestionar el Cambio y la Entrega de manera efectiva
Resolver los incidentes y los problemas con mayor rapidez.
5.7.2. Ámbito
Todos los activos durante el Ciclo de Vida del Servicio están incluidos en el ámbito de la Gestión de
Activos.
SACM afecta también a otros activos ajenos a TI como los productos operativos que se utilizan en el
desarrollo de los servicios, o elementos de configuración requeridos para el soporte y que no son
clasificados como activos.
Incluye también los activos y CIs de otros suministradores si son relevantes para el servicio.

Mejor provisión y planificación de cambios
Cambios y entregas que se valorarán satisfactoriamente por el cliente.
Incidencias y problemas resueltos dentro de los objetivos del SLA.
Capacidad para medir los costes asociados a un servicio
Mejor adhesión a estándares y leyes gubernativas.
5.7.4. Definiciones y Conceptos Genéricos
5.7.4.1. CMDB:
CMDB que es una Base de Datos de los elementos de configuración (CIs) del Proveedor de Servicios
de TI interno, clientes y Proveedores externos.
5.7.4.2. CMS: 4 capas

Presentación: Vistas diferentes para distintos grupos.
Procesamiento de conocimientos: Genera informes y consultas.
Integración de la Información: Ordena y estructura los datos.
Datos: Datos de distintas fuentes como CMDBs, y otras BBDD.
A nivel de DATOS, el CMS recibirá información de distintas CMDBs lo que formarán la CMDB
Federada.

PORTAL Vista Vista Vista Vista

Vista Vista
Cambio y Configuración Gestión de Centro de
Capa de Gestión de Configuración
Técnica Servicio al
Entrega Ciclo de vida Calidad
Presentación Activos Usuario
Capa de FAQ Gestión de Rendimiento

Report Modelado Tablero de Alertas
Proceso del Análisis Pronóstico, Planeamiento Monitorización
Conocimiento
Negocio/Clientes/usuarios – Servicios – Aplicaciones – Mapeo de la Infraestructura

Gestión
Portafolio de Servicio Gestión
Modelo de CMDB de Cambio
Catálogo de Servicio de Entrega
Servicios Integrada
Capa de
Integración de Procesos comunes
Datos e
Mapa del Gestión Reconciliación Sincronización Extracción
Transformación Explotación
Esquema de MetaDatos de Datos de Datos
la información información Carga
INTEGRACIÓN DE D AT O S
Biblioteca Gestión de Herramientas de auditoria y
Archivo Definitiva
Documentación Configuración administración de activos
de medios
del Proyecto de Software
1 Librería Herramientas de Configuración de
Definitivade Plataformas, Bases de Datos,
Estructurado CMDBs FISICAS
documentos
Fuentes y Almacenamiento, Escritorios, Mainframe
Software 2 Librería
herramientas del Proyecto Definitivade
CMDB1 CMDB2 Gestión de Aplicaciones corporativas,
de Información documentos
accesos, Recursos Humanos, de Cadenas
y de los Datos de suministradores, Relaciones con
clientes
5.7.5. Actividades
Planificación y dirección.
Identificación de la configuración.
Proporcionar información precisa de los Elementos de Configuración (CI), sus relaciones y
sus configuraciones en sí, así como su documentación, su estado actual y su historia para
soportar todos los demás procesos de Gestión de Servicios.
Interactuar con la Gestión de Incidente, Gestión de Problemas, Gestión de Cambios y
Gestión de Entrega (Release) para encontrar rápidamente la causa de los problemas.
Coordinarse con el Departamento de Compras y Suministros.
Contabilizar, monitorizar y mantener actualizada la información de todos los bienes y
configuraciones de TI dentro de la organización que son necesarios para la entrega de
servicios.
Gestión (control) de la configuración.
Para gestionar infraestructuras de gran tamaño SACM necesita un mejor sistema de soporte
como CMS (Configuration Management System)
Verificar y auditar los registros de configuración contra la infraestructura y corregir cualquier
discrepancia en la CMDB y CMS.
Es responsable de registrar las relaciones entre los componentes del servicio

5.7.6. Políticas
Desarrollar y mantener políticas de SACM para establecer los objetivos, alcance, principios y
Factores Críticos de Éxito.
Primero hay que tomar decisiones estratégicas que prioricen las necesidades de información y
control, ya que va a suponer esfuerzo en tiempo, recursos y costes.
Los puntos de partida pueden ser:
5.7.7. CIs en la CMDB
5.7.7.1. El Modelo Lógico y Único

La Gestión de Configuración entrega un modelo lógico requerido por los servicios, los activos y la
infraestructura registrando las relaciones entre los elementos de configuración
El poder del modelo lógico es que es EL MODELO. Una sola representación común usada por
todas las partes de la Gestión de Servicios de TI, y más allá.
Información en la SACM
5.7.7.2. Categorías de CIs

Una cierta documentación definirá las características de un CI mientras que la otra documentación
será un CI por derecho propio que necesita ser controlado. Habrá una variedad de CIs; por ejemplo:
Ciclo de Vida del Servicio (CI Service): Proporciona un cuadro de los servicios del Proveedor de
Servicios, cómo estos servicios serán entregados, qué ventajas se esperan, con qué coste y cuando
serán monitorizados, los planes de gestión del servicio, los planes del ciclo vital de servicio, los del
paquete del Diseño del Servicio, del cambio y del lanzamiento, y los planes de prueba
CIs como Servicios con sus descripciones tal como:
Activos de la capacidad de servicio: Gestión, organización, procesos, conocimiento,
gente
Mantenimiento de los activos de recursos: Del capital, los sistemas, los usos,
información, los datos, infraestructura, capital financiero, gente
Mantenimiento del modelo
Paquete de servicio
Lanzamiento del paquete
Mantenimiento de los Criterios de Aceptación (SAC)
Los CIs deben de estar interrelacionados de forma que accediendo a la información de un elemento
de configuración podamos saber con qué otros CIs está relacionado y por lo tanto que impacto
puede tener en otro componente, servicio o negocio.
Tanto el negocio, como sus servicios, como todos los CIs que componen el TODO deben de poder ser
identificados por sus atributos.
Fácilmente una organización de tamaño medio puede invertir de 6 a 8 meses en poblar su CMDB
federada y luego su CMS.

5.7.8. Interrelaciones de CIs por sus atributos

Las interrelaciones describen como se combinan los CIs para proporcionar un servicio
Gobierno Gobernado por

Conectado a
Instalado en
Plataforma Contiene
Servidor
Corre sobre
Dispositivo de Red Plataforma Database Software Documentos
Nombre:
Stack Servidor DBMS Servicios Aplicaciones del Documentos
Negocio Técnicos
Nombre: Nombre: Runs Nombre: Nombre: Nombre:
Backs up Corre sobre
Backed up por
Dispositivo de
Plataforma Software Software
Dispositivo de Sistema
Servidor Operativo Service Pack
Datacenter a Corre
Nombre: Nombre: Nombre:
Conectado a sobre
El proceso SACM es responsable de registrar las

relaciones entre los componentes del servicio
En la etapa del Diseño del Servicio habrá que diseñar con detalle cuales serían los pasos para
planificar con éxito el Sistema de la Configuración y Activos del Servicio como proceso esencial en el
Ciclo de Vida de los Servicios de TI.
La Estrategia, alcance, detalles y políticas.
Selección, designación, propietario, relaciones, cronogramas.
La organización tanto técnica como directiva para la CMDB.
Las políticas de procesos relacionados como Gestión de Cambios y Gestión de la Entregas y
Despliegues.
Puntos de relaciones con proyectos, proveedores, aplicaciones, grupos de soporte, etc.
Las directrices, procesos, procedimientos, roles y responsabilidades relevantes.
Las herramientas de soporte idóneas para su integración en la CMDB.
Donde ubicar la DML y documentación para asegurarla caso de un desastre o no
disponibilidad a largo plazo.
Gestión interna sobre archivo de CIs, licencias y tiempos máximos de almacenamiento.
Líneas de Referencia, rollouts importantes, hitos, cargas de trabajo, planes de recursos para
los siguientes periodos.

n
co
o na el .
ci 8 ..
.
or e . .
la p
re A2 de do b d
Se PC nte iza We .
el l ..
ne
i
ut io o ..
po E s vic n ad a . d e
m r o m a
co se ci ble pi
la co
un re Pro a
Es tá l un
A Es on e Es n
S L C co
n n n a ..
u
a ,a
u io te .
ac
o na nto rel iden
ci ie Se l inc
la
re edim E
Se roc
p
Se pueden relacionar los CI de múltiples y diversos métodos. Cada organización tiene que diseñar
antes, el tipo de relación que mejor interese al negocio.
5.7.9. Estado de un CI
Estado de un CI
5.7.10. Alcance y Detalles de los CIs
SERVICIO
ALCANCE
Tecnología Documentación Clase
SLA’s-UC’s
HW SW Red SLR’s
Procesos
Sistema
Operativo
Programas BD
Un CI
Sistema Sistema • Es necesario para dar un servicio
Servidor Cliente • Su identificación es única
• Cambiado el . . .
• Se puede gestionar
DETALLES • Tiene categoría
• Tiene atributos
• Tiene relaciones
• Tiene un estado
• Tiene un PROPIETARIO

5.7.11. Ejemplos de Atributos en la CMDB
Atributo Descripción
Nombre de CI El único nombre por el que se conocerá este tipo de CI
Número de Copia o de El número que identifica de forma única las instancias particulares de este
Serie CI, por ejemplo, el número de copia de software, para hardware el número
de serie
Categoría Clasificación de un CI (p.ej. hardware, software, documentación, etc.)
Tipo Descripción del tipo de CI, ampliando la información de “categoría” (p.ej.
configuración de hardware, paquete de software, aparato de hardware o
capítulo de programa).
Número de modelo Modelo de CI (correspondiente por ejemplo al número de modelo de
proveedor (hardware) p.ej. Dell model xxx, PC/aa model yyy).
Fecha vencimiento de Fecha en la que vence la garantía del proveedor
Garantía
Número de Versión El número de versión del CI.
Localidad La localidad del CI, p.ej. la biblioteca o medio donde reside el software del
CI, el sitio/cuarto donde se encuentra un servicio.
Propietario El nombre y/o designación del propietario responsable del CI
Responsable
Fecha de Fecha en la que el propietario arriba mencionado se hizo responsable del
Responsabilidad CI
Fuente / Proveedor La fuente del CI, p.ej. desarrollado en la misma casa, importada de la
empresa xxxx etc.
Licencia Número de licencia o referencia al acuerdo de licencia
Fecha de Provisión Fecha cuando el CI fue dado a la organización.
Fecha de Aceptación/ Fecha en la que el CI fue aceptado por la organización como probado de
modo satisfactorio.
Estado (Actual) El estado actual del CI; p.ej. bajo “prueba”, “vivo”, “archivado”.
Estado (programado) El próximo estado programado del CI (con la fecha o indicación del evento
que provocará el cambio de estado).
Comentario Un campo de comentario a ser utilizado para narrativa textual; por
ejemplo, para proporcionar una descripción de cómo esta versión del CI es
distinta de la versión anterior.

5.7.12. Actividades
5.7.12.1. Dirección y Planificación.

Debe contener lo siguiente.
Contexto y objetivo
Alcance
Requisitos
Políticas y estándares aplicables
Sistemas y herramientas de SACM
5.7.12.2. Identificación de la configuración

Determinar y mantener los nombres y números de versión de activos, CIs, las relaciones
mutuas y los atributos correspondientes.
Definir y documentar criterios para seleccionar los CIs y sus componentes dentro de
ellos.
Seleccionar los CIs a partir de los criterios definidos anteriormente.
Asignar números de identificación exclusivos a cada CI.
Especificar los atributos de cada CI.
Definir cuando un CI se debe registrar en la CMDB o CMS.
Identificar a cada propietario de cada CI.
A partir de cada CI se puede granular hacia abajo en otros subniveles.

5.7.13. Control de configuración

Con el control de la configuración se garantiza que todos los CIs se gestionan de forma autorizada.
Ningún CI se puede agregar, eliminar, modificar o sustituir sin los procedimientos autorizados, por lo
que hay que definir directrices y procedimientos para.
Gestión de licencias.
Gestión de cambios.
Gestión de versiones.
Control de accesos.
Control de construcciones.
Promoción.
Despliegue
Instalación.
Gestión de integridad de Líneas de Referencia
5.7.13.1. Seguimiento y reporte del estado de la

configuración
Lista de CIs y sus referencias.
Detalles del estado actual y cambios anteriores.
Lista de CIs no autorizados.
Informes sobre hardware y software no autorizado.
5.7.14. Verificación y auditoria

SACM tiene que realizar auditorías para verificar que:
No hay discrepancias entre las Líneas de Referencias documentadas y las reales de los
entornos de negocio.
Los CIs existen físicamente en la os almacenes o en la DML y se puede comprobar que los
registros en el CMS se corresponden a la infraestructura física
Que existen documentos de las versiones y de su configuración antes del despliegue de la
versión.
Hay que documentar las excepciones encontradas en la auditoría y las acciones correctivas
corresponderán al propietario de Gestión de Cambios.
Las auditorías se realizarían cuando:
Después de cambios relativamente importantes en el CMS.
Antes y después de cambios en los servicios de la infraestructura de TI.
A intervalos planificados y aleatorios.
Antes de una entrega para garantizarnos el back out
En respuesta a la detección de cambios NO autorizados.
Después de la recuperación ante un desastre.
5.7.15. Métricas
Mayor calidad y precisión de la información sobre activos y CIs.
Menos errores por información obsoleta.
Menor duración de las auditorías por mejor acceso a la información.
Tiempos de diagnóstico y resolución más cortos para incidencias y problemas.
Menor discrepancia entre la información en el CMS y en el entorno real.


Convencer al personal que no se puede ignorar el proceso de SACM.
Colección excesiva de atributos solo por el hecho de estar disponibles.
Falta de compromiso por la alta gerencia e Interesados.
Persuadir al personal de soporte técnico para que adopten una política de verificación de
entrada/salida. A veces se puede percibir como una barrera para un servicio rápido y
responsable
Si los aspectos positivos de sistema no se dieran a conocer adecuadamente, entonces el
personal podría inclinarse por intentar evitarlo
Atraer y justificar financiación para el SACM, ya que normalmente no es visible para las
unidades del cliente
Una actitud de “sólo recopilar datos porque es posible hacerlo” conduce al SACM a una
sobrecarga de datos que supondría ser caro de mantener

Determinar el nivel correcto de detalles y profundidad de los atributos.
Implementar el correcto enfoque vertical para alinearlo a la estructura de TI.
Conseguir el nivel correcto de precisión.
Utilizar la correcta tecnología para automatizar el CMS y de acuerdo a las directrices de
SACM.
5.7.18. Riesgos
Dar más importancia a los aspectos técnicos sobre los servicios y las operaciones.
Pérdida de vigencia del CMS por traslados de activos por personal no autorizado.
La tentación de considerar un enfoque técnico, en lugar de al servicio y al negocio, pero el
conocimiento técnico es esencial para su entrega exitosa
La degradación de la exactitud de la información de la configuración a través del tiempo, que
puede causar errores y ser difícil y costoso de corregir
Establecer el alcance demasiado amplio, provocando exceso de coste y esfuerzo para el
beneficio esperado
Establecer el alcance demasiado estrecho, por lo que el proceso tiene muy pocos beneficios
El CMS se convierte en obsoleto debido al movimiento de los activos de hardware por parte
del personal no autorizado
Auditorías físicas regulares deben ser llevadas a cabo con las discrepancias
Los gerentes deben ser informados de las inconsistencias en sus área

Gestión de la Arquitectura
Continuidad de Red
Gestión de
Ingeniería Incidencias
de Hardware
Gestión de
Gestión de la
Gestión de la Problemas
Configuración
Disponibilidad
Gestión de
Gestión Cambios
Financiera de TI
Gestión de
Gestión de Nivel
Entregas de Servicio
5.7.20. Roles
I. Gestor de Activos del Servicio

Alinea los objetivos generales de acuerdo con el Gestor de Servicios de TI; IMPLEMENTA
las políticas y estándares de la Organización que incluirían:
Sistemas de Gestión de Activos
Evalúa la existencia y el diseño de activos. Maneja los nuevos/mejorados sistemas
para la eficiencia y la efectividad, incluyendo el cálculo y la planificación del trabajo y
de los recursos implicados, y la supervisión y la información sobre el progreso contra
el plan previsto
Planes y procesos de gestión de activos, normas y procedimientos
Acuerda el ámbito, la función, los artículos que se controlarán, y la información que
debe ser registrada
Dotación y Formación de Personal
Conocimiento – Sensibilización del personal para ganar su apoyo para los nuevos
procedimientos, asegurándose que los cambios a los métodos y a los procesos están
aprobados y comunicados correctamente para proveer el personal idóneo antes de
ser ejecutados (Planes de la puesta en práctica de los nuevos sistemas de la gestión
de activos)
Herramientas de Gestión de Activos
Evalúa las herramientas propietarias y de recomendación de los que cumplen mejor
el presupuesto, el recurso, el calendario y los requisitos técnicos
Maneja el plan de la gestión de activos, los principios y los procesos y su puesta en
práctica

Propone y/o conviene interfaces con funciones de Gestión de Cambios, del

Problema, de la administración de la red, de la Gestión de Entrega, de las
operaciones de computadoras, de la logística, de las finanzas y de la administración
contable
Planea la población de la DB de activos. Maneja la DB de activos, las bibliotecas
centrales y las herramientas, asegurando economía interna regular
Proporciona informes, incluyendo los informes a la Gerencia (que indican la acción
sugerida para ocuparse de los actuales activos o de defectos previstos), los informes
del análisis de impacto y los informes del activo
Asiste a interventores para revisar las actividades del equipo de la gestión de activos
para la conformidad con procedimientos puestos-abajo, asegurándose
Convenciones de nombres únicos para cada CI
Convenir los activos (CIs) que se identificarán únicamente con convenciones de
nombres, asegura conformidad con los estándares de la identificación para los tipos
de objeto, los entornos, los procesos, los ciclos de vida, la documentación, las
versiones, los formatos, las Líneas de Referencias, los lanzamientos y las plantillas
II. Analista de la Configuración

Propone el alcance de los procesos de Gestión de Configuración y Activos, de las
funciones, de los CIs que deben ser controlados, y de la información que debe ser
registrada. Desarrolla los estándares de la Gestión de Configuración y Activos, los
planes y los procedimientos.
Forma a los especialistas de la Gestión de Configuración y Activos de los planes,
procesos y procedimientos
Apoya la creación de los planes la Gestión de Configuración y Activos y de los planes
y puesta en práctica
Crea los procesos y los procedimientos de Gestión de Configuración y Activos. Esto
incluye procedimientos de registros del CIs; controles de acceso y privilegios. Se
asegura de que los roles y las responsabilidades correctas estén definidas en los
planes de Gestión de Configuración y Activos
Comunica con el administrador/bibliotecario de la Gestión de Configuración y
Activos en la forma de poblar los activos en el CMS. Maneja el CMS, las bibliotecas
centrales, los códigos comunes y los
Utiliza o proporciona los activos y el CMS para facilitar el menor impacto para RFCs y
para asegurarse de que los cambios ejecutados están según lo autorizado. Crea los
expedientes de cambios, Líneas de Referencias de la configuración, y el lanzamiento
de paquetes. Se asegura que cualquier cambio en los expedientes de autorización de
cambios estén ellos mismos conforme a los procedimientos de Gestión de Cambios.
Se asegura que los activos y el CMS estén actualizados cuando se ejecuta un cambio
Utiliza los activos y el CMS para ayudar a identificar a otros CIs afectados
Realiza auditorías de la Gestión de Configuración y Activos para comprobar que el
inventario de TI es consistente con los activos en el CMS e inicia cualquier acción
correctiva si es necesaria
Crea y puebla las bibliotecas del proyecto y el sistema de Gestión de Configuración y
Activos. Chequea los elementos de CIs con las herramientas de Gestión de
Configuración y Activos
Líneas de Referencia: Acepta productos de línea de base a partir de terceros y
distribuye productos. Configura y guarda Líneas de Referencias para la promoción y
lanzamiento
Mantiene la información de estado de proyectos y los registros de estadísticas y los
informes del estado
Monitoriza los problemas (pruebas de incidentes) y mantiene la base de datos para

los informes generales y de Métricas (KPIs)
III. Administrador de la Configuración o de la biblioteca

El administrador/ Bibliotecario de la Gestión de Configuración y Activos es el
guardián de todas las copias principales del software, de todos los elementos de
software (CIs) y de la documentación registrada que se refiera a los activos y a la
Gestión de Configuración y Activos. Las tareas principales de este rol son:
Para controlar la recepción, recibo, identificación, almacenaje y el retiro de todos los
CIs
Para proporcionar la información de los estados de CIs
Para numerar, registrar, almacenar y distribuir los activo y ediciones de Gestión de
Configuración y Activos
IV. CMS / Administrador de Herramientas

Comunica con el analista y el administrador/el bibliotecario de la Gestión de
Configuración y Activos para la población de activos y del CMS. Proporciona la
administración y ayuda técnicas para los activo y CMS, las bibliotecas centrales, los
códigos comunes de las herramientas y los datos.
Emprende la economía doméstica técnica regular de los activos y del CMS
Asegura la integridad y el funcionamiento operacional de los sistemas de CMS.
V. Configuration Control Board

El Tablero de Control de la Configuración requiere asegurarse de que la intención y
las políticas de la Gestión de Configuración y Activos del Servicio estén empleadas a
través del Ciclo Vital de la Gestión del Servicio y con la consideración específica para
cada aspecto del servicio completo.
El Tablero Marcador tendrá las responsabilidades siguientes:
Definir la Línea de Referencia de los servicios en términos de usos, información,
servicio técnico, infraestructura y servicios de soporte, asegurándose que cumplen
los requisitos establecidos en el Diseño del Servicio
Revisar los cambios en la configuración del servicio para el cumplimiento de
requisitos contractuales e internos
Crear los requisitos de los cambios para que configuración del servicio se conforme
con peticiones del cambio del contrato.

5.8. Procesos de Evaluación del Cambio

La Evaluación es un proceso genérico con el que se considera si algo tiene un
rendimiento aceptable, si su relación valor-precio es adecuada o si se utilizará, aceptará o
se pagará por ello.
5.8.1. Objetivos
Establecer las expectativas de los interesados correctamente y proporcionar información
efectiva y precisa al proceso de Gestión del Cambio para asegurarse de que los cambios no
afecten negativamente a la capacidad del servicio y no introducir riesgos, y que sean
transferidos sin control
Evaluar los efectos esperados de un cambio que afecten a un servicio, y detectar la mayor
cantidad de efectos no deseados tanto como sea razonablemente posibles, dadas las
limitaciones de la capacidad, recursos y organización
Proporcionar salidas de calidad de manera que el proceso de Gestión del Cambio puede
acelerar una decisión efectiva sobre si un cambio de servicio debe ser autorizado o no
5.8.2. Ámbito
En el contexto de Transición del Servicio, la Evaluación tiene que definir el rendimiento de
futuro de un cambio en el servicio.
Cada cambio debe ser autorizado por una autoridad de cambio en varios puntos de su ciclo
de vida, por ejemplo antes de construir y probar, antes de que se registren en la DML y
antes de que se implemente en Operaciones del Servicio
La evaluación es necesaria, antes de cada una de estas autorizaciones, para proporcionar a
la autoridad del cambio el asesoramiento correcto
Este proceso de Evaluación del Cambio describe una evaluación formal, adecuada para su
uso cuando se producen cambios importantes
Cada organización debe decidir qué cambios deben usar este proceso formal de Evaluación
del Cambio, y que puede ser evaluado como parte del proceso de Gestión del Cambio

La evaluación está, por naturaleza, asociada al valor
Específicamente, una evaluación eficaz establecerá el uso de los recursos en términos del
beneficio entregado, y esta información permitirá un enfoque más preciso en el valor, en el
futuro desarrollo del servicio, y en Gestión de Cambios
Existe bastante información, que Mejora Continua del Servicio puede obtener de la
evaluación, para analizar futuras mejoras en el proceso de cambio y las predicciones y
medidas del rendimiento del cambio del servicio
Suministra información para la Mejora Continua del Servicio, así como futuras mejoras en
el desarrollo del servicio y Gestión de Cambios.

5.8.4. Políticas
Los diseños y los cambios de los servicios se evalúan antes de la transición.
El Cliente gestiona las desviaciones entre el rendimiento esperado y el real.
El Cliente participa en la evaluación.
El cliente o su representante gestionará cualquier desviación entre el rendimiento previsto y
el real, aceptando el cambio aun cuando sea diferente al que estaba previsto; o rechazando
el cambio; o requiriendo la implementación de un nuevo cambio, con el acuerdo previo del
rendimiento previsto revisado. No se autoriza por Gestión del Cambio ningún otro resultado
de la evaluación
Una evaluación no se realizará sin el compromiso del cliente
Hasta donde sea razonablemente práctico, será necesario identificar los efectos pretendidos
y no pretendidos de un cambio, entender y considerar sus consecuencias
Un cambio del servicio será evaluado de forma imparcial, abierta, consistente, y si fuera
posible, objetivamente
5.8.5. Actividades
Planificación de la evaluación.
Evaluación del rendimiento previsto.
Evaluación del rendimiento real.
5.8.6. Planificación de la evaluación

Durante la planificación de una evaluación se analizan los efectos previstos y no previstos de
los cambios. Los previstos satisfacen al cliente y los imprevistos permanecen ocultos durante algún
tiempo.
5.8.6.1. Evaluación del rendimiento previsto.

Hay que evaluar el riesgo basado en los requisitos del cliente, el rendimiento esperado y el
modelo de rendimiento. Si el riesgo se supone inaceptable, se envía un informe a Gestión de
Cambios y se queda a la espera de una decisión.
5.8.6.2. Evaluación del rendimiento real.

Implementando el cambio del servicio, es Operaciones de Servicio quien informa del
rendimiento real. Si la evaluación indica que hay un riesgo inaceptable, se envía un nuevo informe
intermedio a Gestión de Cambios y se interrumpen las actividades de cambio a la espera de una
decisión.
Se aprueba la evaluación, se envía a Gestión de Cambios un informe conteniendo el perfil de
riesgo, desviaciones, una declaración de cualificación y validación y si es posible también plasmar
algunas recomendaciones.

Gestión del Diseño del

Cambio Servicio Pruebas
Disparadores Plan de pruebas

RFC SDP Y resultados
Planificar la Entradas
evaluación
Evaluar previsto
Rendimiento
OK Informe de Gestión del

SI Rendimiento evaluación
Cambio
Previsto ? NO provisional
Evaluar
rendimiento real
OK
Informe de Gestión del
SI Rendimiento
Evaluación
Real ? NO provisional Cambio
Informe de
evaluación
Gestión del
Cambio
5.8.7. Entradas
El Paquete de Diseño del Servicio
Criterios para la Aceptación del Servicio.
SDP y SAC
Informe y resultados de las pruebas
Discusión con los Interesados
Cambios propuestos
5.8.8. Salidas
Informes para Validación y Pruebas del Servicio
Informes de Evaluación para Gestión de Cambios

5.8.9. Métricas
Diferencias en el rendimiento del servicio (mínimas y en descenso)
Número de incidencias durante las pruebas (bajo y en descenso)
Número de diseños fallidos (cero)
Tiempo de evaluación de los cambios de servicio (corto y en descenso)

Retrasos en el calendario debido a terceros.
Desarrollo de métodos estándares para medir el rendimiento.
Crear una cultura de gestión de riesgos.
Analizar el riesgo desde diferentes lados y entender el impacto de los riesgos sobre la
Transición del Servicio.
La falta de criterios claros para la Evaluación del Cambio
Expectativas poco realistas del tiempo requerido para la Evaluación del Cambio
Personal del proceso Evaluación del Cambio, con la suficiente experiencia o la autoridad de
la organización, para poder influir en las autoridades el cambio
La mala estimación de las fechas de entrega, por parte del proyecto y suministradores,
causando retrasos en la programación de actividades de Evaluación del Cambio
5.8.11. Desafíos
Desarrollar medidas y métodos de medición estándares del rendimiento a través de
Imprecisión en las fechas estimadas de entrega de proyectos y de suministradores y retrasos
en las actividades de evaluación
Entender las diferentes expectativas de los interesados, que apoyan una Gestión del Riesgo
eficiente para las actividades de evaluación
Entender, y ser capaces de evaluar el equilibrio, entre Gestión del Riesgo y asumirlos, ya que
esto afecta a la estrategia general de la organización y de la entrega del servicio
Asumir un método, pragmático y medido, para el riesgo (M_o_R)
Comunicar la actitud de la organización ante el riesgo, y el método para una Gestión del
Riesgo eficiente, durante la evaluación del riesgo
5.8.12. Riesgos
La falta de criterios claros para la Evaluación del Cambio
Expectativas poco realistas del tiempo requerido para la Evaluación del Cambio
Personal del proceso Evaluación del Cambio, con la suficiente experiencia o la autoridad de
la organización, para poder influir en las autoridades el cambio
La mala estimación de las fechas de entrega, por parte del proyecto y suministradores,
causando retrasos en la programación de actividades de Evaluación del Cambio

Gestión del
Gestión del Cambio Nivel de Servicio
Evaluación
del Cambio Validación y
Pruebas del
Servicio
Relaciones con el Coordinación del
Negocio Diseño


5.9. Proceso de Validación y Pruebas del Servicio

Las pruebas del servicio ayudan de forma muy importante a la calidad de la provisión del mismo.
Garantizan que los servicios nuevos o modificados se “ajustan al propósito y al uso”.
“Ajustado al propósito”. El servicio hace lo que el cliente espera, luego es útil para el negocio.
“Ajustado al uso”. Se refiere a disponibilidad, capacidad, continuidad y seguridad del servicio.
La Meta del proceso de Validación y Prueba del Servicio es entregar un servicio que agregue valor
añadido al negocio del cliente.
La falta de interés en las pruebas produce en algunas organizaciones más incidencias, problemas,
llamadas al Centro de Servicio al Usuario con el consiguiente aumento de costes no previstos.
5.9.1. Ámbito
El Proveedor de Servicios (SP) asume la responsabilidad de la entrega, operación y/o
mantenimiento de los activos del cliente y del servicio en los niveles acordados de utilidad y
garantía
Validación y Pruebas del Servicio se aplica a través del Ciclo de Vida del Servicio para
asegurar la calidad de un servicio y la habilidad, recursos y capacidades del SP a la hora de
entregarlo satisfactoriamente
Para validar y probar un servicio extremo a extremo, serán importantes las interfaces con
suministradores, clientes y socios
Las pruebas se aplican a servicios internos o desarrollados, hardware, software o servicios
basados en el conocimiento, así como pruebas de sus componentes, y examina el
comportamiento de éstos en la unidad de negocio, unidad de servicio o entorno objetivo
Las pruebas dan soporte directamente al proceso de Gestión de Entregas y Despliegues
asegurando que los niveles apropiados de las pruebas se realicen durante las actividades de
entrega, construcción y despliegue
El proceso de “Evaluación del Cambio” utiliza la salida procedente de las pruebas para
proporcionar la información, evaluada independientemente, sobre si el servicio está
entregando el rendimiento adecuado
5.9.2. Objetivos
Brindar la confianza de que un lanzamiento, que va a crear un servicio nuevo o modificado,
ofrece los resultados esperados y el valor para los clientes, dentro de los costes proyectados,
la capacidad y limitaciones
Asegurar la calidad de la entrega, los componentes del servicio, el servicio resultante y la
capacidad de servicio prestado por un despliegue
Validar que un servicio cumple con “el propósito“ que ofrecerá el rendimiento óptimo
Validar que un servicio es "apto para el uso" que ofrecerá la garantía acordada
Asegurar que las necesidades de los clientes e interesados, para el servicio, se han definido
correctamente, y corregir los errores y diferencias al principio, ya que es más barato que la
corrección de errores en el entorno de producción
Planificar e implementar una validación estructurada y proceso de prueba que proporcione
evidencias objetivas de que el servicio soportará los requisitos de los interesados y del
negocio del cliente, incluyendo los niveles de servicio acordados
Identificar, evaluar y abordar los problemas, errores y riesgos a través de Transición del
Servicio
Tiene que garantizar que:

La versión satisface los resultados y las expectativas del cliente dentro de los costes,
capacidad y restricciones previstos...
Los servicios están ajustados al propósito y al uso.
Se definen las especificaciones (requisitos) del cliente y de los Interesados.
Las interrupciones de servicio pueden ser potencialmente fatales para las operaciones de ciertos
negocios de los clientes y los proveedores de Servicio.
Por ello, un servicio mal diseñado y sin las pruebas necesarias en la Transición del Servicio podría
suponer no solo dañar nuestra reputación sino provocar graves daños materiales y humanos como
en hospitales, industria aeroespacial, etc.
El valor clave para el negocio y clientes, procedente de Validación y Pruebas del Servicio, se
encuentra en términos del grado de confianza de que un servicio nuevo o modificado
entregará el valor y los resultados requeridos y en términos de entendimiento de los riesgos
El éxito de las pruebas depende de que todas las partes entiendan que no pueden o deben
ofrecer absoluta garantía, aunque proporcionen un grado medido de confianza
El grado requerido de confianza varía en función de los requisitos de negocio del cliente y de
las presiones de una organización
5.9.4. El Modelo de Servicio
Describe la estructura y la dinámica de un servicio proporcionado por Operación del Servicio.
Durante el diseño, desarrollo y construcción de un servicio nuevo o modificado, los activos del
servicio se prueban con respecto a las especificaciones y los requisitos del diseño.
La estructura consta de:
Servicios Esenciales
Servicios de Soporte
Activos del servicio necesarios
La dinámica se describe por medio de:
Actividades.
Flujo de recursos.
Coordinación e interacciones.
Modelo Configuración
de de Activos
Servicio del Servicio
Actividades, eventos
e interacciones Operación
(Diseño del Servicio) del
Servicio

5.9.4.1. Políticas
Para Validación y Pruebas del Servicio se han de establecer políticas de:
Políticas de calidad del servicio.

Políticas de riesgo.
Políticas de reutilización.
Políticas de Transición del Servicio.
Políticas de versiones.
Políticas de Gestión de Cambios.
Pruebas integrales obligatorias.
Participación en las pruebas de todas las partes interesadas.
5.9.5. Tipos de Pruebas

Pruebas de requisitos del servicio.
Pruebas de Nivel de Servicio.
Pruebas de aseguramiento del servicio.
Pruebas de usabilidad.
Pruebas de contratos y normativas.
Pruebas de Gestión del Servicio.
Pruebas operativas.
Pruebas de regresión.
5.9.6. Actividades
El proceso de Validación y Pruebas del Servicio se realiza durante TODO el Ciclo de Vida de los
Servicios para comprobar la calidad del servicio.
Estas pruebas serán posibles entradas y soporte para la Gestión de Entregas y Despliegues.
Las salidas del proceso de Validación y Pruebas del Servicio pueden ser las entradas para el proceso
de Evaluación del Cambio.
Las actividades del proceso de Validación y Pruebas del Servicio no se realizan en un orden
determinado sino que se pueden hacer en paralelo.
a) Dirección de validación y pruebas.

b) Planificación y diseño de pruebas.
c) Verificación del diseño y el plan de pruebas.
d) Preparación del entorno de pruebas.
e) Evaluación de criterios de salida e informes.
f) Limpieza y cierre.

5.9.7. Dirección de validación y pruebas

Planificación de recursos y de qué es lo que se debe probar en su momento.
Gestión de incidencias, problemas, errores, desviaciones, dificultades y riesgos resultantes
durante la Transición del Servicio.
Recolección de las métricas de las pruebas, análisis e informes.
5.9.8. Planificación y diseño

Recursos sobre red, hardware, personal de TI necesarios, capacidades, habilidades, recursos
financieros.
Recursos requeridos por el negocio y el cliente.
Servicios de soporte.
Programación de hitos, provisión y aceptación.
5.9.9. Verificación del diseño y el plan de pruebas

Los diseños y planes de pruebas se verifican para comprobar que todo está completo
5.9.10. Preparación del entorno de pruebas

Preparar el entorno y generar una Línea de Referencia de configuración del entorno.
5.9.11. Realización de pruebas

Las pruebas se ejecutan manualmente o con herramientas.
La causa de un fallo tiene que documentarse
Las pruebas se tienen que ceñir a los planes de prueba lo máximo posible.
5.9.12. Evaluación de criterios de salida e informes
Los resultados de las pruebas se interpretan en términos de pasa/falla y sus criterios de

salida serían:
El servicio probado satisface los requisitos de calidad del cliente.
El servicio y la infraestructura de TI permitirán al usuario ejecutar las funciones previstas.
Se capturan las Líneas de Referencias en el CMS.
5.9.13. Limpieza y cierre
El entorno de pruebas SIEMPRE tiene que quedar LIMPIO.

RFC autorizado con

valoración de Evaluación
impacto y recursos. del Servicio
Diseño evaluado
(SDP y SAC)
Dirección de validación y pruebas
Planificar Verificar Evaluar

plan y Preparar criterios de Limpieza y
y diseñar entorno de Realizar
diseño de salida e cierre de
pruebas pruebas Pruebas
pruebas informar pruebas
Revisión de Pruebas para garantizar los resultados requeridos
5.9.14. Interfaces
Un correcto mantenimiento de los datos de prueba es fundamental, por lo que hay que
tener en cuenta que:
Los datos de prueba tienen que estar separados de los de producción.
Hay que tener presente las Leyes de Protección de Datos de cada país.
Existan procedimientos de backup y recuperación.
5.9.15. Entradas
Paquete del servicio y el Paquete del Nivel del Servicio (SLP)
Definiciones de interfaces según el SP.
Paquete de Diseño del Servicio
Planes de versiones y despliegues.
Criterios de Aceptación del Servicio (SAC).
RFCs
5.9.16. Salidas
Análisis de los resultados, por ejemplo, comparación de los resultados reales con los
resultados esperados, riesgos identificados durante las actividades de prueba
Informes para el proceso de Evaluación del Cambio
Líneas de Referencia de configuración del entorno de pruebas.
Pruebas realizadas.

Análisis de los resultados.

Registros de incidencias, problemas y errores de las pruebas.
Ideas para CSI
Datos actualizados.
Información y conocimiento para el SKMS
5.9.17.1. Desde la perspectiva del cliente:

Reducción del impacto y errores en producción que sean atribuibles a una nueva
transición del servicio.
Uso más efectivo de los recursos e implicación del cliente.
Una mejor comprensión por parte de todos los interesados relacionados con el
servicio nuevo o modificado.
5.9.17.2. Desde la perspectiva del Proveedor de Servicios.

Reducción del esfuerzo y los costes necesarios para preparar el entorno de pruebas
Reducción de esfuerzo para detectar errores.
Reutilización de datos de prueba.
Reducción de % de incidencias relacionadas con los errores durante las pruebas.
Nº de KEs documentados antes y durante las pruebas.

El mayor problema de algunas organizaciones es que no conceden la verdadera importancia
a las pruebas.
La escasez de recursos financieros es un aumento de riesgo por no probar antes los
servicios.
Imposibilidad de mantener el entorno de pruebas y datos de prueba para que se
correspondan con el entorno de producción
Insuficiencia de personal, habilidades y herramientas de prueba para proporcionar la
cobertura de pruebas adecuada
Desbordamiento de proyectos y reducción de las franjas de tiempo asignadas para las
pruebas, con objeto de alcanzar las fechas de lanzamiento del proyecto a costa de la calidad
Desarrollo de medidas y métodos de medición estándares del rendimiento, a través de

Identificación de dificultades en las primeras fases del Ciclo de Vida.
Incorporación de la calidad en todas las fases del Ciclo de Vida siguiendo el Modelo en V.
Diseño de modelo de pruebas reutilizable y demostración de que todas las configuraciones
han sido construidas siguiendo los requisitos del cliente.

5.9.20. Riesgos
Falta de claridad en expectativas y objetivos.
Falta de comprensión de las pruebas como proceso crítico para la calidad en la provisión de
los servicios.
Falta de entendimiento de los riesgos, lo que implica que las pruebas no se dirigen a
elementos críticos, que es necesario controlar bien, y por lo tanto, probar
La escasez de recursos, como usuarios y personal de soporte, introducen retrasos y tienen
impacto en otras Transiciones del Servicio


5.10.Sistema de Gestión del Conocimiento del Servicio (SKMS)

Conjunto de herramientas y bases de datos que se emplean para gestionar el conocimiento
y la información. El SKMS incluye tanto el Sistema de Gestión de Configuración y Activos del
Servicio, como otras herramientas y bases de datos. El SKMS almacena, gestiona, actualiza y
presenta toda la información que un Proveedor de Servicio de TI necesita para gestionar
todo el Ciclo de Vida de los Servicios de TI.
La Gestión del Conocimiento es especialmente importante durante la Transición del Servicio

pues depende de la información disponible y del conocimiento de los usuarios, del Centro
de Servicio al Usuario, del soporte y del Proveedor del Servicio.
5.10.1. Objetivos
Mejorar la calidad de la toma de decisiones, asegurando que el conocimiento, la información
y los datos están disponibles en todo el Ciclo de Vida del Servicio
Permitir que el Proveedor de Servicios sea más eficiente y mejorar la calidad del servicio,
aumentar la satisfacción y reducir el coste del servicio
Asegurar que el personal tenga una comprensión clara y común del valor que ofrecen sus
servicios a los clientes, y las formas en que las prestaciones se realizan a partir de la
utilización de los servicios
Mantener el Sistema de Gestión del Conocimiento de los Servicios (SKMS); que proporciona
el control de acceso al conocimiento, información y datos que son apropiados para cada
audiencia
Recoger, analizar, almacenar, compartir, utilizar y mantener los conocimientos,
información y datos a través del Proveedor de Servicios
5.10.2. Ámbito
La Gestión del Conocimiento es todo un ciclo en todos los procesos en el que es relevante,
para todas las etapas del Ciclo de Vida de los Servicios y por lo tanto se hace referencia a lo
largo de ITIL 2011 desde la perspectiva de cada publicación
Se trata en cierta medida en otras publicaciones de ITIL, pero en esta módulo se exponen
los conceptos básicos, desde un enfoque de Transición del servicio
Especialmente importante durante la Transición del Servicio es la:
Formación y transferencia del conocimiento, propiedad intelectual, conformidad con las

Leyes y los estándares.
Documentación de errores, soluciones temporales y pruebas.
Conformidad con los requisitos legales, con la política de la empresa y /o los códigos de
conducta profesional
Requisitos documentados para la retención de cada categoría de datos, información y
conocimiento
Definir las formas en que los datos, la información y el conocimiento sean fácilmente
utilizables por la organización
Que los datos, la información y conocimiento sean actuales, completos y válidos

Que los datos, la información y el conocimiento estén disponibles para las personas que lo
necesitan y cuando lo necesiten
Eliminación de los datos, la información y el conocimiento necesario
La información es la fuente principal de Negocio y es el recurso estratégico más importante
que maneja una Organización
La combinación de información, experiencia, contexto, interpretación y reflexión se
convierte en Conocimiento. La Mejora Continua de los Servicios convierte este
conocimiento en Sabiduría.
Sabiduría es la capacidad de hacer evaluaciones correctas y tomar las decisiones adecuadas

haciendo el mejor uso de los datos, información y conocimiento.
Esto se conoce como el modelo (DIKW) datos-información-conocimiento-sabiduría.
5.10.4. Actividades
Estrategia de Gestión del Conocimiento.
Transferencia del conocimiento.
Gestión de la información y los datos.
Uso del sistema SKMS.
Comunicar los objetivos del cambio.
Para dar soporte al Proveedor de Servicios para mejorar la eficiencia y la calidad de los
servicios.

Dentro de IT Service Management, la Gestión del Conocimiento enfoca sobre el Service Knowledge
Management System (SKMS). El SKMS se apoya en TODOS los datos, llevados a cabo en un depósito
lógico central o Configuration Management System (CMS) and Configuration Management
Database (CMDB)
El SKMS es un concepto más amplio que la CMDB y del CMS y cubre una base mucho más amplia del
conocimiento.
Service Knowledge Management System

SKMS DECISIONES
Configuration Management System
CMS
Configuration Management
Database CMDB

El personal de Transición del Servicio debe documentar y analizar los errores ocurridos y
proporcionar a Operaciones de Servicio el acceso a dicha información y las posibles
soluciones temporales.
Al mismo tiempo se debe devolver información a Diseño de Servicio si se necesita un
cambio de método.
La gestión de almacenamiento de las actas de las reuniones con el cliente
Las actualizaciones del Catálogo de Servicios o la Cartera de Servicios
La modificación de un Paquete de Diseño de Servicios
La creación de un nuevo o modificado Plan de Capacidad
La recepción de un manual para usuarios, actualizado por un proveedor
Creación de un informe de los clientes
Las actualizaciones del registro de la Mejora continua de los Servicios CSI
5.10.6. Entradas
Las entradas para el proceso de Gestión del Conocimiento incluye todo el conocimiento, la
información y los datos utilizados por el proveedor de servicios (SP), así como los datos de
negocio relevantes
5.10.7. Salidas
Los técnicos de Operaciones de TI, como es el personal de las líneas de escalado de Gestión
de Incidencias y el Centro de Servicio al Usuario, son el punto de captura de gran parte de
datos de ITSM
Si estos técnicos no entienden la importancia de su papel entonces la Gestión del
Conocimiento no será eficiente
Tradicionalmente, los analistas de soporte han sido reacios a registrar sus acciones, por la
sensación de que esto puede socavar su posición dentro de la organización
Cambiar este valor a una actitud de apreciar los beneficios al re-usar el conocimiento es la
clave para el éxito de Gestión del Conocimiento
El personal técnico de Gestión de Problemas serán los principales usuarios de los
conocimientos adquiridos y por lo general responsable de la normalización de la captura de
datos por medio del desarrollo y mantenimiento de scripts
5.10.8. Desafíos
La implementación del proceso de Gestión del Conocimiento puede ser una tarea difícil
La mayoría de las organizaciones, normalmente, ya tienen reservas y almacenamiento de
datos, información y conocimiento que cumplen con muchas de sus necesidades, y puede
ser un reto el tener que justificar el esfuerzo que se necesita para crear una arquitectura
coherente para la gestión de estos datos, de la información y del conocimiento

5.10.9. Riesgos
El personal se centra en las herramientas de soporte, en lugar de la creación de valor
Insuficiente comprensión de lo que el conocimiento, la información y los datos son
necesarios para la organización
Falta de inversión en las herramientas y el personal necesario para apoyar el SKMS
Demasiado esfuerzo en la captura de conocimientos, con una atención insuficiente a la
transferencia de conocimiento y re-uso
Almacenamiento y el intercambio de conocimientos e información que no están al día
Falta de apoyo y compromiso de las partes interesadas
5.10.10. Métricas
El personal de Operaciones de Servicio, como el de Gestión de Incidencias tanto de la primera línea
de soporte como de las sucesivas que haya, es el punto central de recopilación de información.
Es fundamental documentar y transferir esta información y conocimiento a todo TI involucrado,

sobre todo a Gestión de Problemas.
5.10.11. KPIs de la contribución del suministrador de TI

Implementación satisfactoria de servicios nuevos o modificados.
Aumento del conocimiento en el grupo objetivo.
Más y mejores respuestas a las preguntas.
Menor dependencia del personal para el conocimiento.
Localización e identificación de la información de diagnóstico de incidencias y
problemas.
Se puede determinar el valor de la Gestión del Conocimiento para la
organización.
5.10.12. KPIs relevantes para el cliente

Menor duración del Soporte Post-Implantación.
Tiempos más cortos para resolución de incidentes y problemas.
Mejor experiencia de los usuarios.
Menos informes innecesarios de errores por mejor transferencia del conocimiento.
5.10.13. KPIs relevantes para el Proveedor de Servicios

Uso de la base del conocimiento.
Errores detectados por el personal o por las Auditorías.
Participación del personal en foros de discusión técnica.
Mejor aprovechamiento de las FAQ’s.
Satisfacción con los cursos, boletines y material de autoayuda.
Grado de reutilización del material documentado.

5.10.14. El sistema de 4 capas de la SKMS

Proveer servicios a clientes en distintas regiones y zonas horarias y diferentes turnos de operaciones
requiere comunicación del conocimiento con normas y procedimientos ordenados y estrictos.
El Proveedor de Servicios debe desarrollar un sistema de uso de SKMS que esté disponible a los
interesados y satisfaga las expectativas de los clientes.
PORTAL Vista Vista Vista Vista

Vista Vista
Cambio y Configuración Gestión de Service
Nivel de Gestión de Configuración
Entrega Técnica Calidad Desk
Presentació
Presentación Activos Ciclo de vida
Nivel de FAQ Gestión de Rendimiento Tablero de Alertas

Proceso del Análisis Report Pronóstico, Planeamiento Modelado
Monitorización
Conocimiento
Negocio/Clientes/usuarios – Servicios – Aplicaciones – Mapeo de la Infraestructura

Gestión
Servicio Portafolio Modelo de CMDB Gestión
de Cambio
Servicio Catálogo de Entrega
Servicios Integrada
Nivel de
Integració
Integración de INTEGRACIÓN DE DATOS
la informació Procesos comunes Mapa Gestión Reconciliación Sincronización Extracción
información Datos e del Schema de Meta Data de Datos de Datos Transformación
Explotación
información Carga
Librería Gestión de Herramientas de auditoria y administración

Archivo Multimedia
Documentación Configuración de activos
Definitiva
del Proyecto de Software
Librería de Herramientas de Configuración de
Documentación
Estructurado CMDBs FISICAS Plataformas, Bases de Datos,
Definitiva
Nivel de Almacenamiento, Escritorios, Mainframe
Origen de la Software Librería
Del Proyecto Multimedia Gestión de Aplicaciones corporativas,
CMDB1 CMDB2
Informació
Información y Definitiva 1
accesos, Recursos Humanos, de Cadenas de
de los Datos suministradores, Relaciones con clientes

Operaciones del Servicio .6

6.1. Operaciones del Servicio en el Ciclo de Vida de los Servicios
6.1.1. Meta
La empresa para cumplir sus objetivos y el funcionamiento eficiente de los componentes de los
servicios de soporte y centrarse en gestionar eficazmente los requerimientos de los usuarios y
clientes en el día a día, manteniendo al mismo tiempo una gestión proactiva.
Además debe gestionar los servicios a los niveles acordados a través de la coordinación y realizar
actividades para proporcionar esos procesos.
Administrar la tecnología que se utiliza para ofrecer servicios y apoyo.
Realizar, gestionar y controlar día a día el funcionamiento de los procesos (uso de Diseño del
Servicio y de Transición del Servicio).
Ayudar a los Profesionales en Operación del Servicio para alcanzar un equilibrio entre:
El Negocio para cumplir sus objetivos y
El funcionamiento efectivo de los componentes que usan los servicios para centrarse en el
manejo de los aspectos del día a día mientras que mantiene una perspectiva de mayor
contexto
6.1.2. Objetivos
Servicios estables
Terminar las prácticas de las operaciones de extremo a extremo y de forma robusta
Procesos rediseñados para la solución de incidentes y de problemas
Cumplimiento de los eventos de la tecnología y de las peticiones de servicio
Influenciar en la Estrategia, Diseño, la Transición y de la Mejora de Servicios
Modelos de SOA, de virtualización, adaptables y ágiles de Operaciones de Servicio
Manejar los servicios en los niveles convenidos y coordinarlos
Realizar las actividades para entregar procesos de negocio
Manejar la tecnología que se utiliza para entregar los servicios de asistencia
Manejar las operaciones cotidianas de los procesos (usando la transición, el diseño del
servicio y la mejora del servicio)
Permitir la Mejora Continua del Servicio y su supervisión y determinar las Métricas (KPIs) y
coleccionar los datos
Habilitar la Mejora Continua de Servicio mediante el seguimiento de la ejecución, evaluar las
cifras y recopilar datos, por lo que su ámbito es sobre:
Los Servicios
La Tecnología
Los Procesos de Gestión de Servicios.
Las Personas

6.1.3. Ámbito
Reducir el trabajo planificado y costes tanto para el negocio como a TI a través del manejo
optimizado de las interrupciones del servicio y la identificación de sus causas
Reducir la duración y la frecuencia de las interrupciones del servicio
Proporcionar los resultados operativos y datos que pueden ser utilizados por otros procesos
de ITIL para mejorar los servicios de forma continua
Cumplir con las metas y objetivos de la política de seguridad, asegurando que a los servicios
puedan acceder sólo las entidades autorizadas
Proporcionar un acceso rápido y efectivo a los servicios estándar que el personal de las
empresas deben utilizar para mejorar su productividad o la calidad de los servicios de
negocio y productos
Proporcionar una base para las operaciones automatizadas, lo que aumenta la eficiencia y
permitir que los recursos humanos de alto nivel puedan emplearse en trabajos más
innovadores

En Estrategia del Servicio es donde el servicio es modelado.
En Diseño del Servicio y de Transición es cuando el coste de los servicios está diseñado,
probado, validado y previsto.
En Mejora Continua de los Servicios es cuando las Métricas (KPIs) se identifican y optimizan.
El único valor que importa, es el percibido por el cliente.
Es en Operaciones de Servicio cuando el VALOR se entrega y es juzgado.
El propósito de Operación del Servicio es la entrega y soporte de servicios de TI a un nivel
acordado con los usuarios del Negocio y clientes
6.1.5. Servicios de TI vs. Componentes de Tecnología
Las organizaciones deben centrarse en los requisitos del Negocio y cómo lo entregarán así como qué
servicios soportan en los sistemas internos para entregar valor. Los desequilibrios de las diferencias
provienen la cultura de la Gerencia de la Organización y conllevan una baja madurez
6.1.5.1. TI Servicios
Se trata de cómo los clientes y los usuarios perciben desde su perspectiva los servicios. Los
clientes/los usuarios no se preocupan acerca de los detalles de qué tecnología se utiliza para
manejar servicios, pero si se preocupan de cómo los servicios les sean entregados cuando les es
necesario y convenidos
6.1.5.2. Componentes de la Tecnología

Se trata de cómo los componentes y los sistemas se manejan con habilidad para entregar los
servicios. Diversos equipos y los departamentos manejan tecnología, así cada uno debe centrarse en
la realización del buen funcionamiento y de la disponibilidad de sus sistemas

En la figura más abajo que se inclina hacia el lado de la tecnología es posible que NO CUMPLAMOS
lo acordado en el SLA
En la figura más abajo que se inclina hacia el lado del Cliente es posible que entreguemos
el servicio por ENCIMA de lo acordado en el SLA
En la figura más abajo está equilibrada entre Cliente y tecnología. Es muy posible
que entreguemos el servicio por lo acordado en el SLA.
Alcanzando el equilibrio entre la calidad y el coste ayudamos a la consistencia de la Entrega de los

servicios a los niveles convenidos y conservamos la relación coste / recursos en un nivel óptimo. Los
requisitos del porcentaje de disponibilidad se pueden utilizar para entregar servicio en el coste
apropiado y para evitar el “sobre modelado” o “bajo modelado”.
Demasiado foco en la calidad - Entregamos más de lo necesario y con un coste más
alto
Demasiado foco en el coste - Entregamos por debajo del presupuesto, riesgo de
entregar los servicios inferior al nivel normal
La realización de un equilibrio asegurará la Entrega del Nivel de Servicio necesario para cumplir los
requisitos del Negocio en un coste óptimo según lo acordado
6.1.6. Principios de Operación del Servicio

Provisión del Servicio: Todo el personal de Operaciones tiene que ser consciente de que su objetivo
es “proveer servicios” al negocio
Implicación del personal en Diseño y Transición del Servicio: Para proporcionar
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 para evaluar el ROI y las estrategias de su reducción
Salud Operativa: Se puede determinar aislando algunos 'signos vitales' importantes en dispositivos y
servicios que se definen como críticos para lograr el éxito en la ejecución de una Función Vital del
Negocio (VFB)
Comunicación:Es necesaria con otros equipos y departamentos de TI, con los usuarios y los clientes
internos, y entre los propios equipos de Operación del Servicio.
Documentación:Gestión de Operaciones de TI, los equipos y departamentos de Gestión Técnica y de
Aplicaciones están implicados en la creación y mantenimiento de la documentación de Operaciones
6.1.7. Estabilidad vs. Responsabilidad

No importa cómo es de buena la funcionalidad del Servicio de TI y cómo el diseño se
haya preparado al máximo detalle si luego los componentes del servicio no están
disponibles.
Esto significa que Operación de Servicio necesita asegurarse de que infraestructura
esté estable y disponible según lo diseñado.
Cada cambio trae con él una oportunidad de proporcionar mejores niveles de
servicio al Negocio. En cambios evolutivos, es posible planear cómo responder al
cambio y mantener así la estabilidad durante los cambios.
Muchos cambios suceden muy rápidamente y a veces bajo extrema presión.
Algunas organizaciones de TI tienden a centrarse en la estabilidad de la
infraestructura de TI sin la capacidad de responder a los cambios rápidamente.

6.1.8. Calidad vs Coste

Un aumento en el nivel de calidad da lugar generalmente a un aumento en el coste
de ese servicio y viceversa. Pero no siempre la relación es directamente
proporcional.
En el Ciclo de Vida del Servicio es posible alcanzar aumentos significativos en calidad
del servicio con relativamente una pequeña inversión de efectivo. Por ejemplo, la
mejora de disponibilidad de servicio a partir de la 65% hasta el 75% es bastante
directa y puede no requerir una inversión enorme.
Mientras que esto puede parecer directo, muchas organizaciones están bajo una
gran presión para aumentar la calidad de servicio mientras que hay que reducir los
costes. Algunos costes se pueden reducir de forma incremental en un cierto plazo,
pero la mayoría del ahorro en costes se puede hacer solamente una vez.
Para determinar el equilibrio apropiado entre coste y calidad se debe hacer durante
la Estrategia de Servicio y la fase del Ciclo de Vida del Diseño del Servicio, aunque en
muchas organizaciones se deje esto a los equipos de la Operación de Servicio
6.1.9. Reactiva vs Reactiva

Una organización reactiva es la que no actúa a menos que se le exija hacer algo por
un disparador externo. En muchas organizaciones se hace foco en la gestión reactiva
para asegurar que los servicios sean altamente constantes y estables, desalentando
el comportamiento dinámico del personal de Operaciones de TI.
Una organización dinámica está buscando siempre la manera de mejorar la situación
actual. El comportamiento dinámico se considera generalmente como positivo ya
que permite a la organización mantener ventaja en un ambiente dinámico de
Negocio. Sin embargo, el ser demasiado dinámico puede ser costoso y dar lugar al
personal se distraiga del día a día. La necesidad de un equilibrio apropiado en
comportamiento reactivo y proactivo alcanza a menudo el resultado óptimo .
El papel de la Operación de Servicio es por lo tanto alcanzar un equilibrio entre ser
reactivo y dinámico.
6.1.10. Tecnología y Arquitectura

Auto Ayuda: Muchas organizaciones desarrollan software de auto ayuda como
pueden ser páginas con menús de guía con interfaces a otros programas o
servidores para la resolución de incidencias o de información
Flujos de Trabajo y Motores de Control de Procesos: Los Flujos de Trabajo o
Motores de Control de Procesos son necesarios para la pre-definición de Incidentes,
Gestión de Peticiones, Problemas, Cambios y demás. Esto permite a los responsables
rutas de escalado, tiempos de resolución de Incidentes o Problemas, alertas y si está
predefinido el disparo de alertas para una gestión automatizada.
Descubrimiento / Despliegue / Tecnología Licenciada: Las herramientas de
Descubrimiento de hardware y software son necesarias para verificar los datos del
Sistema de Gestión de la Configuración (CMS) y en la gestión de Licencias,
descubriendo licencias de software obsoletas y sin licenciar con lo que ello supone
de pérdida de imagen, sanciones, etc.

6.1.11. Licencias de software

El coste de herramientas de ITSM se determina por el número y el tipo de licencias
de usuario que se necesite. Las herramientas se venden en formato modular, así
que la funcionalidad de cada módulo necesita ser entendida para determinar
cuántos y qué tipo de usuarios acceden al módulo. Las licencias están disponibles
en varios tipos y varían según que fabricante del software. Ejemplos:
Licencias dedicadas: Para el personal que requiere frecuente y uso prolongado del
módulo (por ej: el personal del Centro de Servicio al Usuario necesitaría una licencia
dedicada para utilizar un módulo de Gestión de Incidencias)
Licencias compartidas o flotantes: Para el personal que hace uso regular de
módulos, pero con intervalos significativos puede usar una licencia compartida (por
ej. la tercera-línea de escalado de soporte puede necesitar el acceso regular al
módulo de Gestión de Incidencias, pero solo al actualizar un expediente de
incidente). Las licencias requeridas por el nº de usuarios debe ser evaluado, y
dependerá del nº de usuarios potenciales, de períodos de uso y de la frecuencia
para estimar la concurrencia. El coste de una licencia compartida suele ser mayor
que el de las dedicadas; pero el coste total es menor pues los usuarios están
compartiendo las licencias que se necesitan en total
Licencias Web: Normalmente las licencias web cuestan menos que otras licencias
(incluso podrían ser gratuitas si se adquirieran con otras licencias), y el índice de uso
también suele ser menor, por lo que los costes generales se reducen
6.1.12. Roles en Operación del Servicio

Gestor del Centro de Servicio al Usuario
Supervisor del Centro de Servicio al Usuario
Super Usuarios
Gestores Técnicos / Jefes de Equipos
Analistas / Arquitectos Técnicos
Operador Técnico
Gestor de Operaciones de TI
Analistas de Operaciones de TI
Operadores de TI
Jefes de Equipo / Gestores de Aplicaciones
Analistas / Arquitectos de aplicaciones
Gestores de los Procesos de Eventos, Incidencias, Problemas, Accesos y Peticiones

6.2. Procesos y actividades

Los procesos más específicamente detallados en Operación del Servicio son:
Gestión de Eventos
Gestión de Incidentes
Gestión de Problemas
Gestión de Accesos
Gestión de Peticiones
Y las cuatro funciones que son:
Función Gestión Técnica
Función Centro de Servicio al Usuario
Función Gestión de Aplicaciones
Función Gestión de Operaciones de TI
Hay otros procesos que se ejecutan en Operación del Servicio; pero se dirigen desde otras
fases del Ciclo de Vida
Gestión de Cambios
Gestión de la Capacidad
Gestión Financiera de TI
Gestión del Configuración y Activos del Servicio
Gestión de la Continuidad de los Servicios
También se desarrollarán los Servicios de Medición y Generación de Informes del Servicio

6.3. Gestión de Eventos

¿Qué es un evento?
Un cambio de estado significativo para la cuestión de un Elemento de Configuración o un
Servicio de TI. El término Evento también se usa como Alerta o notificación creada por un
Servicio de TI, Elemento de Configuración o herramienta de Monitorización. Los Eventos
requieren normalmente que el personal de Operaciones de TI tome acciones, y a menudo
conllevan el registro de Incidentes.
Las notificaciones de eventos de Excepciones serían usadas para iniciar futuras actividades
de recuperación
6.3.1. Definiciones y conceptos Genéricos

Alerta: Advertencia o aviso acerca de umbral, cambio o fracaso que se ha producido.
Creado y controlado por Sistema de Gestión de Herramientas y el proceso de Gestión de
Eventos.
Evento: Cualquier ocurrencia perceptible o discernible que resulte significativa para la

gestión de la infraestructura de TI
Objetivos
Para detectar y analizar acontecimientos y tener conocimiento de los mismos
Para determinar la acción de control apropiada, base para la supervisión y el control
operacionales
Para automatizar actividades de la gestión de operaciones y comunicar la información
operacional:
Para proporcionar el punto de entrada para la ejecución de procesos y de actividades
Para comparar funcionamiento real y comportamiento contra estándares de diseño y
SLA
Detectar todos los cambios de estado que tienen importancia para la gestión de un
servicio, de un CI o TI
Proporcionar el disparador, o punto de entrada, para la ejecución de los procesos de
explotación del servicio y las actividades de las operaciones de gestión
Proporcionar los medios para comparar el rendimiento operativo real y el
comportamiento frente a los estándares de diseño y SLAs
Proporcionar una base para la garantía de servicio y presentación de informes y la
mejora del servicio
6.3.2. Tipos de Eventos

Advertencia
Información
Excepción

6.3.3. Ámbito
Se aplica a cualquiera de los aspectos de la Gestión de Servicios que se pueda controlar y

automatizar.
Se incluirán algunos Cl porque su estado necesita cambiar frecuentemente. Gestión de
Eventos puede servir para automatizar estos cambios de estado y actualizar el CMS
Condiciones ambientales (p. ej., 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 (p. ej., detección de intrusiones)
Actividad normal (p. ej., seguimiento del uso de una aplicación o rendimiento de un
servidor)
La gestión de eventos tiene un valor indirecto pero de vital importancia en la Gestión de

Servicios de Ti.
Gestión de Eventos provee mecanismos para la detección anticipada de incidencias lo
que hace posible detectar y asignar la incidencia al grupo adecuado para tomar
acciones antes de que se produzca cualquier interrupción real del servicio
Posibilita la monitorización de algunas actividades automatizadas mediante
excepciones y se elimina la necesidad de una monitorización de recursos cara e
intensiva en tiempo real
Cuando se integra en otros procesos de Gestión del Servicio (p. ej.: Gestión de la
Disponibilidad o de la Capacidad), puede señalar cambios de estado o excepciones que
permitan aplicar una respuesta anticipada
Proporciona la base para realizar operaciones automatizadas, aumentando la eficiencia
y permitiendo asignar los recursos humanos más costosos a trabajos más innovadores
o definiendo nuevas formas con las que el negocio pueda explotar la tecnología para
conseguir aumentar su ventaja competitiva
6.3.5. Actividades, métodos y técnicas.
El Evento tiene lugar

Notificación del evento
Detección de Eventos
Filtros de Eventos
Clasificación de Eventos
Correlación de Eventos
Disparo de alarmas
Selección de respuesta
Evaluación de acciones
Cerrar Evento
Informes de Eventos

Evento
Notificación
de evento
Evento
detectado
Gestión de
Incidencias
Evento
filtrado
Informativo Excepción ¿Incidencia, Gestión de

¿Importante? Problema, Problemas
Cambio?
Correlación
de evento
Gestión de
Cambios
Disparador
Evento Respuesta Respuesta

registrado automática ALERTA humana
Revisar Acciones
SI NO
FIN Cerrar Evento ¿Eficientes?
6.3.6. Clasificación de Eventos
Los eventos se pueden clasificar en:
Según la indicación regular:
Notificar cuando la descarga programada ha sido completa

Usuario que se valida en una aplicación
Email que fue recibido por el recipiente correcto
Indica una excepción (error)
Usuario intenta registrarse con password errónea
Dispositivo de CPU por debajo del umbral de utilización
PC escaneado ha indicado software no autorizado
Eventos que implican una operación inusual pero no excepcional
El uso de la memoria de un servidor se acerca al 5% de su nivel de rendimiento más

alto aceptable
• El tiempo de duración de una transacción es un 10% mayor de lo normal.

6.3.7. Disparadores
Excepciones para cualquier nivel de rendimiento de un CI definido en las
especificaciones del diseño, OLAs o SOPs
Excepciones a un proceso o procedimiento automatizado, p. ej., un cambio rutinario
que haya sido asignado a un equipo de desarrollo y que no haya concluido a tiempo
Una excepción dentro de un proceso de negocio que está siendo monitorizado por
Gestión de Eventos
La finalización de un trabajo o tarea automatizada
Un cambio de estado en un dispositivo o registro de base de datos
Acceso de un usuario o procedimiento automatizado o trabajo por lotes a una
aplicación o base de datos
Una situación en la que un dispositivo, base de datos o aplicación, etc., ha alcanzado el
umbral de rendimiento predefinido
6.3.8. Entradas
Atender los requerimientos de nivel asociado y operacionales
Las alarmas, las alertas y los umbrales para reconocer eventos
Tablas de correlación de eventos, normas, códigos de eventos y soluciones de
respuesta automática
Los roles y responsabilidades para el reconocimiento de eventos y comunicación a los
que deben manejarlos
Los procedimientos operativos para el reconocimiento, registro, escalado y la
comunicación de eventos
6.3.9. Salidas
Eventos comunicados y escalados a los responsables
Registros de eventos con su descripción y actividades
Eventos que indican que un incidente ha ocurrido
Eventos que indican la posible brecha de un SLA u objetivo OLA
Eventos y alertas que indican el estado de finalización del despliegue, actividades de
soporte o de otros
SKMS con la información de eventos y su historia

Eventos que se han comunicado y se escalaron a los responsables para la adopción de
nuevas medidas
Registros de eventos que tuvieron lugar y las actividades de cualquier tipo y escalado y
de comunicación adoptadas para apoyar el diagnóstico forense, o más actividades de
CSI
Eventos que indican que un incidente ha ocurrido
Eventos que indican posibles incumplimientos de un SLA
Eventos y alertas que indican el estado de finalización del despliegue o actividades de
soporte
SKMS con la información de eventos y su historia

6.3.11. Desafíos
Un desafío inicial podría ser la financiación para la adquisición de las herramientas y
esfuerzo necesario para implantar dichas herramientas
Establecer el nivel correcto de filtrado. Si se establece incorrectamente se podría
generar un desbordamiento con respecto a eventos relativamente insignificantes
El despliegue de agentes de monitorización a través de toda la infraestructura de TI,
podría resultar una actividad difícil y lenta
La adquisición de los perfiles necesarios puede ser lenta y costosa
6.3.12. Riesgos
Error a la hora de obtener la financiación adecuada
Garantizar el nivel correcto de filtrado
Error a la hora de mantener el impulso en el despliegue de los agentes de
monitorización a través de la infraestructura de TI
Gestión de Cambios
Gestión de Gestión del

Seguridad Nivel de Servicio
Gestión de
Gestión de Eventos
Capacidad Gestión
de Incidentes
Gestión de Problemas Gestión de la

Configuración
CMS
Gestión de la
Gestión de Disponibilidad
Accesos
6.3.14. Roles de Gestor de Eventos

Se juzga innecesario designar a un encargado de eventos específicos puesto que los eventos tienden
a ocurrir en contextos múltiples y por muchas diversas razones. Las actividades de la Gestión de
Eventos se delegan al Puente de Operaciones de la función Operaciones de TI.
La Gestión Técnica tiene que asegurarse de que se forme al personal adecuadamente y de que
tienen acceso a las herramientas apropiadas para permitirles realizar estas tareas.

6.3.15. Relaciones del Gestor de Eventos en las Fases del Ciclo de

Vida de los Servicios
Centro de Atención al Usuario
Información de comunicación. Sobre el tipo de incidente al equipo directivo técnico
apropiado y en su caso al usuario.
Investigación y resolución de acontecimientos. El Centro de Atención al Usuario se
extiende a los equipos apropiados de la Operación del Servicio
Clasifique los acontecimientos, ponga al día los motores de la interrelación y asegúrese
de que cualquier auto-respuesta está definida
Asegúrese de que los acontecimientos estén generados correctamente y de que las
respuestas definidas son apropiadas
Operación del Servicio
Realice la Gestión de Eventos para los sistemas bajo su control. Es inusual que haya
equipos de técnicos que tengan una persona dedicada para manejar a la Gestión de
Eventos, pero para cada líder de los equipos de personas se asegurará de que los
procedimientos apropiados estén definidos y ejecutados según los requisitos de los
procesos y de sus políticas
6.3.16. Interfaces u otros disparadores

Excepciones a todos los niveles de rendimiento de CIs en las especificaciones del
diseño.
Una especificación en un proceso del negocio monitorizado por la gestión de eventos.
Un cambio de estado en un dispositivo o registro de la base de datos.
Un trabajo automatizado que se ha completado.
Acceso de un usuario a una aplicación o BBDD.
6.3.17. Métricas
Número de eventos por categoría.
Número de eventos por importancia y criticidad.
Número y porcentaje de eventos que requiere intervención humana y si se ha
realizado.
Número y porcentaje de eventos que han dado como resultado incidencias o cambios.
Número y porcentaje de eventos que en porcentajes sobre cada tipo de evento en cada
plataforma y/o aplicación.
6.3.18. Riesgos
No conseguir los recursos financieros suficientes de la dirección la financiación.
Determinar el nivel de filtrado correcto.
No poder mantener en el momento preciso el despliegue de los agentes de
monitorización


6.4. Gestión de Peticiones de Servicio

Una petición de servicio es una solicitud de información, asesoramiento, cambio
estándar o acceso a un servicio por parte de un usuario. Por lo general pasan por el
Centro de Servicio al Usuario
6.4.1. Objetivos
Proporcionar la información sobre la disponibilidad y obtención de servicios
Poner a disposición de los usuarios un canal para que puedan recibir servicios
estándares para el que hay una cualificación y aprobación
Proporcionar componentes de los servicios estándares como son las licencias, etc.
Ayudar con la información de carácter general, quejas y aclaraciones
Se ocupa de las solicitudes de los usuarios que no son fallos en la infraestructura TI ni
de software.
Solicitud de información y aclaraciones
Asesoramiento
Cambio estándar o acceso a un servicio por parte del usuario que inicialmente pasa
por el Centro del Servicio al Usuario
Cambios de bajo riesgo y bien entendidos
Cambios de bajo coste, que ocurren con frecuencia y son de bajo riesgo
P. Ej.: petición de manuales o consumibles, aprobaciones financieras, etc.
6.4.2. Ámbito
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)
6.4.3. Valor
La capacidad de proporcionar un acceso rápido y efectivo a los servicios estándar que
el personal de las empresas pueden utilizar para mejorar su productividad o la calidad
de los servicios de negocio y productos
La capacidad de reducir efectivamente la burocracia en la solicitud y recepción de
acceso a los servicios existentes o nuevos, por tanto, también reducir el coste de la
prestación de estos servicios
La posibilidad de aumentar el nivel de control sobre los servicios solicitados a través de
una función centralizada de cumplimiento. Esto a su vez puede ayudar a reducir costes
mediante la negociación centralizada con los proveedores, y también puede ayudar a
reducir el coste de soporte

6.4.4. Actividades
Admitirán Solicitudes de Servicio de servicios que estén en el Service Catalogue pero no
tienen la responsabilidad de actualizar el Service Catalogue
Al Centro de Servicio al Usuario nunca se le requiere para peticiones de servicio, se
llama a Gestión de Peticiones
Suministrar y proveer pequeños cambios que suelen pasar por el Centro de Servicio al
Usuario.
Proveer los canales para que los usuarios puedan solicitar y recibir servicios estándar,
para los cuales existe un proceso predefinido de aprobación y cualificación.
Es responsable de cambios económicos, que ocurren con frecuencia y son de bajo
riesgo
Centro de Servicio Interfaz Llamada de

al Usuario RFC WEB Teléfono E_mail
Solicitud
Recibida
Registro de Solicitud A Gestión de

¿Es Incidentes,
y validación
realmente si es un incidente o a
si Una NO Gestión de la Cartera si
Solicitud? es una propuesta de
Priorizar Categorizar ¿Solicitud cambio
Solicitud
Solicitud Solicitud validada?
devuelta
Gestión de si NO
Accesos Autorizar
Solicitud
Gestión
Financiera
¿Solicitud
Autorizada? Solicitud
devuelta
NO
si
Solicitud Gestión de
autorizada Cambios
si
¿CI
¿Solicitud Modelo ¿Solicitud si Solicitud
si Enrutada? ejecución de
Impactado?
cumplimentada? Cerrada FIN
NO Solicitud
Escalado NO
Funcional Gestión
Solicitud
Financiera
Devuelta

Las peticiones del servicio se repetirán con frecuencia, así que un flujo de proceso
predefinido (un modelo) se puede crear para incluir las etapas necesarias para
satisfacer las peticiones
Las peticiones del servicio serán satisfechas generalmente ejecutando un cambio
estándar
No son Peticiones de Servicio los de la categoría de Gestión de Cambios.
Son peticiones de servicio: P. ej.: cambios de password, petición de manuales o
consumibles, restauración de archivos, instalaciones de ofimática, etc.
Los cambios no estandarizados que son manejados como RFC seguirán el
procedimiento formal de la Gestión de Cambios y éstos tampoco son peticiones de
servicio.

6.4.6. Entradas
Solicitudes de trabajo
Formularios de autorización
Peticiones de Servicio
RFC para cambios estándar
Solicitudes tales como llamadas telefónicas, interfaces web o correo electrónico o de
información.
6.4.7. Salidas
RFCs para resolución de cambios estándar
Autorizado / rechazado las solicitudes de servicio
Solicitud de informes de cumplimiento de la condición
Actualización de activos / CI actualizados
Actualización de registros de solicitud
Solicitudes de servicio cerradas
Solicitudes de servicio canceladas
6.4.8. Gestión de la Información en Gestión de Peticiones

Las Peticiones de Servicio contendrán información sobre:
El servicio que se está solicitando
Quién solicitó y autorizó el servicio
Qué proceso se utilizará para satisfacer la petición
A quienes se asignó y qué acción se tomó
La fecha y hora en las que se registró la petición
Detalles del cierre
Solicitudes de Cambio: En algunos casos el proceso de Gestión de Peticiones se iniciará
a través de una RFC
Las Políticas de Seguridad formularán cualquier control a llevar a cabo o al que
adherirse en la provisión de un servicio, garantizando que el solicitante esté autorizado
a acceder al servicio, o que se licencie el software
6.4.9. Roles
La propiedad de las peticiones del servicio reside con el Centro de Servicio al Usuario que
supervisa, extiende, envía y satisface las necesidades de peticiones e incidentes de usuario
El Propietario del Servicio de Gestión de Peticiones es el responsable para asegurar que el
proceso se está desarrollado de acuerdo a lo acordado en el SLA.

6.4.10. Interfaces o disparadores

Peticiones de servicio.
Solicitudes de Cambio.
Cartera de Servicios.
Políticas de Seguridad.
6.4.11. Métricas o KPIs

Número de peticiones de servicio
Distribución de peticiones de servicio por fases del Ciclo de Vida.
Número de peticiones de servicio pendientes de resolución.
Tiempo medio de gestión.
Número y porcentaje de peticiones de servicio gestionadas en el plazo acordado.
Coste medio por cada tipo de petición de servicio.
Nivel de satisfacción de los clientes con Gestión de Peticiones.
Gestión de
Gestión de la Accesos Gestión de
Configuración Incidentes
CMS
Gestión del Gestión de

Cambio Peticiones Gestión del
Catálogo
Gestión de Gestión Financiera

Entregas y de TI
Despliegues
Gestión de Peticiones depende de los siguientes Factores Críticos de éxito.

Existencia de acuerdos sobre quien está autorizado a solicitar servicios estándar.
Que los servicios estén publicados en el Catálogo de Servicios.
Existencia de acuerdos sobre qué servicios son estándar.
Definición de procedimientos estándares para gestionar los servicios solicitados.
Usar el CSU como UNICO punto de contacto para solicitar servicios, también puede ser
Internet o una petición automatizada o de auto ayuda.
Uso de herramientas de autoservicio para interfaz de usuarios que se comuniquen con
herramientas de gestión de peticiones


Definir y documentar con claridad
Definir opciones de interfaz que permitan a los usuarios acceder al proceso de Gestión
de Peticiones
6.4.15. Desafíos
Definir claramente y documentar el tipo de solicitudes que se tratarán
Establecimiento de auto-ayuda front-end con las capacidades que permiten a los
usuarios interactuar con éxito
Los objetivos de Nivel de Servicio tendrán que ser acordados y comunicados
El establecimiento de metas puede complicarse cuando se consideran distintos tipos
de usuarios, tales como VIPs, la dirección ejecutiva y personal administrativo
Los costes para el cumplimiento de las peticiones también debe ser acordado
Los acuerdos tendrán que estar descritos para que los servicios sean los normalizados
y que están autorizados para los solicitantes
Asegurarse de que no se viole la política de seguridad de la información
La información solicitada tendrán que ser de fácil acceso
Las solicitudes tendrán que seguir un procedimiento estándar
Las solicitudes de cumplimiento tienen impacto en la satisfacción del usuario
6.4.16. Riesgos
Si el ámbito está mal definido, la gente no sabrá qué es lo que tiene que gestionar el
proceso.
Interfaz de usuarios mal diseñadas dificultarán la presentación de las peticiones de
usuarios.
Procesos internos de gestión mal diseñados pueden hacer que el sistema sea incapaz
de procesar el número de peticiones o el tipo de las mismas.
Si la capacidad de monitorización es insuficiente puede impedir la obtención de
métricas precisas.
6.4.17. Roles en la Comunicación

Observar que no hay medio definitivo para la comunicación, ni hay una localización fija o una
frecuencia. Debe por lo tanto haber una política alrededor de comunicación dentro de cada equipo
o departamento y para cada proceso. Aunque esto deba ser formal, la política no debe ser
incómoda o compleja.
Los canales de comunicaciones correctamente establecidos pueden ayudar a la prevención de las
ediciones de la atenuación. Una política de comunicación debe por lo tanto indicar el propósito
previsto o la acción resultante, así como una audiencia clara, implicada en la determinación de la
necesidad de la comunicación.
Los tipos de comunicación incluyen: • Reuniones • Email • SMS/Pagers • VOIP Documento que
comparte utilidades


6.5. Gestión de Incidentes

Una incidencia es una interrupción no planificada o una reducción de la calidad
de un servicio de TI. El fallo de un CI que aún no ha afectado a un servicio se
considera un incidente también.
6.5.1. Propósito
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.
El Proceso de Gestión de Incidentes trata de minimizar el impacto adverso en las
operaciones del negocio y del usuario.
6.5.2. Objetivos
Restaurar la operación normal del servicio tan rápido y eficiente como sea posible. La
'Operación normal del servicio' se define aquí como la operación del servicio dentro de
los límites de los SLA.
Asegurar que los niveles de calidad y disponibilidad de los servicios se mantengan en lo
establecido en la SLA.
Mantener registros de los incidentes actualizados.
Asegurar que los métodos y procedimientos estandarizados se utilizan para una
respuesta eficaz y rápida, se analizan y se documentan
Aumentar la visibilidad y la comunicación de los incidentes al negocio y personal de
soporte
Mejorar la percepción de negocio de TI mediante el uso de un enfoque profesional en
resolver con rapidez los incidentes que se producen
Alinear las actividades de gestión de incidentes y sus prioridades con las de la empresa
Mantener la satisfacción del usuario con los servicios de la calidad de la información
6.5.3. Definiciones y Conceptos Genéricos

Workaround: Reducción o eliminación del impacto de una incidencia o problema para lo
que no existe una solución definitiva. Puede requerir intervención manual
Incidente: Cualquier evento que no es parte de la operación estándar de un servicio y que
causa o puede causar una interrupción o una reducción de la calidad de servicio.
Límites de tiempo: Tiempo objetivo acordados para resolución de incidencias en contratos
de soporte UCs y en OLAs.
Modelos de Incidencias: Manera de determinar los pasos para ejecutar correctamente un
proceso, lo que es igual a que las incidencias estándar se gestionarán en forma y tiempo
establecido.
Incidencias graves: Requieren procedimientos distintos, plazos más cortos y con mayor
urgencia y tienen alto impacto y prioridad en el negocio.
Una incidencia NUNCA llegará a ser un problema.

6.5.4. Ámbito
Cubre cualquier evento que interrumpe o puede interrumpir un servicio o bien puede bajar
la calidad del servicio
La Gestión de Incidencias incluye cualquier evento que afecte o pueda afectar

negativamente a un servicio. Esto es, eventos que los usuarios comunican
directamente, o 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. Sin
embargo, esto no significa que todos los eventos sean incidencias
Aunque se informa de las incidencias como de las peticiones de servicio al Centro de
Servicio al Usuario, 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

La capacidad de reducir el trabajo planificado y los costes para el negocio y del
personal de soporte causados por incidentes
La capacidad de detectar y resolver incidencias consiguiendo que el tiempo de caída
para el negocio sea menor, lo que implica una mayor disponibilidad del servicio. Esto
significa que el negocio podrá explotar la funcionalidad del servicio según se diseñó
La capacidad para alinear la actividad de TI con las prioridades de negocio. Esto es que
la Gestión de Incidencias incluye la capacidad de identificar prioridades del negocio y
asignar dinámicamente recursos
La capacidad de identificar mejoras potenciales en los servicios
6.5.6. Clasificación de los Incidentes
Prioridad Categoría
Clasificación de Incidencias
Impacto en el Negocio
Por ejemplo:
– Evidencia de efecto en las
actividades de Negocio Aplicación
– Peligro de incumplimiento de – Servicio no disponible
niveles de servicio – Aplicación de consulta /bugs
– Número de usuarios afectados
Hardware
Urgencia del Negocio – Alerta automática
– Tiempo máximo de demora que – Impresora no imprime
acepta el Cliente y/o según lo
acordado en el SLA Solicitud de Servicio
Priorizar recursos – Clave de acceso olvidada
Incidencia de Seguridad
– Recursos Humanos
– Dinero – Virus
– Tiempo
Una “Incidencia Grave” es aquella
Impacto + Urgencia = Prioridad que tiene una alta prioridad o alto
impacto en el negocio

6.5.7. Actividades
Identificación
Registro
Clasificación
Priorización
Diagnóstico inicial
Escalado
Investigación y diagnóstico
Resolución y recuperación
Cierre
6.5.8. Ciclo de Vida del Incidente
Identificación
de Incidencias
Registro
de Incidencias
Categorización
de Incidencias
A Gestión
de Peticiones
Petición de SI
Servicio ?
NO
Procedimiento SI ¿Incidencia
Priorización
de Incidencias Grave o
de Incidencias
graves mayor?
Niveles 2/3
Escalado
Necesita funcional
Soporte
Escalado?
inicial
Investigación Cierre del incidente

Cierre del incidente
y Diagnóstico Resolución y Por Centro de
Por Gestión
Recuperación Servicio al Usuario
de Incidentes
6.5.9. Escalado de los Incidentes
6.5.9.1. Funcional
Si el CSU no puede resolver una incidencia se escala a nivel superior de conocimientos,
habilidades y experiencia. Puede haber varias líneas de soporte basadas en las habilidades y
experiencia.
6.5.9.2. Jerárquico
El CSU escala a la cadena de mandos de la organización que ya está previamente definida
pues puede requerir autorización superior

IT Service
Manager
Jerarquico (Autoridad)
Centro de
Servicio al Usuario
2a Linea 3a Linea
Manager Manager Manager
Centro de Servicio al Centro de Servicio al Centro de Servicio al

Usuario 1ª Línea Usuario 2ª Linea Usuario 3ª Linea
Equipo de Ofimática Equipo de Aplicaciones Equipo de
Funcional (competencia) Comunicaciones
Gestión de
Gestión de la Accesos Gestión de
Configuración Problemas
CMS
Gestión del Gestión de Gestión de la

Cambio Incidencias Seguridad
Gestión de Nivel
de Servicio
Gestión de
la Capacidad Gestión de la
Disponibilidad
6.5.11. Métricas
Número total de incidencias y de mal enrutamiento.
Tiempo Medio transcurrido en alcanzar la resolución de Incidencia o workaround
desglosado por código de impacto.

Porcentaje de incidencias manejados dentro del tiempo de respuesta acordado (los

objetivos de tiempo de respuesta pueden acordarse en los SLAs, ejemplo: por código
de impacto).
Coste promedio por Incidencia.
Porcentaje de incidencias cerradas por el Centro de Servicio al Usuario sin referencia a
otros niveles de soporte.
Número y porcentaje de incidencias resueltas de forma remota sin necesidad de visita.
Incidencias procesadas por puesto de trabajo en el Centro de Servicio al Usuario.

Mantener el CMS actualizado
Mantener un directorio de soporte actualizado
Una KEDB de Problemas y KE actualizados para dar respuestas a través de la CMS o de
una web con las FAQs
Un sistema de BBDDs automatizado para la Gestión de Incidencias
Una relación persistente con Gestión de Nivel de Servicios
Entender fehacientemente cuales son las necesidades del negocio y que se han
identificado
Herramientas de soporte integradas para impulsar y controlar el proceso
6.5.13. Desafíos y Riesgos

Falta de Compromiso desde la Dirección y por los empleados
Falta de definición clara y acordada
Si no están bien definidos en el Catálogo de Servicios (SC) o en el Acuerdo de Nivel de
Servicio (SLA)
Mal redacción en Acuerdos a Nivel de Operacional (OLAs) y Contratos de Soporte (UCs)
Prácticas de trabajo que no se revisan y/o modifican
Objetivos, metas y roles no definidos adecuadamente
La Gerencia no cumple con los SLAs
Usuarios y personal de TI omiten los procedimientos de la Gestión de Incidencias
Mala formación técnica al personal
No se integra con otros procesos. No hay empatía.
No hay inversión en herramientas para automatizar el proceso
Resistencia al cambio


6.6. Gestión de Problemas

Describe una situación no deseable y es la causa de uno o más incidentes.
6.6.1. Objetivos
Prevenir problemas e incidencias y eliminar su repetición y por ello minimizar la
adversidad del impacto de los incidentes y problemas en el negocio, que son causados
por errores en la infraestructura de TI o de software.
No solo solucionar el Problema sino eliminarlo definitivamente
Prevenir la recurrencia de Incidencias ocasionados por un mismo error
Dar de alta una entrada tipo KE inmediatamente después de la solución del Problema
para que exista un registro histórico permanente en el caso de que éste vuelva a
plantearse o en cualquier momento que sea útil registrarlo
6.6.2. Ámbito
Se incluye en todas las actividades para diagnosticar las causas subyacentes de
incidencias y en todas las fases del Ciclo de Vida del Servicio.
Gestión de Problemas incluye las actividades necesarias para diagnosticar la causa raíz
de los incidentes y para determinar la resolución de estos
También es responsable de asegurar que la resolución se lleva a cabo a través de los
procedimientos de control adecuados, en especial la Gestión del Cambio y Gestión de
Entregas y Despliegues
Mantener la información acerca de los problemas y las soluciones correctas, por lo que
la organización reducirá el número y el impacto de los incidentes en el tiempo
Gestión de Problemas tiene una firme relación con Gestión del Conocimiento, y los dos
procesos usarán herramientas como el KEDB
Gestión de Incidentes y Gestión de Problemas son procesos separados, pero están
muy relacionados y por lo general se utilizan las mismas herramientas, y son similares
la categorización, impacto y códigos de prioridad. Esto asegurará una comunicación
eficaz cuando se trata de incidentes y problemas relacionados
6.6.3. Valor
Mayor disponibilidad de servicios de TI al reducir el número y la duración de los
incidentes que esos servicios puedan incurrir
Cuando los incidentes se resuelven, la información acerca de la resolución se registra
para usarse en acelerar el tiempo de resolución y buscar soluciones permanentes
Mayor productividad del personal de TI mediante la reducción de la mano de obra
causada por incidentes no planificados
Reducción de los gastos en soluciones o soluciones que no funcionan
Gestión de Problemas colabora con Gestión de Incidentes y Gestión de Cambios
para mejorar la disponibilidad y calidad en la provisión de servicios de TI.
Resuelta una incidencia y sabida su solución, se registran en el CMS, por lo que
la próxima vez que se repita una incidencia igual o parecida tendremos la
solución, acortando los tiempos de no disponibilidad para los servicios críticos
del negocio.

6.6.4. Actividades
No solucionar el problema sino eliminarlo definitivamente
No restaura el servicio al usuario, eso corresponde a Funciones y Actividades técnicas.
Prevenir la recurrencia de incidentes ocasionados por un mismo error.
Investigar la causa subyacente de los errores e iniciar las acciones de corrección.
Proponer solicitudes de cambio (RFC) para restablecer la calidad del servicio.
Desarrollo y mantenimiento de procedimientos del Control de Problemas y Control de
Errores.
Gestionar el personal de Gestión de Problemas.
Identificar tendencias.
Informes de gestión.
Dirigir las revisiones “post mortem” o de problemas graves.
Dar de alta una entrada tipo KE inmediatamente después de la solución del problema
para que exista un registro histórico permanente en el caso de que éste vuelva a
plantearse.
Aunque puede aún no ser una resolución permanente, el error conocido se debe
registrar en la base de datos de errores conocidos (KEDB) para si se presentan
incidentes o problemas futuros, poderlos identificar y restaurar el servicio más
rápidamente.
En algunos casos puede ser ventajoso registrar un error conocido incluso antes de
completar el proceso aunque solo sea para propósitos de información, por ejemplo -
aunque el diagnostico puede no ser completo o una solución alternativa no se haya
encontrado. Así pues es desaconsejable fijar un punto concreto para registrar el error
conocido.
El registro debe ser anotado siempre. ¡Debe ser hecho tan pronto como llegue a ser útil
hacerlo!

Muchos problemas serán únicos y requerirán el tratamiento de forma individual.
Algunas incidencias puedan ser recurrentes debido a problemas subyacentes o latentes
(por ejemplo, cuando el coste de una resolución permanente es alto y se ha tomado la
decisión de no seguir adelante con una solución cara, lo que implica 'vivir con' el
problema).
Además de crear un Registro de Errores Conocidos en la Base de Datos de Errores
Conocidos (KEDB) para asegurar un rápido diagnóstico, podría ser útil la creación de un
Modelo de Problemas para tratar tales problemas en el futuro.
6.6.6. Conceptos básicos

Error Conocido (Know Error - KE -). La condición que prevalece después de investigar y de
haber realizado un diagnóstico e identificada la causa raíz de un problema. Se puede tener
registro y documentación anterior y una solución provisional en la KEDB. El error es
eliminado mediante la implementación de un cambio.
Los KE se registran y almacenan en la Base de Datos de Errores Conocidos (KEDB)
Petición de Cambio (RFC). Un RFC propone un cambio para eliminar un error conocido (KE).
Workaround: Reducción o eliminación del impacto de una incidencia o problema para lo
que no existe una solución definitiva. Puede requerir intervención manual

6.6.7. Métodos y técnicas
En Gestión de problemas se incluyen dos procesos muy importantes:

Gestión reactiva de problemas: Realizada por Operación del Servicio.
Gestión proactiva de problemas: Normalmente realizada por CSI (Mejora Continua del
Servicio)
6.6.7.1. Gestión Reactiva (Control del Problema)
Se trata de
convertir los
Detección del
Problemas en Problema
Errores
Conocidos (KE)
Registro del
Problema
Centro de
Servicio al
Impacto + Urgencia= Prioridad
Usuario Categorización
Y Priorización
Gestión
de Método Kepner – Tregoe
Eventos Pain Value Analysis
Investigación Análisis de Pareto
y Diagnóstico CMS
Gestión de
Incidencias
¿Workaround?
Gestión
Proactiva
de Problemas
(KE)
Crear registro
Suministrador de Error Conocido KEDB
O Contratista
6.6.7.2. Gestión reactiva (Control del Error (KE))
(SI) RFC
¿Se necesita un Gestión de
Cambio? Cambios
Solución (SI)
¿Cambio
Implementado?
Cierre por
Gestión de
Problemas
¿Problema
(SI) Revisión de
Problemas
Grave?
Graves
(NO)
(SI)
Registro
y cierre

6.6.7.3. Gestión Proactiva de Problemas

Pensar qué cosas se han hecho correctamente
Pensar que cosas se han hecho incorrectamente
¿Cómo impedir que vuelvan a ocurrir?
¿Qué cosas tendremos que hacer en el futuro para impedir Incidencias y Problemas?
Recomendaciones
a los Análisis de
Tendencias de
demás Procesos
Incidentes
registrados
Gestión
Proactiva
Acción Preventiva
Planificada
6.6.8. Análisis de tendencias

Investigar CIs débiles en la infraestructura de TI
Ocurrencias de Problemas después de un cambio
Fallos incipientes de algún tipo en particular
Fallos recurrentes de algún tipo en particular o con un CI singular
Necesidades de documentación y educación a cliente/usuario
Eventos repetitivos desde Gestión de Operaciones y Sistemas
Desde la asistencia a conferencias y foros técnicos
Vistas en publicaciones y documentaciones de referencia
De las sugerencias de los usuarios y grupos de internet
Obtenidas en las reuniones con clientes
Foros y blogs

6.6.9. Relación con Procesos de Incidentes y del Cambio
Control del
NO Investigación Problema KE
I Investigación
y del Error
N NO y
Diagnóstico Solución
C Conocida? Gestión de Cambios
I Cambio
RFC
Autorizado
D Coincide ?
E SI
N Resolver Problema
SI Obtener con el cambio resuelto
T Solución
Con Solución
E Provisional
KEDB (Workaround) Incidente
Workaround o KE resuelto
Gestión
Gestión de
Financiera de TI
Cambios
Gestión de
Nivel de Servicio
Gestión de la
Disponibilidad
Gestión de la
Gestión de
Capacidad
Problemas
Gestión de
Continuidad
Gestión de
Incidencias
Gestión de la
Configuración Gestión de
CMS Entregas

6.6.11. Interrelaciones con otros Procesos
Gestión de
Gestión del Gestión de Gestión del
Relaciones con
Incidente Nivel de Servicio Cambio Clientes
CLIENTE
Gestión de
Problemas Usuarios
Gestión de la Registro
Configuración Aceptación
Clasificación
CONTROL de
Actualización
Planificación Demanda de
Registros Construcción algún Cambio
Pruebas Peticiónes de
Implementación Servicio
Seguimiento Incidentes
6.6.12. Entradas y Salidas con otros Procesos
Gestión del Gestión de la Gestión de la Gestión de Nivel Gestión de la

Configuración de Servicio Disponibilidad
Incidente Capacidad
INFORMACIÓN
Revisión Después de la
Implementación (PIR) INFORMACIÓN
Base de
Comparación de la Control del Problema
Datos de
Información. Control del Error Problemas
Soluciones temporales y
Arreglos rápidos. Gestión Proactiva del Problema REGISTRO
Petición de
Revisión Después de la Cambio
Implementación (PIR) (RFC)
Gestión de Cambios

6.6.13. Interfaces o disparadores
Normalmente se inician en el Centro de Servicio al Usuario y durante las pruebas.

Los siguientes procesos tienen interfaces con la Gestión de Problemas.
6.6.13.1. Estrategia del Servicio

Gestión Financiera: Gestión de Problemas informa sobre costes necesarios para resolver y
prevenir problemas. Esta información es una entrada para los sistemas de presupuestos,
contabilidad y cálculo de TCO.
6.6.13.2. Diseño del Servicio

Gestión de Disponibilidad: Ayuda a determinar cómo reducir el tiempo de caída y aumentar
el de productividad (tiempo disponible).
Gestión de Capacidad: Gestión de Capacidad informa a Gestión de Problemas de los
registros de capacidad y datos de rendimiento y facilita la aplicación de medidas correctivas.
Gestión de Continuidad del Servicio: Gestión de Problemas actúa como el punto de partida
para ITSCM.
6.6.13.3. Transición del Servicio

Gestión de Cambios: Gestión de Problemas garantiza que los Workaround y soluciones
permanentes que requieran el cambio de un CI se hagan mediante un RFC. Gestión de
Cambios monitoriza el progreso de los cambios e informa a Gestión de Problemas.
Gestión de la Configuración y Activos del Servicio: Gestión de problemas usa el CMS para
identificar CIs incorrectos y determinar su impacto y posibles soluciones.
Gestión de Versiones y Despliegues: Despliega las soluciones de problemas a un entorno de
producción.
6.6.13.4. Mejora Continua del Servicio

Gestión del Nivel de Servicio: Los incidentes y problemas afectan a la calidad del servicio
proporcionado por SLM. Gestión de Problemas ayuda a mejorar la calidad del servicio y
ayuda informando sobre que componentes se deberían revisar en la SLAs.
6.6.14. Entradas
Detalles de Incidencias y workarounds
Detalles de configuración en CMS - KEDB
Workarounds definidos
6.6.15. Salidas
Una base de datos de Errores Conocidos (KEDB)
Solicitudes de Cambios (RFCs) a Gestión de Cambios
Documentación de Problemas actualizados incluidos workarounds y/o soluciones
Respuesta a la correspondencia con la Gestión de Incidencias
Información de su gestión a la Gerencia

6.6.16. Mejores prácticas

Escuchar a los especialistas, seguramente tienen razón.
Valorar sus ideas respecto al negocio.
No valorar solo la tecnología.
Separar la Gestión de Incidencias de la Gestión del Problema.
Asignar los tiempos necesarios para la Gestión del Problema.
Potenciar la contención y la prevención de las Incidencias.
Potenciar la coordinación y cooperación con Gestión de Incidencias.
Los registros tienen que ser de calidad.
La clasificación de Incidencias tienen que ser de calidad.
6.6.17. Principio de Pareto

El 80% del valor de cualquier actividad se genera con el 20% del esfuerzo.
Se utiliza para priorizar Actividades: Priorizar investigación de problemas, Seleccionar
personas con influencia para gestionar un cambio (El 80% de las personas permitan
que se produzca el cambio puede pasar a la siguiente fase; el otro 20% lo aceptará...
Concepto de eficiencia: La solución o negociación “es eficiente”, cuando un lado no
puede mejorar sin empeorar al otro .
Análisis de Pareto: Esta es una técnica para separar causas potencialmente importantes
de problemas más triviales.
6.6.18. Desafíos
Además de los costes de soporte y herramientas hay que considerar los costes de
personal de Gestión de Problemas
Mala conexión entre la Gestión de Incidencias y la del Problema. Si hay mala interfaz
entre los detalles de Incidencias y de Problemas y del KE, la Gestión de Incidencias no
estará al tanto de las soluciones temporales y definitivas y la Gestión de Problemas no
podrá evaluar el impacto de los Problemas y sus workarounds
Mala comunicación de los errores conocidos del área de desarrollo (bugs) a la de
producción. Debe haber intercambio de información eficiente entre sistemas de
almacenamiento (BBDD) y registro o debe de estar unificado
Falta de compromiso. Si todo anteriormente era informal, seguro que hay una
resistencia a la documentación y actualización de los registros en la CMS
Tiene que haber buena empatía entre Gestión de Incidencias y Gestión del Problema
6.6.19. Riesgos
Falta de personal de soporte
Falta de disciplina a la hora de ejecutar los procesos dentro de los equipos de soporte
Falta de experiencia en el análisis de tendencias
La dirección no se compromete de forma total
Mala calidad en el control de Incidencias y falta de históricos de datos
No se dedica el tiempo suficiente al CMS
Celos profesionales (A mi éste no viene a decirme que es lo que tengo que hacer)

6.6.20. Beneficios
Mejorar la calidad de los servicios de TI.
Mayor disponibilidad de los servicios a clientes y usuarios al eliminar Incidencias
repetitivas.
Gracias al análisis proactivo se evitan interrupciones y que las Incidencias se extiendan
sobre los sistemas.
Soluciones permanentes.
Mejor aprendizaje de toda la organización.
El ratio “a la primera” del servicio del Centro de Servicio al Usuario se mejora paso a
paso
6.6.21. Métricas
Número total de problemas registrados en el periodo
Número y porcentaje de problemas que requirieron más tiempo de solución
Número de problemas pendientes de resolución y SUS tendencias.
Número de problemas graves (pendientes, retrasados y cerrados)
Número de KEs agregados a La KEDB
Porcentaje de problemas resueltos y no resueltos dentro de los objetivos del SLA.
Porcentaje de revisiones correctas de problemas serios.
Porcentaje de exactitud de la KEDB a partir de las auditorías de la BBDD.


6.7. Gestión de Accesos

6.7.1. Objetivos
Proveer derechos a usuarios para acceder a un servicio o grupos de servicios y
aplicaciones
En algunas organizaciones también es conocido como Gestión de Derechos o
Identidades.
Es el proceso de conceder el derecho a los usuarios o grupos autorizados a usar un
servicio o grupo de servicios
Proceso que quien ejecuta las políticas de seguridad de Gestión de la Seguridad de la
Información y de Gestión de la Disponibilidad, y eso permite gestionar la
confidencialidad, integridad y disponibilidad (CIA) de los datos y de la propiedad
intelectual de la organización
6.7.2. Ámbito
Proceso que garantiza que se conceda a los usuarios el derecho de uso de un servicio,
pero no garantiza que este acceso esté disponible durante todo el tiempo acordado.
Esto lo proporcionará la Gestión de la Disponibilidad
Interactúa normalmente con RRHH
Proceso que se ejecuta a través de todas las funciones de Gestión de Aplicaciones y
Técnica. Sin embargo, probablemente habrá un único punto de control de
coordinación, normalmente en Gestión de Operaciones de TI o en el Centro de Servicio
al Usuario.
Puede iniciarse mediante una Petición de Servicio a través del Centro de Servicio al
Usuario.

La organización puede mantener de forma eficaz la confidencialidad de la información
mediante un riguroso acceso controlado a los servicios.
El riesgo de errores durante la entrada de datos o uso de servicios críticos por usuarios
no cualificados es más bajo.
El personal tiene un nivel de acceso más alineado con su trabajo.
Permite retirar rápidamente los derechos de acceso a un usuario si ello lo requiere el
gobierno empresarial o las leyes vigentes.
Los empleados tienen el nivel correcto de acceso para realizar sus funciones de forma
eficaz
La capacidad de auditar el uso de los servicios y de rastrear el abuso de los servicios
6.7.4. Disparadores
La Gestión de Accesos se inicia cuando un usuario solicita acceso a un servicio y puede tener su
origen.
Un RFC.
Una petición de servicio.
Una petición del RRHH.
Una petición de un responsable de un departamento dentro de la estructura
organizativa.


Accesos: Grado de la funcionalidad sobre datos que un usuario puede utilizar
Identidad: La información de distinción única de un individuo y que verifica su estado
Derechos: Configuración sobre el sistema que dan los administradores y Operadores de
Servidores (privilegios). También se incluyen los permisos sobre objetos.
Grupos de usuarios y Grupos de Servicios: Acceso a un conjunto de Servicios para un
conjunto de usuarios Y no acceso individual para Servicios separados.
Directory Services: Herramienta para manejar derechos, accesos y permisos sobre
objetos, tales como archivos, carpetas, impresoras y objetos del Active Directory.
Desarrollado por IBM para UNIX en 1970 y hoy es el estándar X-500
6.7.6. Actividades
Las Peticiones de acceso o solicitudes de denegación de acceso suelen venir de RRHH a la
contratación de personal. También los responsables departamentales pueden hacer peticiones.
Pueden venir de un RFC o de la ejecución de una opción o un guion autorizado
Actividades más importantes.
Verificación de las solicitudes de uso de un servicio desde dos puntos de vista
¿es quien dice ser?
¿tiene motivos válidos para usar el servicio?
Proporcionar derechos de uso de un servicio de TI no es iniciativa de la Gestión de
Accesos sino que se limita a ejecutar las políticas definidas en la Estrategia del Servicio
y en el Diseño del Servicio.
Monitorizar status de ID’s: Gestión de Accesos debe comprobar los roles de los
usuarios tales como bajas por ausencias o enfermedad, ascensos, despidos,
jubilaciones, etc.
Registro y monitorización de accesos para comprobar que el uso de los servicios y sus
derechos sobre el mismo se usan correctamente. Esto incluye la comprobación de toda
la Gestión Técnica y de Aplicaciones, asó como todos los procesos de Operación del
Servicio.
Revocación o limitación de derechos: No toma la decisión pero ejecuta las políticas de
los responsables de la organización.
6.7.7. Roles en la Gestión de Accesos
6.7.7.1. Gestión de Accesos

La Gestión de Accesos se puede solapar con la Gestión de la Seguridad. Es poco usual que
un Gestor de Accesos necesite ser designado; pero las políticas de seguridad, las prácticas y
los procedimientos se deben definir y comunicar a todos los grupos e individuos
6.7.7.2. Centro de Servicio al Usuario

Actúa como filtro inicial para la Gestor de Accesos. Comprobará su validez contra las tablas
de autoridad y si es correcta su correlación puede entonces conceder realmente los accesos
más simples para niveles inferiores; pero escalará a los grupos funcionales específicos
cualquier acceso a los sistemas críticos o a las áreas delicadas dentro de la infraestructura
de la organización

6.7.8. Métricas
Número de solicitudes de acceso (peticiones de servicio y solicitudes de cambio)
Número de concesiones de acceso por usuarios, departamentos o servicios.
Número de incidencias para revocar derechos de acceso
Número de incidencias por configuraciones incorrectas de acceso.
6.7.9. Entradas
Directivas de Seguridad (desde el Diseño del Servicio)
Requerimientos de Nivel de Servicio (SLR) para garantizar el acceso a los servicios
RFC autorizado para acceder a los servicios con sus derechos
Solicitudes autorizadas para otorgar o cancelar derechos de acceso
6.7.10. Salidas
Provisión de acceso a los servicios de TI, de acuerdo con las políticas de seguridad de la
información
Gestión de registros de acceso e histórico de acceso a los servicios
Comunicación sobre el acceso inadecuado o abuso de los servicios
6.7.11. Desafíos
La capacidad de verificar la identidad de un usuario (que la persona es quien dice ser)
La capacidad de verificar la identidad de la persona en un grupo
La capacidad de verificar que un usuario está autorizado para acceder a un servicio
específico
La capacidad para vincular múltiples derechos de acceso a un usuario individual
La capacidad de determinar el estado del usuario en cualquier momento (p. ej.,
determinar si son todavía empleados)
La capacidad de gestionar cambios para los requisitos de acceso de un usuario
La capacidad de restringir los derechos de acceso a usuarios sin autorización
Una base de datos de todos los usuarios y los derechos que se les puede haber
concedido
SLRs para garantizar el acceso a los servicios
6.7.12. Riesgos
La falta de tecnologías adecuadas de soporte para gestionar y controlar el acceso a los
servicios
Controlar el acceso de las fuentes de la "puerta trasera", tales como interfaces de
aplicaciones y los cambios de reglas de firewall para necesidades especiales
Gestionar y controlar el acceso a los servicios externos de terceros
La falta de apoyo a la gestión de las actividades de Gestión de Acceso y los controles
Asegurar que los niveles necesarios de acceso a los servicios y los controles de gestión
necesarios se proporcionan de forma que no obstaculicen la capacidad de los usuarios
para realizar sus actividades


La no posibilidad de verificar la identidad de un usuario
La no posibilidad de verificar la identidad de la persona o entidad que concede el
permiso.
La no posibilidad de conceder diversos derechos de acceso a un solo usuario.
Una BBDD con todos los usuarios y sus derechos.
Gestión de
Gestión de la Peticiones
Gestión de Nivel
Configuración
de Servicio
CMS
Gestión del
Catálogo
Gestión del Gestión de
Cambio Accesos
Gestión de la
Demanda
Gestión de
Seguridad
Gestión de la
Continuidad

6.8. Monitorización y Control de Operaciones

La actividad de monitorización y control está basado en un ciclo en bucle de chequeo,
informes y acciones de eventos y actividades de TI en la organización.

Monitorización: Observación de una situación durante un tiempo para detectar
cambios.
Informes: Análisis, producción y distribución de los resultados de la actividad que se
está monitorizando.
Control: Gestión del uso o comportamiento de un CI, sistema o servicio y requiere 3
condiciones.
Garantía que el comportamiento cumple un estándar definido.
Se debe definir, comprender y confirmar las condiciones que llevan a la acción.
La acción debe de estar definida, aprobada y adaptada para estas condiciones.
6.8.2. Actividades
Hay dos niveles:
6.8.2.1. Monitorización interna:

Se centra en actividades dentro de un equipo o departamento.
6.8.2.2. Monitorización externa:

Realiza el control de elementos y actividades que dependen de otros grupos, procesos o funciones
externalizados.
Hay dos tipos de ciclos de monitorización y control:
6.8.2.3. Sistema de ciclo abierto:

Para una actividad específica. Por ejemplo un backup se inicia en un momento determinado y
finalizará independientemente de otras condiciones.
6.8.2.4. Sistema de ciclo cerrado.

Monitorizan un entorno y responden a cambios en esos entornos. Por ejemplo si las transacciones
de red superan la capacidad de la misma, se puede desviar el tráfico por una red de reserva.
Cada proceso consta de tres actividades importantes y cada una tiene una entrada y una salida que
es la entrada de la siguiente actividad.
Monitorización
Comparación
Control.
6.8.3. Herramientas
La situación determinará el tipo de herramientas a utilizar.
Monitorización activa. Es la continua “interrogación” de un CI o sistema para determinar su estado.
Monitorización pasiva. Herramientas que consisten en la generación y transferencia de eventos a
un agente de monitorización.

Monitorización reactiva. Herramientas diseñadas para acometer una acción después de un tipo de
evento.
Monitorización proactiva: Identifican patrones de eventos que indican que un sistema o CI se
puede averiar.
Medición continua. Monitorizan en tiempo real un sistema para garantizar que cumple una norma
de rendimiento.
Monitorización basada en excepciones: No miden el rendimiento, detecta y comunica excepciones.
Rendimiento y salida: Hay que distinguir entre informe de rendimiento de un CI, sistema o
departamento e informes que indican que se han cumplido los objetivos.
Operaciones de TI realiza ambos tipos de monitorización, pero ITIL® focaliza en la monitorización
del rendimiento.
Norma
Control Comparación
Monitorización
Entrada Actividad Salida
6.8.4. Métricas
Las organizaciones tienen que contar con buenas técnicas de medición y tener en cuenta los
siguientes ítems.
Medición: Se refiere a las técnicas que evalúan, la dimensión o la capacidad de un CI
con respecto a un estándar.
Métricas: Se refiere a la evaluación periódica y cuantitativa de un proceso, sistema o
función. Esto es muy importante pues no solo especifica lo que se debe medir, sino
como hay que medirlo y que acciones hay que tomar en caso de una excepción o
normalidad.
Indicadores Clave de Rendimiento (KPI): Se refiere a un nivel específico y acordado de
rendimiento para medir la efectividad y eficiencia de una organización o proceso.

6.9. Funciones
Función Gestión Técnica

Función Centro de Servicio al Usuario
Función Gestión de Aplicaciones
Control de Operaciones de TI
Gestión de Instalaciones


6.10.Función Gestión Técnica

6.10.1. Actividades
Gestión de Mainframes
Gestión de Servidores y soporte
Gestión de Redes
Almacenamiento y Archivo
Gestión de Bases de Datos
Gestión de Servicio de Directorios
Soporte de Escritorios
Gestión de Middleware
Gestión de Internet
Gestión de Servidores Web
6.10.2. Roles en la Gestión Técnica

Gestión Técnica juega diferentes roles en la Gestión de Accesos a través del Ciclo de Vida de los
Servicios. Ejemplos:
Diseño del Servicio: Asegura controles sencillos y diseña medidas de control para
evitar abusos
Transición del Servicio: Prueba los controles diseñados.
Operación del Servicio: Configura la gestión de accesos para los sistemas dentro de su
área de control y se ocupa de incidentes y de problemas relacionados con los accesos
en toda la infraestructura de la organización
6.10.2.1. Gestión de Mainframes

Mantenimiento y soporte del sistema operativo del mainframe
Soporte de tercer nivel para cualquier incidencia o problema con el mainframe
Escritura de scripts de trabajo
Programación del sistema
Soporte para la interfaz con el hardware (H/W); organización del mantenimiento,
acuerdo de franjas de tiempo, identificación del fallo de H/W, colaboración con
ingeniería de H/W.
Provisión de información y asistencia a Gestión de la Capacidad
6.10.2.2. Gestión de Servidores y soporte

Soporte a los sistemas operativos
Gestión de licencias
Soporte de tercer nivel
Asesoramiento para el aprovisionamiento
Seguridad del sistema
Definición y gestión de servidores virtuales
Capacidad y Rendimiento
Mantenimiento continuo
Retirada del servicio activo y eliminación de equipos antiguos

6.10.2.3. Gestión de Redes

Gestión de Red también es responsable, a veces junto con Soporte al Puesto de
Trabajo, de conectividad remota como las funcionalidades de recepción y devolución
de llamadas, VPN para los tele trabajadores, trabajadores remotos y proveedores.
Algunos equipos o departamentos de Gestión de Red también son responsables de los
servicios de voz/telefonía, incluyendo la provisión y soporte de correos, líneas, ACD,
paquetes de software estadístico, etc., y de los sistemas de Voz sobre el Protocolo de
Internet (VolP) y de Monitorización Remota (RMon).
6.10.2.4. Almacenamiento y Archivo

Dispositivo de almacenamiento, como discos, controladores, cintas, etc.
Network Attached Storage (NAS), almacenamiento vinculado a una red y al que pueden
acceder varios clientes
Redes de Área de Almacenamiento (SAN) designadas para vincular dispositivos de
almacenamiento informático, como controladores de conjuntos de discos y librerías de
cinta. Además de los dispositivos de almacenamiento, un SAN también necesitará la
gestión de varios componentes de red, como hubs, cables, etc.
Direct Attached Storage (DAS), que es un dispositivo de almacenamiento vinculado
directamente a un servidor
6.10.2.5. Gestión de Bases de Datos

La Administración de Bases de Datos debe realizarse en colaboración con los equipos o
departamentos de Gestión de Aplicaciones y en algunas organizaciones, las funciones
pueden combinarse o vincularse bajo una única estructura de gestión
6.10.2.6. Gestión de Servicio de Directorios

Trabajar dentro de Diseño del Servicio y Transición del Servicio para asegurar que los
nuevos servicios sean accesibles y controlados durante su despliegue
Localizar recursos en una red
Realizar el seguimiento del estado de esos recursos y proporcionar la capacidad para
gestionarlos de forma remota
Gestionar los derechos de usuarios o grupos de usuarios para acceder a los recursos en
una red junto a Gestión de Accesos
Definir y mantener las convenciones de nomenclatura a utilizar para los recursos en
una red
Vincular diferentes Servicios de Directorio en toda la organización para formar un
Servicio de Directorio distribuido

6.10.2.7. Soporte de Puestos de Trabajo

Políticas y procedimientos para los puestos de trabajo, control de licencias, uso de
ordenadores portátiles o de sobremesa para fines personales, restricción de
movimientos de equipos USB, etc.
Diseño y acuerdo de imágenes para puestos de trabajo estándar
Mantenimiento del servicio a puestos de trabajo, el despliegue de versiones,
actualizaciones, parches y hotfixes
Diseño e implementación de las políticas de archivo e imágenes de puestos de trabajo
(incluyendo la política relacionada con cookies, favoritos, plantillas, datos personales,
etc.)
Soporte de tercer nivel para las incidencias relacionadas incluyendo las visitas al
puesto de trabajo
Soporte a problemas de conectividad (junto con Gestión de Red) para los tele
trabajadores, personal desplazado, etc.
Control de la configuración y auditoría de todo los equipos del puesto de trabajo
6.10.2.8. Gestión de Middleware

Proveer mecanismos de transferencia para los datos de diversas aplicaciones o fuentes
de datos
Enviar trabajo a otra aplicación o procedimiento para su procesamiento
Transmitir datos o información a otros sistemas, como por ejemplo suministrar datos
para su publicación en sitios web
Entregar módulos de software actualizados en entornos distribuidos
Cotejo y distribución de mensajes e instrucciones del sistema, como eventos y scripts
operativos que se deben ejecutar en dispositivos remotos
Configuración multidifusión con redes. Multidifusión es el suministro simultáneo de
información a un grupo de destinos utilizando la ruta de entrega más eficiente
Gestionar tamaños de colas
6.10.2.9. Gestión de Internet

Definir arquitecturas para Internet y los servicios web
Especificación de estándares para el desarrollo y gestión de aplicaciones basadas en la
web, contenido, sitios web y páginas web
Diseño, pruebas, implementación y mantenimiento de sitios web
La gestión web puede incluir edición del contenido a publicar en la web
Coordinación de los equipos de contenido web del negocio. El contenido puede residir
en aplicaciones o dispositivos de almacenamiento, lo que implica una relación con
Gestión de Aplicaciones y otros equipos de Gestión Técnica.
Coordinación y Gestión de Suministradores de ISP, hosts, monitorización de
suministradores externos u organizaciones de virtualización
Soporte de tercer nivel para las incidencias relacionadas con Internet o la web
Monitorización y gestión del rendimiento del sitio web
Pruebas de señal de red, simulación de la experiencia de usuario, benchmarking,
equilibrio de carga bajo demanda, virtualización
Disponibilidad del sitio web, capacidad de recuperación y seguridad

6.10.3. Actividades operacionales
Hay otros procesos que se ejecutan en Operación del Servicio; pero se dirigen desde otras
fases del Ciclo de Vida:
Gestión de Cambios
Gestión de la Configuración y Activos del Servicio
Gestión de Entregas y Despliegues
Gestión de Capacidad
Monitorización del Rendimiento
Gestión de la Demanda
Gestión de Disponibilidad
Gestión Financiera de los servicios de TI
Gestión del Conocimiento
Gestión de Continuidad del Servicio de TI
6.10.4. Mejora de actividades operacionales

Automatización de tareas manuales
Revisar las actividades improvisadas o procedimientos
Auditorías de Operaciones
Gestión de Capacidad
Usando la Gestión de Incidentes y Problemas
Comunicación
Educación y formación
6.10.5. Gestor Técnico
6.10.5.1. Juega dos roles

Guardián del conocimiento técnico y de la maestría: Se asegura que el conocimiento
requerido para diseñar, probar, manejar y mejorar los servicios está identificado,
desarrollado y que modelado
Proporciona recursos reales al ciclo de vida de la Gestión de Servicios: Se asegura que
los técnicos estén formados, entrenados y desarrollados eficazmente para diseñar,
construir, transicional, funcionar y mejorar la tecnología para entregar los servicios
6.10.5.2. Objetivos del Gestor Técnico

Ayudas en el planeamiento, la puesta en práctica y el mantenimiento de una infraestructura estable
a través de:
Una bien diseñada y resistente topología técnica y a un coste razonable
Uso de habilidades técnicas adecuadas para mantener la infraestructura técnica
Uso rápido de habilidades técnicas para diagnosticar y resolver cualquier fallo técnico

6.10.5.3. Actividades más importantes:

Solución de Problemas Técnicos.
Identificar conocimiento y experiencias requeridas.
Documentación del inventario de las habilidades y realización de Análisis de
Necesidades de Formación.
Lanzar programas de formación.
Contratación de recursos que no se puedan desarrollar internamente.
Investigación y desarrollo de soluciones para ampliar la Cartera de Servicios.
Implicación en la Gestión de la Disponibilidad y la Capacidad para diseñar
nuevos servicios.
Implicación en proyectos durante el diseño de Servicios y Transición de
Servicios


6.11.Gestión de Aplicaciones
Ciclo de vida de Gestión de Aplicaciones no es una alternativa al Ciclo de Vida de Gestión de
Servicios. Las aplicaciones son parte de los servicios y se gestionan como tales y son una
combinación ÚNICA de tecnología y funcionalidad por lo que se han de enfocar en cada fase del
Ciclo de Vida de la Gestión de Servicios.
NO es responsable de las herramientas y habilidades para manejar la Infraestructura
Se necesitan dos enfoques alternativos
Ciclo de Vida de Desarrollo del Servicio (SDLC): Enfoque sistemático para la resolución de
problemas.
Mantenimiento de aplicaciones. Examina globalmente todos los servicios para garantizar la
continuidad del proceso de gestión y mantenimiento de aplicaciones. Todas las aplicaciones deben
de estar en sintonía con los requisitos del cliente.
6.11.1. Ciclo de vida de Gestión de Aplicaciones
Requisitos
Optimizar Diseñar
Operar Crear
Desplegar
6.11.2. Objetivos
El Objetivo de Gestión de Aplicaciones consiste 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.
Es responsable de todas las aplicaciones durante su ciclo de vida
Una de las decisiones clave de este proceso es contribuir a la decisión de comprar o
desarrollar el software

6.11.3. Rol de los equipos en el Ciclo Vida de Gestión de Aplicaciones
Desarrollo de Requisitos Gestión de la

Aplicaciones Aplicación
Optimizar Diseñar
Gestión de
Servicios de TI,
Estrategia, Diseño,
Transición
y Mejora
Operar Crear y Probar
Desplegar
6.11.4. Herramientas CASE

Los entornos de desarrollo tienen sus propias herramientas e Ingeniería de Sistemas Asistida por
Ordenador (CASE) ya que ofrecen un medio para especificar requisitos, elaborar diagramas de
diseño o generar aplicaciones. Permiten almacenar y gestionar los elementos creados

6.12.Función Gestión de Operaciones de TI

El Gestor de Operaciones debe asegurarse de que los procedimientos de las operaciones estándar
se realicen siempre y en su totalidad sin dejar laguna posible. También compaginará los datos de
acceso para propósitos de informes (incluyendo los accesos y las peticiones rechazadas) de toda la
infraestructura de la organización
Operaciones de TI ayuda a los profesionales a lograr el equilibrio entre la empresa para cumplir sus
objetivos y el funcionamiento eficiente de los componentes de los servicios de soporte y centrarse
en gestionar de forma efectiva los requerimientos de los usuarios y clientes en el día a día, a la vez
que mantener una gestión proactiva.
Debe proporcionar y gestionar servicios TI a los usuarios y clientes del negocio cumpliendo los SLAs.
Administrar la tecnología que se utiliza para ofrecer servicios y apoyo.
Realizar, gestionar y controlar día a día el funcionamiento de los procesos (uso de Service Design y
de Service Transition).
Habilitar la Mejora Continua de Servicio mediante el seguimiento de la ejecución, evaluar las cifras
y recopilar datos.
6.12.1. Objetivos
Mantener el Statu Quo para alcanzar estabilidad
Para escudriñar y mejorar regularmente los servicios
Usar rápidamente las habilidades operacionales para diagnosticar y resolver fallos
6.12.2. Ámbito
En Operación de TI es donde los planes se convierten en acciones
Se hace foco en las actividades diarias o a corto plazo, se debe tener en cuenta que
estas actividades se realizarán y repetirán durante un periodo relativamente amplio
Estas actividades las realiza personal técnico especializado, que debe 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 el nivel correcto de calidad, garantizarán el éxito de la operación
(automatización de los servicios)
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
El valor generado debe superar el coste de la inversión y todos los demás gastos
generales organizativos
6.12.3. Actividades
Realizar las actividades del día a día y los procedimientos requeridos:
Para manejar y mantener la infraestructura
Para entregar los servicios de soporte en los niveles convenidos.
Gestión de Consola / Puente de Operaciones
Programación de Tareas
Respaldo y Restauración
Mejora de actividades Operacionales
Gestión de Facilidades y Centros de Computación

6.12.3.1. Control de Operaciones de TI

Puente de Operaciones. Define la observación y la supervisión centralizada para
ejercitar actividades de supervisión y de control. Combina varias y diferentes
actividades como gestión de consolas, proveer personal para la gestión de eventos. En
algunas organizaciones el CSU forma parte del Puente de Operaciones.
Programación de trabajos. Gestión de los tratamientos por lotes y de las rutinas
De copias de seguridad y restauración. Para equipos directivos, de los usuarios
técnicos y de todos los datos que estén en uso
Gestión de impresoras y de las colas. Distribución de toda la impresión centralizada o
salida electrónica
Funcionamiento de las actividades de mantenimiento. Para equipos directivos, de los
usuarios y de todos los que estén en uso
6.12.3.2. Gestión de Instalaciones:

Gestionar el entorno físico de TI dentro de la organización o externalizado
Coordinar proyectos de consolidación a gran escala y entornos Datacenter
La estabilidad de la infraestructura y su consistencia es su ocupación principal
Gestiona y controla los contratos de facilidades de terceros para Datacenters
Control de Temperatura en CPDs, humedad, humos, etc.
Mantenimiento Generadores de energía
6.12.4. Funciones – Solapamiento en la Organización

Las funciones ilustradas en el siguiente gráfico son necesarias para manejar el estado del entorno de
TI en la organización. También puede estar descentralizado por razones geográficas
Función Gestión Función

Centro de
Servicio de Operaciones de TI Gestión de
Función Gestión
al Usuario Técnica Aplicaciones
2
Mainframe
Control Operaciones de TI Apps. Finanzas
Servidores
Puente de Operaciones
Redes Gestión de Consola
Apps. RRHH
Planificación de Trabajos
Almacenamiento Copias y Restauración
y Archivo
Impresoras y colas
Apps. Negocio
Databases
Servicio de
directorios Gestión de
Instalaciones
Puestos de
Trabajo Hardware de Data Centers
Equipos de energía y A.C.
Middleware Consolidación de
Infraestructuras.
Internet/Web Instalaciones de Recuperación

Por razones geográficas
TI TI TI TI
América - Miami Europa - Londres África – El Cairo Asia - Tokio
Operaciones Operaciones Operaciones Operaciones

Mainframe Mainframe Mainframe Mainframe
Operaciones Operaciones
Servidores Apps. Negocio Bases de Apps. RRHH
Datos
Operaciones Redes Operaciones

Almacenamiento
Operaciones Apps. Negocio
Middlware
y Archivo
Operaciones
Puestos de Trabajo Operaciones
Operaciones Internet/Web
Servicio de Apps.
directorios RRHH
Apps. Negocio
Operaciones
Operaciones Servidores
Servidores
Operaciones Operaciones
Internet/Web Middlware
Por actividades
Gestor de Estrategia
de TI y Planificación
Investigación
Arquitectura Planificación Cartera de
de Nueva
y Estándares de Capacidad Servicios
Tecnología
Aplicaciones Mainframe
Infraestructura Servidores
Basado en la
ejecución de un conjunto
de actividades
Almacenamiento
Red
Basado en
Web


6.13. Tecnología y Arquitectura

6.13.1. Requerimientos para integrar la Tecnología en la Gestión de
Servicios
En el mercado existes muchas y diversas herramientas que se pueden usar para ayudarnos en el
diseño de las soluciones de servicio y sus componentes relacionados para:
Diseño de Hardware
Diseño de Software
Diseño de Entornos
Diseño de Procesos
Diseño de Datos
Las herramientas y técnicas se usan para:
Asegurar los estándares y las leyes gubernamentales de cada país
Ofrecer prototipos, modelados y simulación de instalaciones
Establecer escenarios con la pregunta de ¿Qué pasa si . . .?
Validar diseños antes de ponerlos en producción
Chequear interfaces y procesos interrelacionados y así.
6.13.2. Tecnologías propias o de terceros
6.13.2.1. Auto Ayuda

Muchas organizaciones desarrollan software de auto ayuda como pueden ser páginas con menús de
guía con interfaces a otros programas o servidores para la resolución de incidencias o de
información
6.13.2.2. Flujos de Trabajo y motores de procesos

Los Flujos de Trabajo o motores de control de procesos son necesarios para la pre-definición de
Incidentes, Gestión de Peticiones, Problemas, Cambios y así.
Esto permite a los responsables de sus actividades, rutas de escalado, tiempos de resolución de
Incidentes o Problemas, alertas y si está predefinido pues el disparo de alertas para gestión
automatizada.
6.13.2.3. CMS Integrada

El CMS debería de estar integrada y deberían de confluir en ella todas las CMDB.
Toda la información de la infraestructura, componentes, servicios, clientes, suministradores, etc. y
todo aquello que la organización quiere controlar debe de formar parte del CMS.
6.13.2.4. Descubrimiento / Despliegue / Tecnología Licenciada

Las herramientas de Descubrimiento de hardware y software son necesarias para verificar los datos
del CMS y ayudar en la gestión de Licencias, es decir descubrir licencias de software obsoletas
derrochando capital y descubrir software sin licenciar con lo que ello supone de pérdida de imagen,
sanciones, etc.

6.13.3. Automatización de Servicios

La automatización puede tener, en particular, un gran impacto en el funcionamiento de los activos
del servicio tales como gestión, organización, personas, procesos, conocimiento e información. Los
usos solo son medios de automatización; pero su funcionamiento puede también ser mejorado
donde necesitan ser compartidos para muchos usuarios y procesos.
Los avances en inteligencia artificial, el aprendizaje en máquinas y tecnologías de última generación
han aumentado las capacidades de las personas basadas en programas para manejar una variedad
de tareas y de interacciones. La automatización es útil para mejorar la utilidad y la garantía de
servicios. Puede ofrecer ventajas en muchas áreas oportunas incluyendo las siguientes:
La capacidad de los recursos automatizados se puede ajustar más fácilmente para responder a las
variaciones de la demanda.
Los recursos automatizados pueden manejar capacidad con pocas restricciones en los momentos
requeridos para acceder a los servicios en épocas estacionales, pueden por lo tanto ser utilizados
para servir demanda a través de zonas horarias durante los periodos acordados.
La automatización de servicios y procesos tienen que ser simples y bien entendidos.
Los sistemas automatizados presentan una buena base para medir y mejorar procesos del servicio
llevando a cabo la medición de forma constante de los factores de recursos humanos. Inversamente,
pueden ser utilizados para medir el impacto durante los picos de servicio y mantener la calidad y los
costes debido a los niveles de variación de conocimiento, de habilidades y de experiencia de los
recursos humanos.
Muchos problemas de la optimización tales como: Previsión, enrutamiento y asignación de recursos
requieren el poder de computación que está más allá de la capacidad de los humanos.
La automatización es el medio para capturar el conocimiento requerido para un proceso del servicio.
El conocimiento, codificado, es relativamente fácil de distribuir a través de la organización de una
manera constante y segura. Reduce la depreciación del conocimiento cuando hay mucha rotación
del personal dentro de la organización o se van definitivamente a otra
6.13.4. Desafíos en Operación del Servicio

Hay un número de factores para los cuales las organizaciones necesitan planear durante la
preparación, despliegue y puesta en práctica de las aplicaciones de soporte de ITSM. Éstos incluyen
el siguiente.
Falta de implicación con el personal de desarrollo y de proyectos.
Tradicionalmente, siempre ha habido una separación entre el personal de Operación del Servicio y el
personal implicado en el desarrollo de nuevas aplicaciones o en la ejecución de proyectos que
eventualmente entregarán nuevas funcionalidades al entorno de producción
Justificación de los fondos:
En muchas ocasiones es difícil justificar el gasto en el área de Operación del Servicio debido a que el
dinero gastado en esta área con frecuencia se asocia con 'costes de la infraestructura', sin nada
nuevo que ofrecer a la inversión

Desafíos para los Gestores de Operación del Servicio

No existen soluciones fáciles para estos desafíos, principalmente porque son subproductos de la
cultura de la organización y de las decisiones tomadas durante el proceso de creación de la
estructura organizativa.
El propósito de involucrarse en el Diseño y Transición del Servicio es garantizar que los Gestores de
Operación del Servicio sean conscientes de los desafíos a los que se enfrentan y puedan crear un
plan para abordarlos.
6.13.5. Factores Críticos de Éxito en Operaciones de Servicio

Soporte de gestión
Soporte del negocio
Líderes
Dotación de personal y retención
Formación en Gestión de Servicios
Herramientas adecuadas
Validez de las pruebas
Medición y generación de informes
6.13.6. Riesgos en Operaciones de Servicio

Pérdida del Servicio
Riesgos para el éxito de Operación del Servicio
Financiación y recursos inadecuados
Pérdida de la oportunidad
Pérdida de personal clave
Resistencia al cambio
Falta de soporte de gestión
Diseño inicial erróneo
Diferencias con las expectativas del cliente


6.14.Centro de Servicio al Usuario

El Help Desk (HD) o Centro de Soporte se dedicaba al proceso de incidentes en tanto que
el Service Desk (SD) o Centro de Servicio al Usuario cubre un rango de actividades mucho
más amplio.
En algunas organizaciones nombran al Help Desk como CAU o Centro de Atención al
Usuario. El Help desk y el service desk son DOS centros distintos
La mayoría de las organizaciones consideran al CSU como el mejor recurso para la primera
línea de soporte a problemas de TI por lo siguiente.
Mejor servicio al cliente, mejor percepción del servicio por el cliente y mayor índice de
satisfacción.
Mayor accesibilidad por ser el UNICO punto de contacto, comunicación e información.
Mejor resolución y más rápida de peticiones de los clientes y usuarios.
Mejor cooperación y comunicación.
Menor impacto negativo sobre el negocio.
Mejor gestión y control de la infraestructura
Mejor uso de recursos de soporte de TI.
Aumento de la productividad del personal.
Mejor información de gestión para facilitar la toma de decisiones.
6.14.2. Objetivos
Actuando como una función estratégica que reduzca los costes de propiedad asociados
al soporte de la infraestructura de TI
Apoyando a la integración y Gestión del Cambio
Apoyando a la optimización de las inversiones y a la gestión de los servicios de soporte
a los clientes
Ayudar en la identificación de oportunidades de negocio
Facilitar la restauración del servicio normal con impacto mínimo y según lo acordado
en el SLA y en los OLAs.
No solo “resolver este asunto” sino “inmediatamente restaurar el servicio al usuario.
Al Centro de Servicio al Usuario nunca se le requiere para peticiones de servicio, se
llama a Gestión de Peticiones

Incidentes. Todas las llamadas excepto los cambios estándar.
Todas las llamadas al Centro de Servicio al Usuario deben ser registradas como
Incidencias con el objeto de que se contabilicen como actividad del Centro de Servicio
al Usuario
Informes de errores. Fallos verdaderos y quejas sobre el servicio.
Los cambios no estandarizados que son manejados como RFC seguirán el
procedimiento normalizado de la Gestión de Cambios.

6.14.4. Actividades
Es el centro neurálgico de todos los procesos de soporte al servicio.
Recepción, registro, priorización y localización de llamadas.
Seguimiento de todas las llamadas incluidas las “peticiones de Servicio”.
Informar a los usuarios de status y progresos.
Soporte de primera línea en colaboración con Gestión de Incidentes.
Puede usar peldaños jerárquicos para escalar incidentes a otros grupos de 2ª, 3ª línea o
externos.
Cierre de las incidencias
Identificar necesidades de educación, nuevas oportunidades de negocio con usuarios y
clientes.
Comunicación de cambios planificados.
Actualización si así está acordado del CMS.
6.14.5. Puntos a tener en cuenta

La propiedad de las incidencias será siempre del CSU (SD), independientemente del
estado en el cual se encuentren. El CSU (SD) es responsable de sus seguimientos,
progresos, mantener informado al usuario y en última instancia, de su cierre.
Puede haber varias incidencias encoladas con el mismo nivel de prioridad, por lo que
inicialmente será el trabajo de CSU (SD) o Gestión de Incidencias, junto a los gestores
de diversos grupos de soporte, decidir el orden de prioridad en función de los procesos
de negocio.
Habrá ocasiones en que las incidencias se repitan a pesar de haber sido oficialmente
cerradas. Por ello es conveniente tener predefinidas reglas sobre la reapertura de
Incidencias
Deben de existir buenos SLAs y OLAs y UCs para garantizar que el soporte del Centro de
Servicio al Usuario tenga un enfoque claro.
6.14.6. Beneficios
Mejor Servicio al Cliente.
Mayor índice de satisfacción del Cliente.
Mejor percepción del servicio por parte del Cliente.
Mayor accesibilidad al ser el único punto de contacto.
Resolución más rápida y mejor de las peticiones de usuarios.
Mejor cooperación y comunicación.
Menor impacto negativo sobre el negocio.
Mejor uso de la infraestructura de TI.
Mejor gestión y control de la infraestructura.
Descubrimiento de nuevos mercados.
Mejor información de gestión para facilitar la toma de decisiones sobre soporte.

6.14.7. Desafíos y Riesgos

La dirección pasa de los compromisos
Puede que los grupos de soporte utilicen distintas herramientas
Las herramientas de soporte tienen limitaciones
No se reconoce el trabajo del personal de CSU (SD)
El personal de soporte de TI está desmotivado
La función de CSU (SD) no tiene la propiedad CLARA
Las Responsabilidades y los Roles no están bien diferenciados
Las métricas son ambiguas y los informes mal-intencionados y falseados
Mal feeling entre CSU (SD) y los demás Procesos
Los usuarios “pasan” del “canuto” establecido
Pobre comunicación entre TODOS LOS PROCESOS y el Centro de Servicio al Usuario
6.14.8. Estructura organizativa
Según el tipo y tamaño de la organización el CSU puede estar organizado de diferentes maneras,
como por ejemplo:
Centro de Servicio al Usuario Local.
Centro de Servicio al Usuario centralizado.
Centro de Servicio al Usuario virtual.
Servicio 24 horas.
Centros de servicios especializados.
EL CENTRO DE ASISTENCIA AL USUARIO (CAU) NUNCA FORMA PARTE DE LA ESTRUCTURA

ORGANIZATIVA DEL CSU.
6.14.9. Tecnologías más usuales
Solicitud Solicitud Señales de

Solicitud Solicitud
e_mail Internet Hardware y
Mensajes voz telefónica por Fax
Intranet Aplicaciones
Centro de
REFERIR A. . . Informar a la Gerencia
Servicio al Usuario
Apoyo a Apoyo Ventas Apoyo Apoyo a

los servicios a los y a los los servicios
externos productos Marketing Contratos internos

6.14.10. Tipos de Mesa

Centro Telefónico (Call Center):
Gestiona grandes volúmenes de llamadas de transacciones telefónicas y las refiere a otras partes de
la Organización.
Centro de Atención al Usuario de TI (CAU) (Help Desk):
Para gestionar, coordinar y resolver Incidentes lo antes posible. De forma remota o con
desplazamiento. No forma parte de la estructura organizativa de Centro de Servicio al Usuario
Centro de Servicio al Usuario (Service Desk):
Permite que procesos de negocio se integren a la infraestructura de Gestión de Servicio. No sólo
maneja Incidentes, problemas y quejas, sino también proporciona una interfaz para otras
actividades. Es un Vendedor “GRANDE”.
6.14.11. Centro de Servicio al Usuario Local.
Establece procesos Usuario Usuario Usuario

comunes a través de A B C
todas las localidades y con
procedimientos comunes.
Comparte las habilidades

y conocimientos con otros Centro de Servicio
Centro de Servicio al Usuario. al Usuario
Asegura la
Compatibilidad
Apoyo Apoyo Apoyo a Apoyo Apoyo
entre la al a la Sistemas y de a la
infraestructura Desktop Aplicación Operaciones Terceros Red
de Hardware,
Software y Red
Usa idénticos procesos internos de autorización, el mismo impacto,

severidad, prioridad y códigos de status entre las localidades

6.14.12. Centro de Servicio al Usuario centralizado.
Reducción de
costes operacionales.
Clientes Clientes Clientes
Centro A Centro B Centro C
Visión global de Gestión
consolidada.
Mejor uso de los
recursos existentes.
Centro de Servicio
al Usuario Soporte Primera Línea
CENTRALIZADO
Soporte Segunda Línea KB
Apoyo Apoyo Apoyo Apoyo Apoyo

a Sistemas al a la de a la
CMDB
y Operaciones Desktop Aplicación Terceros Red
6.14.13. Centro de Servicio al Usuario virtual.
Centro de
Servicio al
Usuario
SIGUE
SIGUE AL
AL SOL
SOL
Virtual Idioma.
Procedimientos exactos.
Centro de Servicio Dependiente de la tecnología.
al Usuario en
Toronto Conocimiento centralizado.
CMS
CMS
KB
Centro de Servicio
al Usuario en
Barcelona
Cliente Cliente Centro de Servicio

al Usuario en Sidney
Cuenca Alicante
Centro de
Servicio al
Usuarios a distancia Usuarios Locales Usuario de
Terceros y
Proveedores

6.14.14. El Centro de Servicio al Usuario virtual

Cuando los usuarios están en distintas ubicaciones geográficas repartidos por el mundo el uso de las
nuevas tecnologías basadas en Internet permite crear la impresión de un Centro de Servicio al
Usuario Centralizado.
Esto permite que un usuario en Europa por la noche solicite ayuda y asistencia técnica y le
contestarán desde Norteamérica porque allí el CSU está en sus horas diurnas de trabajo.
El CSU de Norteamérica se hace cargo de los eventos pendientes y suyos propios y al terminar el día
su responsabilidad se transfiere al CSU de Europa.
Quizás el único inconveniente estaría en el manejo de una lengua común.
6.14.15. Personal del Centro de Servicio al Usuario

Contacto con los proveedores de mantenimiento, reemplazo de impresoras,
periféricos, equipos incluso de telecomunicaciones. Este tipo de mantenimiento puede
incluir gestionar los incidentes en sentido puro o en términos de cambio y RFC.
Realizar copias de respaldo y restauración, conexiones LAN, administrar los espacios de
discos en servidores, habilitar cuentas de usuario y restablecimiento de contraseñas.
Manejar herramientas de monitorización de routers, switches, servidores, aplicaciones,
BBDD y más.
Instalación de aplicaciones ofimáticas autorizados por La Gestión de Versiones y
Despliegues.
Muchas organizaciones ven útil elegir entre sus usuarios a un número de SUPER
USUARIOS, que actúan como personas de contacto con la organización de TI en general
y como CSU en general.
Es muy importante que el personal del CSU haya tenido y mantenga la suficiente
formación de las tecnologías a usar para ayuda y soporte, así como de las aplicaciones
de TI y del negocio del cliente.
6.14.16. Consideraciones Finales

La imagen de marca de una empresa puede depender en gran medida de la calidad del
servicio prestado por su Centro de Servicio al Usuario.
"El éxito de su Centro de Servicio al Usuario es el éxito de su EMPRESA" y depende de
las personas que lo integren. Es por tanto imprescindible establecer estrictos
protocolos de selección y formación de su personal integrante y deben de:
Compartir la filosofía de atención al cliente de la organización.
Comunicarse con corrección y buena educación y de una manera que el cliente pueda
comprender. Jamás utilice jerga cheli ni sea cursi.
Conocer en profundidad los servicios y productos ofrecidos.
Comprender las necesidades de los clientes y redirigirlos, si fuera necesario, a los
expertos en cuestión.
Controlar todas las herramientas tecnológicas a su disposición para ofrecer un servicio
de alta calidad.
También es imprescindible el compromiso de la dirección con un seguimiento de cerca
de los servicios prestados, su rendimiento y un continuo apoyo al equipo en la siempre
difícil tarea del trato directo con los clientes.
No ejemplarice durante los cuellos de botella.
Sólo tenemos una oportunidad de ofrecer una buena primera impresión.

6.14.17. Métricas o KPIs

Las métricas deben de ser realistas y elegidas con cuidado.
Un mal diseño puede resultar que los clientes estén satisfechos pero sus evaluaciones nos
transmitan desánimo y decepción, y ello por no ser ajustadas al objetivo que nos hemos marcado en
la Estrategia del Servicio.
De otra manera, los clientes no están satisfechos y caemos en la falsa impresión que hemos
alcanzado los objetivos.
Además de las estadísticas de eventos, las métricas incluirían aparte de las que considere la
organización y a modo de ejemplo:
Tiempo de procesamiento en la primera línea de soporte.
Porcentaje de eventos resueltos en primera línea sin necesidad de escalarlos.
Tiempo medio de resolución de incidencias.
Tiempo medio de escalado si fue necesario.
Coste medio de procesamientos de incidencias.
Porcentaje de peticiones de servicio de clientes y usuarios.
Porcentaje de peticiones que se ejecutan según lo acordado en los SLAs, OLAs y UCs.
Tiempo medio necesario para evaluar y cerrar una incidencia resuelta.
6.14.18. Externalización del Centro de Servicio al usuario

La decisión de subcontratar o externalizar el CSU es un asunto que la alta dirección debe discutir en
la Estrategia del Servicio y delicadamente diseñado en Diseño del Servicio, ya que se corren los
riesgos:
Sustitución. El vendedor puede reemplazar el origen de la organización.
Disrupción: El vendedor puede dañar su reputación.
Distinción: Puede desarrollar una dependencia del vendedor.


Mejora Continua de los Servicios CSI .7

7.1. Continual Service Improvement in the Service Lifecycle
7.1.1. Conceptos genéricos y definiciones
Continuous:
La organización está involucrada en una actividad sin interrupción. El esfuerzo es constante y al
mismo nivel. (P.ej: Le damos servicio de correo las 24 horas diarias de forma continua)
Continual:
Significa una sucesión de actividades estrechamente colocadas creando secuencias de actividades
para mejorar. P.ej:(Chicken Fast Bar = Creemos en nuestra calidad pero si ve algo que pueda
mejorarlo, por favor díganoslo)
7.1.2. Modelo de Madurez

La Fundación Europea para la Gestión de Calidad se creó en 1988 por 14 compañías europeas con
el apoyo de la Comisión Europea.
El objetivo de la EFQM es promover la Gestión de la Calidad Total.
El “Modelo de Excelencia del Negocio” de EFQM es conocido como el modelo EFQM.
Más de 1.200 empresas y organizaciones de investigación se han unido a EFQM.
El Ciclo de Calidad de Deming está incorporado en el modelo EFQM.
La estrategia y las políticas se toman basándose en los resultados de todas las áreas. Estas medidas
sirven para apoyar la planificación y conseguir los resultados deseados e identifica 9 áreas
1 2 5 6 Resultados
9
Personas De las
Personas
7 Resultados Resultados
Liderazgo
3 Políticas y
Procesos del Clave de
Estrategia
Cliente
Rendimiento
Socios y Resultados
4 Recursos 8 de la
Sociedad
ORGANIZACIÓN RESULTADOS

7.1.3. Propósito
El propósito principal de CSI es alinear y realinear continuamente los servicios de TI con
las necesidades cambiantes del negocio, identificando e implementando mejoras en los
servicios de TI, que soportan los procesos de negocio. Estas actividades de mejora
sustentan el enfoque del ciclo de vida a través de la Estrategia del Servicio, Diseño del
Servicio, la Transición del Servicio y Operación del Servicio
7.1.4. Objetivos
Revisar, analizar y hacer recomendaciones sobre las oportunidades de mejora en cada
fase del ciclo de vida: Estrategia del Servicio, Diseño del Servicio, Transición del Servicio
y Operación del Servicio
Revisar y analizar los Niveles de Servicio alcanzados
Identificar e implementar actividades orientadas a mejorar la calidad del servicio de TI,
y mejorar la eficiencia y eficacia de los procesos de ITSM que lo hacen posible
Mejorar la rentabilidad de la provisión de servicios de TI; pero sin sacrificar la
satisfacción al cliente
Garantizar que se utilicen los métodos de gestión de la calidad adecuados para
soportar las actividades de mejora continua
7.1.5. Ámbito
La salud global de ITSM como una disciplina
La continua alineación de la Cartera 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 del Ciclo de Vida de los Servicio
7.1.6. Valor
Capacidad de organización creciente
Integración entre las personas y los procesos
La reducción de la redundancia incrementa el rendimiento de todo el negocio
Reduce al mínimo las oportunidades perdidas
Asegura la conformidad reguladora con los organismos gubernamentales e
instituciones para reducir al mínimo los costes y reducir los riesgos
Capacidad de reaccionar ante cambios rápidos en el negocio

7.1.7. Meta
Considere las frases siguientes sobre medidas y su control

Si no lo mides, no puedes manejarlo.
Si no lo manejas, no puedes Controlarlo.
Para Controlarlo necesitamos las Métricas (KPIs).
Controlar es Medir
Se puede medir la tecnología y cada uno de sus CIs y también los Servicios y los procesos.
CSI mide y monitoriza haciendo foco en lo siguiente:
Conformidad del proceso: ¿La organización usa las nuevas herramientas y sigue los procesos
de Gestión de Servicios?
Calidad: ¿Consiguen sus objetivos las distintas actividades del proceso?
Rendimiento: ¿Hasta dónde son eficaces los procesos?
Valor de un proceso para el negocio: ¿Crea el proceso alguna diferencia y qué opinión tiene
el cliente sobre el proceso?
Ajustar continuamente, y volver a alinear los servicios de TI a los cambios en las necesidades
de las empresas, mediante la identificación y ejecución de mejoras en los servicios de TI, que
soportan los procesos de negocio.
CSI trata de buscar las formas de mejorar:
Eficacia
Eficiencia
Si los procesos de ITSM no son implementados, gestionados y soportados con objetivos
claramente definidos, los objetivos y las mediciones pertinentes se verán afectados en la
empresa. Dependiendo de la criticidad de un servicio específico de TI para el negocio, la
organización podría perder horas productivas, experimentar costes más elevados, pérdida
de reputación o quizás incluso un fracaso empresarial
Revisar y analizar los niveles de servicio y logro de resultados.
Identificar y aplicar las distintas actividades de TI para mejorar la calidad del servicio y
mejorar la eficiencia y la efectividad de los procesos que permitan ITSM
Mejorar la relación costo-eficacia de la prestación de Servicios de TI sin sacrificar la
satisfacción del cliente
Asegurar que los métodos que se aplican para la gestión de calidad son usados y
soportados para la continua mejora de las actividades
7.1.8. Actividades de CSI

Verificar:
Verificar los resultados de los procesos
Examinar el grado de satisfacción del cliente
Evaluar el grado de madurez de los procesos
Comprobar que el personal sigue las directrices internas
Analizar los datos y compararlos con los objetivos definidos en la SLA

Informar:
Proponer mejoras para todas las Fases del Ciclo de Vida
Tener en cuenta la importancia de los objetivos establecidos
Mejorar:
Introducir actividades que aumenten la calidad, la efectividad y la eficacia y
satisfacción del cliente
Aplicar métodos adecuados de Gestión de Calidad en las actividades de mejora
7.1.9. El Modelo SMART

Singulares, Medibles, Adecuados, Realistas y ligados al Tiempo.
Política de la Organización: Combinación de decisiones y medidas para definir y
conseguir los objetivos.
Planificación: Implementación de políticas en forma de actividades específicas.
Acción: Realización de las actividades.
Tareas: Acciones asignadas al personal o cedidas a externos.
Cada paso se tiene que medir para saber si nos movemos en la dirección objetivo o hay
que tomar medidas correctivas. Para ello usaremos métodos como Cuadro de Mandos
Integral para definir Factores Críticos de Éxito y para medirlos utilizaremos los
Indicadores Claves de Rendimiento y si es necesario se subdividen en Indicadores de
Rendimiento.
Singulares: Al establecer los objetivos se debe asegurar que cada uno de ellos contiene
una acción determinada. ¿Por qué? Pues porque un objetivo genérico, debe traducirse
en varias acciones singulares que especifiquen como alcanzar ese objetivo.
Mensurables: ¿Cuánto tiempo tardarías en recorrer la galaxia? No puedes
responder…Un objetivo que no puede medirse no sirve, pues no contribuye de una
forma cuantificable a alcanzar nuestras metas y no podemos confirmar si se ha logrado
o no.
Alcanzables: ¿Cuánto tiempo tardarías en recorrer la galaxia? Plantearse objetivos
inalcanzables no contribuye a nada, solo contribuye al escepticismo, ya que la función
de un objetivo es la de posibilitar una meta, no la de obstruirla.
Realistas: ¿Quiero ser el hombre más rico del mundo en una semana?… Ser irrealista al
implantar un objetivo nos desmotivará e impedirá que continuemos peleando por
nuestros objetivos. Un objetivo debe motivar, debe empujarnos hacia su logro, debe
retarnos en lo difícil y debe obligarnos a pelear hasta el final, plantear un objetivo irreal
no lo consigue.
Tiempo: ¿Algún día comenzaré una empresa?…algún día… Trabajar contra plazos es la
única forma de romper la inmovilidad de un objetivo eterno. Si un objetivo no tiene
plazos marcados entonces es un objetivo abierto y un objetivo abierto es un objetivo
eterno

7.1.10. Los Seis Pasos del Impulso
Visión, misión,
¿Cuál es
metas y objetivos
la visión?
de negocio
¿Dónde Evaluaciones de
estamos Líneas de
ahora? referencias
¿Cómo ¿Dónde
mantenemos Objetivos
queremos
medibles
el impulso? estar?
Mejora del
¿Cómo
servicio y del
Llegamos ahí?
proceso
¿Hemos Medidas y
llegado? métricas
Definir la visión: TI recibe información sobre los objetivos de la empresa y junto con el
negocio, define una visión que combine la estrategia de TI con la del negocio
Registrar la situación existente: Debe registrarse el punto de partida (Línea de
Referencia =BL) del cliente, la organización, las personas, el proceso y la tecnología
Determinar objetivos medibles: Partiendo de la visión junto con el cliente, se definen
prioridades. ¿Qué es lo primero que hay que mejorar, qué alcance debe tener la
mejora y cuando debe de estar terminada?
Planificar: Se prepara el Plan de Mejora del Servicio (SIP) con todos los detalles que
incluyan las acciones para llegar a la situación deseada
Verificar: Se mide para verificar que se han cumplido los objetivos y comprobar que se
siguen los procesos
Consolidar: Se integran los cambios con el fin de mantenerlos
7.1.11. CSI y el Ciclo de Vida del Servicio

Más abajo se muestra la interacción que debería establecerse entre cada fase del ciclo
de vida. Una organización de TI no tiene que esperar hasta que un servicio o proceso
de gestión del servicio sea transferido al área de operaciones para comenzar a
identificar las oportunidades de mejora.
Cada fase del ciclo de vida proporcionará un resultado para la siguiente fase del ciclo
de vida. Este mismo concepto se aplica a CSI.

Estrategias del
Servicio
Estrategias y Realimentación
Políticas lecciones aprendidas Realimentación
para la mejora lecciones aprendidas
para la mejora
Diseño del
Servicio
Salida Planes para crear y
modificar servicios y Realimentación
procesos de gestión lecciones aprendidas
para la mejora
del servicio
Realimentación
lecciones aprendidas
Transición del
para la mejora
Servicio
Salida Gestionar la transición a
producción de un
servicio nuevo o Realimentación
cambiado y/o un lecciones aprendidas
para la mejora
proceso de gestión de
servicio
Operación del
Servicio
Operaciones diarias
Salida de servicio y
procesos de
gestión de servicios

Las actividades se integran en el Ciclo de
Vida de los Servicios
7.1.12. El cambio organizativo

La mejora de la gestión del servicio exige un programa de cambio organizativo
Muchos programas de cambio organizativo fracasan al intentar alcanzar los resultados
deseados
El éxito de ITSM requiere entender la forma en la que el trabajo se realiza, y poner en
práctica un programa de cambio dentro de la organización de TI
Abarca a las personas y la forma en la que trabajan
Las personas generalmente son remisas al cambio; deben explicarse los beneficios a
toda la organización para conseguir su apoyo, y así abandonar las prácticas de trabajo
anteriores

7.1.13. Entradas y Salidas de CSI en las fases del Ciclo de Vida
Fase Entradas de la fase de la primera Salidas a la fase de la primera columna

columna
Catálogo de Servicios Resultados en las encuestas de satisfacción de los

Paquetes de Diseño de Servicios usuarios y clientes
La Información y el Conocimiento en el Entradas para los requerimientos del diseño
Diseño
SKMS Datos requeridos para métricas, KPIs y CSF

Mejoras de las métricas, KPIs y CSF Informes de servicios
Diseño de los servicios, arquitecturas, Retroalimentación para los Paquetes de Diseño del
métricas, procesos y sistemas Servicio
Oportunidades de mejora en los registros RFCs para implementar las mejoras
de CSI
La Información sobre pruebas Resultados en las encuestas de satisfacción de los

Transición
Informes de Evaluación del Cambio usuarios y clientes

La Información y el Conocimiento en el Entradas para las pruebas
SKMS Datos requeridos para métricas, KPIs y CSF
Mejoras de las métricas, KPIs y CSF Informes de servicios
Oportunidades de mejora en los registros Entradas a Evaluación del Cambio y el CAB
de CSI RFCs para implementar las mejoras
La Información y el Conocimiento en el Resultados en las encuestas de satisfacción de los

SKMS usuarios y clientes
Operación
Mejoras de las métricas, KPIs y CSF Informes de servicios y del Cuadro Integral de
Oportunidades de mejora en los registros Mandos
de CSI RFCs para implementar las mejoras
Propuestas de resolución de problemas y Datos requeridos para métricas, KPIs y CSF
medidas proactivas
Datos sobre el rendimiento operacional y
registros de servicio
Visión y la Misión Resultados en las encuestas de satisfacción de los

Cartera de Servicios usuarios y clientes
Directivas Entradas para los casos de negocio y Cartera de
Estrategia
Estrategias y Planes estratégicos Servicios

Prioridades Retroalimentación para la Estrategia de Servicios y
Información financiera y presupuestos Políticas
Patrones de Actividad del negocio (PBA) Información financiera en lo que se refiere a
Mejoras de las métricas, KPIs y CSF iniciativas de mejora como entradas al presupuesto
Oportunidades de mejora en los registros Datos requeridos para métricas, KPIs y CSF
de CSI Informes de servicios
RFCs para implementar las mejoras

7.1.14. El Principio de Propiedad

El principio de propiedad es primordial en cualquier estrategia de mejora
CSI es una mejor práctica, y un factor crítico de éxito es asegurar que un gestor
específico de CSI, se responsabilice de garantizar que se adopte y apoye la mejor
práctica en toda la organización
El gestor de CSI es el propietario y defensor principal de CSI
El propietario de CSI asume la responsabilidad del éxito de la Mejora Continua del
Servicio en la organización
La responsabilidad de la propiedad no se limita a asegurar que las prácticas de CSI se
integren en la organización, si no que se garantice que se aplican los recursos
necesarios para dar soporte y permitir la realización de CSI
También se incluyen actividades continuas de CSI, como monitorizar, analizar, evaluar
tendencias e informar, así como las actividades de mejora del servicio basadas en
proyectos; actividades que son fundamentales para el marco de trabajo de ITIL
7.1.15. Registros de CSI

Es probable que varias iniciativas o las posibilidades de mejorar sean identificadas
Se recomienda que un registro de CSI se mantenga para registrar todas las
oportunidades de mejora y que cada una deban ser clasificadas en grupos lógicos
Deben ser clasificadas las iniciativas que se pueden lograr rápidamente, o a medio o
largo plazo
Cada iniciativa de mejora también debe mostrar los beneficios que se lograrán con su
implementación. Con esta información se produce la lista de prioridades
Si un defecto se ha observado es que algo ha sido identificado como una prioridad
baja. El aumento de las prioridades en el tiempo puede ser además de utilidad para el
registro
El registro contiene información importante para CSI del proveedor de servicios (SP) y
debe ser considerado como parte del Sistema de Gestión del Conocimiento de los
Servicios (SKMS)
El registro de CSI presentará una estructura y visibilidad a CSI que pueda asegurar que
todas las iniciativas son capturadas y grabadas
Además de los beneficios, las métricas demostrarán que han dado los resultados
deseados.

7.1.16. La Mejora Continua de los Servicios (CSI) y el Cambio

Organizativo
Será necesario un cambio de mentalidad para convertir la Mejora Continua del Servicio en parte
permanente de la cultura organizativa.
Este es el aspecto más complicado de CSI y de hecho algunos programas de CSI fracasan al no
conseguir este cambio cultural. Según John P. Kotter de la Escuela de Negocios de Harvard se
requieren ocho puntos básicos:
Ocho razones por las que los esfuerzos de transformación no fracasen (Fuente: Kotter)
Crear un clima de urgencia: Plantear al personal la pregunta ¿Qué ocurrirá si no se
hace nada?
Formar una coalición rectora: Necesidad de crear un equipo con autoridad y recursos.
Desarrollar una visión: Sin visión CSI se convierte en un depósito de proyectos vacíos.
La visión debe de responder a los requisitos del negocio del cliente. Una guía para
tener una visión clara es el modelo SMART.
Comunicar la visión: Cada interesado tiene que saber cuál es la visión, cómo le afecta y
por qué se necesita el programa de CSI.
Capacitar a otros para que actúen sobre la visión: Eliminar obstáculos, definir
objetivos claros al personal y proporcionarles herramientas y/o formación.
Generar éxitos a corto plazo: En cada servicio o proceso qué es lo que se puede
mejorar en poco tiempo. No sea ambicioso.
Consolidar las mejoras y generar más cambio: Los logros a corto plazo motivan y
convencen, los logros a medio plazo aumentan la confianza en el personal de que se
puede lograr la capacidad de una mejora continua.
Institucionalizar los cambios:
Contratar a personal con experiencia en las mejores Prácticas en Gestión de TI.
Repartir instrucciones de trabajo desde el primer día.
Explicar qué y cuáles son los procedimientos.
Dar formación a la plantilla sobre Gestión de TI.
Adaptar los objetivos y los informes a la evolución de las demandas
Definir puntos de acción claros en las actas que se levanten.
Integrar las nuevas soluciones y proyectos de desarrollo de TIO en los procesos
existentes.

7.1.17. El ciclo Planificar - Hacer – Verificar – Actuar
Edwards Deming desarrolló en 1980 un método de mejoras de procesos paso a paso.

PDCA
Planificar: ¿Qué tiene que ocurrir, quién lo hará y cómo?
Hacer: Ejecución de las actividades planificadas.
Verificar: Comprobación de que las actividades dan el resultado deseado.
Actuar: Ajuste del plan en función de las verificaciones
Requerimientos Resultados
del Negocio del Negocio
PLANEAR
Identificar el
Solicitar alcance y Satisfacción
un nuevo objetivos del Cliente
Servicio
Métricas de ACTUAR Procesos

Servicios y HACER mas efectivos
Implementar
procesos Definir roles y y eficientes
Las mejoras
responsabilidades
Nuevos
Requerimientos
Servicios
externos
Cambiados
CHEQUEAR
Monitorizar,
medir y revisar Moral de
Requerimientos
Empleados
del Seguridad
mejorada
7.1.17.1. Planificar CSI

Determinar el ámbito.
Determinar los requisitos que debe cumplir CSI.
Determinar las comprobaciones que deben hacerse durante la fase de verificación.
Determinar las interfaces entre CASI y el resto del Ciclo de Vida.
Determinar los procesos y actividades que hay que introducir.
Definir objetivos (por ejemplo por análisis de gaps).
Definir puntos de acción.
Definir roles y responsabilidades.
Identificar las herramientas
Seleccionar los métodos y técnicas para medir y documentar la calidad y eficacia de los
servicios y procesos.

7.1.17.2. Implementar CSI (Hacer)

Determinar el presupuesto
Documentar roles y responsabilidades.
Determinar la política, los planes y los procedimientos de CSI, mantenerlos, divulgarlos y dar
formación a la plantilla.
Proporcionar herramientas de monitorización, análisis e informes.
Integrar CSI en las cuatro fases del Ciclo de Vida de los Servicios.
7.1.17.3. Monitorizar, medir y evaluar CSI (Verificar)

Informar de los progresos del plan.
Evaluar la documentación.
Efectuar evaluaciones y auditorías de progresos.
Plantear propuestas para mejorar procesos.
7.1.17.4. Ajustar CSI (Actuar)

Introducir las mejoras.
Ajustar la política, los procedimientos, los roles y las responsabilidades.
Métricas (KPIs)
7.1.18. Políticas de CSI
Continual Service Improvement debe implementar políticas como:

Todas las iniciativas de mejora deben pasar por Gestión de Cambios.
Todos los grupos funcionales son responsables de CSI.
Los roles de CSI deben ser registrados y anunciados.
7.1.19. Métricas, KPIs y Factores Críticos de Éxito (CSF)
Los responsables de ITSM necesitan saber si sus organizaciones cumplen los objetivos, para ello hay
que medirlo.
Necesitamos métricas para medir los resultados de una actividad o proceso para ver si una cierta
variable cumple el objetivo definido.
Las métricas se interpretan a nivel estratégico y táctico y deben de describir todos los procesos de la
organización.
CSF necesita tres tipos de Métricas (KPIs):
De tecnología: Miden rendimiento y disponibilidad de los componentes y aplicaciones.
De proceso: Miden el rendimiento de los procesos de Gestión de Servicios y proceden de los
KPIs que a su vez tienen su origen en los Factores Críticos de Éxito (CSF).
De servicio: Los resultados del servicio final, medidos con métricas de componentes.
Los KPI determinan la calidad, rendimiento, valor y conformidad.
Los KPI pueden ser cuantitativos coste de una incidencia) o cualitativos (satisfacción del cliente).

Una métrica es una escala de medida que se define en términos de un estándar, esto es, en
términos de una unidad totalmente definida. La cuantificación de un evento a través del proceso de
medida se basa en la existencia de una métrica explícita o implícita, que es el estándar al que se
referencian las medidas.
Las métricas son un sistema de parámetros o medios de evaluación cuantitativa de un proceso que
se tiene que medir. Las métricas definen qué se tiene que medir. Las métricas se especializan
normalmente por cada tipo de área, en cuyo caso sólo son válidas dentro de un cierto dominio y no
pueden compararse o interpretarse directamente fuera del mismo. No obstante, las métricas
genéricas pueden agregarse entre diversos tipos de áreas o unidades de negocio de una empresa.
Son empleadas en la Gestión del Conocimiento (KM). Estas medidas o métricas pueden servir para
realizar el seguimiento de las tendencias, la productividad, los recursos y para muchas otras
aplicaciones. Habitualmente, las métricas a las que se les realiza un seguimiento son KPI.
7.1.19.1. Ejemplo cualitativo

CSF: Mejora de la calidad del servicio de TI
KPI: Incremento del 10 por ciento en la tasa de satisfacción del cliente para la gestión de
incidencias durante los próximos 6 meses
Métricas necesarias:
 Resultado original de la satisfacción del cliente para la gestión de incidencias
 Resultado final de la satisfacción del cliente para la gestión de incidencias
Medidas:
 Resultado de la encuesta de gestión de incidencias
 Número de resultados de las encuestas
7.1.19.2. Ejemplo cuantitativo:

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 necesarias:
 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 de Gestión de Problemas por el personal y su sueldo
medio
 Tiempo invertido en la formación del personal sobre la solución provisional
 Tiempo y material del suministrador externo

7.1.19.3. ¿Cuántos CSF y KPI?

No se deberían de definir más de dos o tres KPI por CSF en un momento dado y que un servicio o
proceso no tenga más de dos a tres CSF asociados, mientras que para otros se puede recomendar
hasta cuatro o cinco. Aunque puedan parecer pocos si se tiene en cuenta el número de servicios,
procesos o se emplea la metodología del Cuadro de Mando Integral, el límite superior puede ser
sorprendente.
Se recomienda que en las primeras etapas de un programa de CSI, únicamente se definan,
monitoricen e informen dos o tres KPI para cada CSF. A medida que aumente la madurez de un
servicio y/o de los procesos de gestión del servicio, pueden agregarse otros KPI. Los KPI pueden
cambiar con el tiempo según resulte de importante para el negocio y la gestión de TI.
A modo de ejemplo, el incremento de la resolución en el primer contacto es un KPI común para la
Gestión de Incidencias. Este es un buen KPI con el que comenzar, pero la situación cambiará cuando
implemente la Gestión de Problemas.
Uno de los objetivos de la Gestión de Problemas es reducir el número de incidencias recurrentes.
Cuando estos tipos de incidencias recurrentes se reduzcan, también se reducirá el número de
resoluciones en el primer contacto. En este caso, una reducción de las resoluciones en el primer
contacto supone una tendencia positiva.
7.1.20. KPI (Key Performance Indicator)

Demuestran como la Organización de TI agrega valor al negocio.
Nos muestran donde estamos ahora
Determinan la efectividad de la Organización de TI.
Fijan guías para el plan estratégico de TI.
Comunican y motivan acerca del funcionamiento de TI.
Establecen los informes de Gestión de TI.
Para saber si los KPIs son adecuados deberían de responder a:
¿Se lograrán los objetivos si se cumple el KPI?
¿Se puede interpretar correctamente el KPI?
¿Ayuda a determinar las acciones necesarias?
¿Quién necesita la información’
¿Cuándo?
¿Con qué frecuencia?
¿En qué tiempo debe de estar disponible la información?
¿Es el KPI estable y preciso?
¿Depende del KPI a influencias externas y por lo tanto incontrolables?
¿Es fácil ajustar el KPI a nuevas circunstancias?
¿Hasta qué punto es posible medir justo ahora el KPI?
¿En qué circunstancias?
¿Quién efectúa y analiza las medidas?
¿Quién es el responsable de las mejoras debidas a esta información?

7.1.21. Cuadro Integral de Mando (Balanced Scorecard)
El Cuadro de Mando Integral es una filosofía práctica de gobierno corporativo de una organización y
fue desarrollada en 1992 por los profesores Robert Kaplan y David Norton de la Universidad de
Harvard. Su principal característica es que mide los factores financieros y no financieros del Estado
de Resultados de la Empresa.
Las cuatro perspectivas que conforman el modelo básico de Kaplan y Norton son:
Perspectiva Financiera.
Comprensión de los costes de TI para el negocio.
Capacidad de controlar los costes de TI para el negocio.
Economía de la provisión de TI.
ROI en infraestructura de TI.
Gestión de contratos de TI.
Perspectiva del cliente.
Disponibilidad de los servicios de TI.
Calidad de los servicios de TI.
Rendimiento de los servicios de TI.
Valor de los servicios de TI.
Fiabilidad de la infraestructura de TI.
Soporte a los usuarios finales de TI.
Procesos Internos.
Captura orientada al servicio.
Personal cualificado y conocimientos de TI.
Eficiencia de la provisión de servicios de TI.
Tiempos de entrega de servicios.
Capacidad de proceso.
Seguridad.
Responsabilidad de provisión de TI.
Aprendizaje y crecimiento.
Flexibilidad de la infraestructura de TI.
Capacidad de controlar los cambios en los servicios y en la infraestructura de TI.
Adaptabilidad de la infraestructura de TI a la demanda cambiante del negocio.
Comunicación y transferencia del conocimiento.
Productividad del negocio en relación a los costes de TI.
Aprovechamiento de la tecnología.

Se trata de un poderoso instrumento para medir el desempeño corporativo y se ha demostrado que

es la herramienta más efectiva para enlazar la visión, misión y la estrategia con cinco medidas de
desempeño que son:
Resultados Financieros
Satisfacción de Clientes (Internos y Externos)
Operación Interna Procesos
Creatividad, innovación y satisfacción de los empleados
Desarrollo de los empleados (competencias)
El CMI es un instrumento que permite ofrecer una visión completa de la organización, siendo el
elemento esencial del sistema de información que sirve de apoyo al sistema de control de gestión en
su misión de mejorar su nivel de competitividad en el largo plazo.
7.1.22. Benchmark
10
Patrón o Direrenciación
Punto de
Referencia
Percepción
del Espacio no
Cliente contestado
Su
Organización
0
Disposición Confiabilidad Conformidad
Opción de Ayuda técnica
Asequibilidad de Costes reguladora
Plataformas In situ
Y tiempos
La prueba patrón se puede basar en promedios de la
industria, el rival más cercano o la mayoría alternativa y
mas atractiva para el Cliente. La opinión del cliente puede
ser medida en cierta escala o índice aceptado dentro de la
industria.
Procedimiento de benchmarking
Conversaciones informales con clientes, empleados o proveedores
Grupos de interés
Estudios de mercado
Investigación cuantitativa
Encuestas
Cuestionarios
Análisis de reingeniería
Informes de varianza de control de calidad
Análisis de ratios financieros
Costes de benchmarking
De desplazamiento
De tiempo
De bases de datos de benchmarking
¿Quién está involucrado?

El Cliente
El usuario o consumidor
El proveedor interno y/o externo de servicios
Público en general
Colaboradores en el proceso de benchmarking
BENCHMARKING
Técnicas de gestión
empresarial
Descubrir Definir
Las observaciones que hace que una empresa

sea más rentable que otra
Categorías
Benchmarking Benchmarking Benchmarking Benchmarking

Competitivo Interno Funcional General
Se orienta a la: Comparación entre: Se orienta a todos los: Se enfoca en:

Competencia Operaciones o Competidores Otras empresas e
directa procesos internos Directos e industrias
indirectos
Importante Centra su atención Revela mejoras

diferencia entre: en temas críticos Busca reconocer la prácticas
Tecnología mejor práctica
Procesos
Similares

Evaluaciones
Las evaluaciones son Ventajas

muy útiles en las fases de Medir ciertas partes del proceso
Diseño Determinan el impacto de los
componentes en el proceso
Transición Se pueden repetir
Operación Se realizan evaluaciones comparativas
Desventajas
Representan un momento concreto, no la dinámica de la organización
Pueden convertirse en un fin y no en un medio
Exigen mucho trabajo
Los resultados dependen de puntos de vista subjetivos del evaluador
Aunque las medidas lo sean, quizás los resultados no sean objetivos
Los entrevistadores y los entrevistados pueden no entender la pregunta


7.2. Los Estándares de la industria y Marcos de Trabajo

7.2.1. ISO 9000
Término genérico que se refiere a varios normas y guías internacionales para Sistemas de
Gestión de Calidad (QMS) bien documentados y orientado al cliente. Para organizaciones
que quieren demostrar que su capacidad de entrega de bienes o servicios es constante en
sus procesos.
Es un conjunto de normas sobre calidad y gestión continua de calidad, establecidas por la

Organización Internacional de Normalización (ISO). Se pueden aplicar en cualquier tipo de
organización o actividad orientada a la producción de bienes o servicios. Las normas recogen tanto
el contenido mínimo como las guías y herramientas específicas de implantación, como los métodos
de auditoría. El ISO 9000 especifica la manera en que una organización opera sus estándares de
calidad, tiempos de entrega y niveles de servicio. Existen más de 20 elementos en los estándares de
este ISO que se relacionan con la manera en que los sistemas operan.
Su implantación, aunque supone un duro trabajo, ofrece numerosas ventajas para las empresas,
entre las que se cuentan con:
Estandarizar las actividades del personal que trabaja dentro de la organización por medio de
la documentación
Incrementar la satisfacción del cliente
Medir y monitorizar el desempeño de los procesos
Disminuir re-procesos
Incrementar la eficacia y/o eficiencia de la organización en el logro de sus objetivos
Mejorar continuamente en los procesos, productos, eficacia, etc.
Reducir las incidencias de producción o prestación de servicios
7.2.2. ISO/IEC 20000

Especificación y Código de Prácticas para Gestión del Servicio TI para cumplir con los
requisitos del negocio y de los clientes. Para Proveedores de Servicios de TI que desean
adoptar la norma global y que tienen capacidad para la entrega de servicios de TI de calidad
a clientes internos y externos
La organización se orienta más a los clientes
Mejora la reputación, la consistencia y las operaciones
Método estándar de valoración y auditoria externa e imparcial
Reconocimiento internacional en la industria
La valoración y las comparativas son un elemento importante de la mejora de procesos
Proporciona una guía de las medidas de Gestión de Calidad que se deben tomar para
implementar una política de calidad en la organización
Definir los procesos que contribuyan a la aceptación de los servicios por parte del cliente
Mostrar que una compañía considera seriamente la calidad y que cada servicio es auditado
individualmente antes de su entrega, al menos una vez al año por un organismo de
certificación registrado

Por negocios que salgan al mercado a ofertar sus servicios

Para proporcionar un método consistente para todos los proveedores de servicio en una
cadena de suministro
Para comparar la gestión del servicio de TI
Como base de una evaluación independiente
Para demostrar la capacidad de cumplimiento de los requisitos del cliente
Para mejorar los servicios.
La norma BS 15000 es la precursora de ISO/IEC 20000
7.2.3. ISO/IEC 27001

Especificación para Gestión de la Seguridad de la Información. Para reducir las
vulnerabilidades a riesgos de seguridad de la información mediante ISMS. Su
correspondiente código de prácticas es ISO/IEC 27002. Para organizaciones que desean
mantener los riesgos bajo control y proteger sus activos.
Está dentro del alcance de los requisitos de la norma ISO/IEC 20000
Gestión de la Seguridad de la Información (ISMS) es un concepto compartido entre ISO/IEC
20000 y ISO/IEC 27001
Consta de los siguientes capítulos
Introducción
1. Ámbito
2. Términos y definiciones
3. Estructura de este estándar
4. Valoración del riesgo y tratamiento
5. Política de Seguridad
6. Organización de la Seguridad de la información
7. Gestión de los recursos
8. Seguridad de los recursos humanos
9. Seguridad física y ambiental
10. Gestión de comunicaciones y operaciones
11. Control de acceso
12. Adquisición de sistemas de información, desarrollo y mantenimiento
13. Gestión de incidencias en la Seguridad de la información
14. Gestión de la continuidad del negocio
15. Conformidad

7.2.4. COBIT TM
Los Objetivos de Control para las Tecnologías de la Información (COBIT) conforman un
marco de trabajo reconocido y adoptado globalmente que se basa en controles, el valor y la
gestión del riesgo y que sirve para respaldar el gobierno general de TI. COBIT es un marco de
trabajo flexible que debe alinearse con los requisitos de negocio de una organización. Puede
ser empleado por la gestión, consultores y auditores para:
Definir los controles de TI necesarios para minimizar los riesgos y agregar valor al negocio y,
por lo tanto, para el desarrollo de un marco de trabajo de gobierno de TI adecuado a su
propósito
Crear un marco de trabajo de medición de TI y de CSI que se alinee con los objetivos del
negocio de TI
Evaluar y auditar al gobierno de TI y asegurar que éste se alinea con el gobierno global de la
empresa.
COBIT da apoyo a CSI de tres formas:
COBIT define procesos para dar apoyo a CSI
COBIT proporciona los modelos de madurez que se pueden utilizar para realizar
benchmarking e impulsar CSI
COBIT proporciona objetivos y métricas que se alinean con los objetivos del negocio para TI,
que pueden servir para crear un panel de control para la gestión de TI.
Suministrar una estructura uniforme para comprender, implantar y evaluar capacidades,
rendimiento y riesgos de TI.
Su objetivo es cumplir con los requisitos del negocio. Para organizaciones que desean
estructurar su gobierno
Se organiza en 4 dominios en un cuadrante
Planeamiento y Organización
Adquisición e Implementación
Entrega y Soporte
Monitoreo y Evaluación
Estos procesos tienen en cuenta múltiples factores que pueden impulsar la necesidad de
mejora, factores como la necesidad de mejorar el rendimiento y gestionar los riesgos con
más eficacia a través de mejores controles o de una mejor conformidad regulatoria. Estos
procesos también aseguran que se identifique cualquier acción de mejora y que se gestione
a través de su implementación.
Por lo tanto, una empresa puede implementar los procesos necesarios para dar apoyo a CSI
a través de los procesos de COBIT Además, una empresa puede revisar periódicamente los
procesos que dan apoyo a CSI y mejorarlos en función de sus modelos de madurez asociados
dentro de COBIT.

7.2.5. Microsoft Operational Framework

MOF ofrece directrices sobre el modo de planear, implementar y mantener procesos
operativos de TI que respalden las soluciones de servicio críticas
Optimización
Cambios
Operaciones
Soporte Técnico
7.2.6. SIX SIGMA

Six Sigma es una metodología de mejora de procesos adecuada para TI. Su objetivo
fundamental es reducir los errores a menos de 3,4 defectos por millón de ejecuciones
(independientemente de cuál sea el proceso). Dada la variada gama de entregables de TI
(por ejemplo, Gestión de Cambios, Gestión de Problemas, Gestión de la Capacidad) y los
roles y tareas que se puede encontrar dentro de los entornos operativos de TI, los gestores
de TI deben determinar si es razonable esperar que la provisión alcance un nivel Six Sigma.
Six Sigma es un método basado en datos que respalda la mejora continua. Se basa en las
salidas de negocio que dependen de las especificaciones del cliente y se centra en la
reducción drástica de la variación del proceso mediante el uso de medidas de Control de
Proceso Estadístico (SPC).
El objetivo de Six Sigma es la implementación de una estrategia orientada a medidas y
centrada en la mejora de los procesos y en la reducción de defectos. Un defecto Six Sigma se
define como cualquier cosa que se salga de las especificaciones del cliente.
Ofrecer a empresas las herramientas necesarias para medidas estadísticas de alto
rendimiento y aumentar su capacidad de negocio o de TI, reduciendo el número de defectos
y minimizar la variación de los procesos. Para organizaciones que desean conocer el
rendimiento de sus procesos y detectar las oportunidades de mejora.
Puede calcular el número de defectos por millón de unidades
Six Sigma engloba dos metodologías principales: DMAIC (definir, medir, analizar, mejorar,
controlar) y DMADV (definir, medir, analizar, diseñar, verificar). El proceso DMAIC es un
método de mejora de los procesos existentes que no satisfacen las expectativas, o de los
procesos en los que se desean mejoras increméntales. El proceso DMADV se centra en la
creación de nuevos procesos.

7.2.7. CMMI
Aumentar la facilidad de uso de modelos de madurez para la ingeniería de software y otras
disciplinas integrando muchos modelos en un solo marco de trabajo. Para organizaciones
que buscan mejorar los procesos en toda la empresa
Se usa para evaluar el grado de madurez de las organizaciones
El Modelo de Integración de Madurez de la Capacidad (CMMI) es un método de mejora de
procesos que proporciona a las organizaciones los elementos esenciales para la medición
efectiva de los procesos. Puede servir para guiar la mejora de los procesos a lo largo de un
proyecto, en una división o en toda una organización. CMMI ayuda a integrar funciones
organizativas tradicionalmente independientes, establece objetivos y prioridades para la
mejora de los procesos, proporciona directrices para los procesos de calidad y provee un
punto de referencia para evaluar los procesos actuales.
CMMI utiliza una jerarquía de cinco niveles, cada uno con una capacidad mayor que el
anterior para proporcionar calidad, en la que cada nivel se describe como un nivel de
madurez.
Aumentar la facilidad de uso de modelos de madurez para la ingeniería de software y otras
disciplinas integrando muchos modelos en un solo marco de trabajo. Para organizaciones
que buscan mejorar los procesos en toda la empresa
Se usa para evaluar el grado de madurez de las organizaciones
Las mejores prácticas de CMMI permiten a las organizaciones:
Un vínculo más explícito de la gestión y las actividades de ingeniería con sus
objetivos de negocio
Ampliar el ámbito y la visibilidad dentro del ciclo de vida del producto y las
actividades de ingeniería para asegurar que el producto o servicio satisfaga las
expectativas del cliente
Incorporar lecciones aprendidas de áreas adicionales de las mejores prácticas (por
ejemplo, medición, gestión del riesgo y gestión de suministradores)
Implementar prácticas más sólidas y con una mayor madurez
Abordar funciones organizativas adicionales que sean críticas para sus productos y
servicios
Mayor cumplimiento de los estándares ISO pertinentes

7.3. Sabiduría
Sabiduría es la capacidad de hacer evaluaciones correctas y tomar las decisiones adecuadas
haciendo el mejor uso de los datos, información y conocimiento
Las métricas proporcionan datos cuantitativos. (Ejemplo: CSU registra 1000 incidencias día).
CSI transforma estos datos en Información cualitativa a partir de datos agrupados y procesados. (El
20% de esas incidencias se relacionan con el correo electrónico.
La combinación de información, experiencia, contexto, interpretación y reflexión se convierte en
Conocimiento. (Si el negocio es una tienda Web determinamos el impacto de las incidencias en el
correo electrónico)
CSI convierte este conocimiento en Sabiduría
Esto se conoce como el modelo (DIKW) datos-información-conocimiento-sabiduría
Capacidad de toma
de decisiones
DIKW Conocimiento +
Sentido Común
Información +
Experiencia y Sabiduría
reflexión
¿ Porqué ?
Conocimiento
Datos +
contexto ¿ Cómo ?
Cifras, Información
caracteres,
imágenes ¿ Quién, cuando y dónde ?
Datos
Datos
Conjunto de hechos separados sobre los eventos. Datos cuantitativos
Knowledge Management (KM) (Gestión del Conocimiento):
 Recoge los datos
 Analiza, sintetiza, transforma datos en información
 Identifica los datos relevantes y utiliza los recursos para recogerlos
Información ( cualitativa )
Los datos se agrupan y procesan según el contexto (documentos, mail, etc.) KM
 Gestiona el contenido para facilitar su captura, obtención, búsqueda,
reutilización y aprendizaje de la experiencia para evitar los errores y evitar
rehacer el trabajo

Conocimiento
La información más experiencia, ideas, valores e interpretación la convierte en
conocimiento
Es dinámico y se basa en el contexto
KM (Gestión del conocimiento):
 Facilita el uso del conocimiento para la toma de decisiones
Sabiduría ( Wisdom )
Proporciona la capacidad, en un contexto dado, a emitir un juicio adecuado
 Ej: incidencias de correo pueden tener prioridad en un momento dado


7.4. Gobierno
7.4.1. El Gobierno de la Organización a través del Ciclo de Vida del
Servicio
La gobernabilidad es una única área general, que enlaza TI y el negocio, en su conjunto

Los servicios de TI son una forma de asegurar que la organización es capaz de ejecutar la
gobernabilidad
La gobernabilidad es lo que define las orientaciones políticas comunes, y las reglas para que el
negocio y el uso de TI puedan ejecutar la realización del negocio
Muchas estrategias de gestión de los servicios fallan 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 gobierno existentes
Cambiar la organización para satisfacer las nuevas necesidades de negocio es positivo; pero los
promotores de proyectos tienen que asegurarse de que el gobierno de las organizaciones reconoce y
acepta estos cambios
No hacerlo así resultará en una ruptura entre las políticas de gobierno de la organización y sus
procesos actuales. Esto se traduce en una organización disfuncional, y una solución que en última
instancia, fracasará.
7.4.2. Establecer la Estrategia, Políticas y Planes
Evaluar
Dirigir Monitorizar
7.4.2.1. Evaluar
Actividad para evaluar permanentemente el desempeño de la organización y su
rendimiento. Esta evaluación incluirá un conocimiento profundo de la industria, sus
tendencias, el entorno normativo y los mercados a los que la organización sirve
Servicios y carteras de proyectos
Las operaciones en curso
Ampliaciones
Las oportunidades y amenazas
Las propuestas de los directores, accionistas, clientes, etc.

Los contratos
Los comentarios de los usuarios, clientes y socios
7.4.2.2. Dirigir
Actividad que se relaciona con la comunicación de la estrategia, políticas y planes a través de
la gestión. También asegura que a los gerentes se le dan las directrices adecuadas, para que
sean capaces de cumplir con la gobernabilidad
La delegación de autoridad y responsabilidad
Los comités de dirección para comunicarse con la gestión, y para hablar de
retroalimentación (también se utiliza durante la Evaluación)
La visión, estrategias y políticas se comunican a los directivos, de los que se espera que las
comuniquen y cumplan con ellas
7.4.2.3. Monitorizar
Actividad por la que el gobierno de la organización debe ser capaz de determinar si el
gobierno se está cumpliendo con eficacia, y si hay alguna excepción. Esto les permite tomar
medidas para rectificar la situación, y también aportar ideas para
evaluar la eficacia de las medidas de gobierno actual. Se requerirá:
Un sistema de mediciones, a menudo un Cuadro Integral de Mandos
Indicadores clave de rendimiento (KPIs)
Evaluación de riesgos
Auditoría de cumplimiento
Análisis de capacidades de servicio, lo que garantizará que la gestión tenga lo que
necesita para cumplir con la gobernabilidad
“TI es el Negocio y el Negocio es TI”
La información es la fuente principal de Negocio y es el recurso estratégico más importante

que maneja una Organización
Los elementos clave para el almacenamiento, análisis, producción y distribución de la
información son la infraestructura y servicios de TI de calidad.
Proporciona una adecuada gestión de calidad.
Aumenta la eficiencia.
Alinea los procesos de Negocio y la infraestructura de TI.
Reduce los gastos asociados a los Servicios de TI
Genera Negocio.
Las actuales organizaciones de TI interno deben transformarse en efectivos y
eficientes Proveedores de Servicios de TI o dejarán de ser relevantes para la empresa
y poco después, dejarán de existir. Este incesante y continuo impulso hacia un
mayor valor de Negocio con mayor eficiencia interna está en el corazón de CSI.

La información es la fuente principal de Negocio y es el recurso

estratégico más importante que maneja una Organización
Los elementos clave para el almacenamiento, análisis, producción y
distribución de la información son la infraestructura y servicios de TI
de calidad.
TI Genera Negocio.
TI es el negocio,
El negocio es TI
Gobierno de la Organización o Corporativo: Considera el panorama en su conjunto y se asegura de

que los objetivos estratégicos están alineados y la buena gestión se logra. Está relacionado con la
promoción de la justicia, transparencia y responsabilidad en la empresa. (J. Wolfensohn, Presidente,
Banco Mundial
Gobierno de Negocio: Da como beneficios buenos resultados para la empresa
Gobierno Empresarial: La promoción de la equidad corporativa, la transparencia y la rendición de
cuentas. La combinación del Gobierno Corporativo y de Negocio
Gobierno de TI: Es responsabilidad del consejo de administración y gestión ejecutiva. Parte
integrante del gobierno empresarial y consiste en el liderazgo, las estructuras organizativas y
procesos que aseguren que la organización de TI soporta y extiende en la organización sus
estrategias y objetivos.
Establece responsabilidades
El gobierno de TI no existe como un área separada. Ya que es parte de la organización, TI no
puede ser gobernado de una manera diferente al resto de la organización
ISO / IEC 38500 se refiere a "gobierno corporativo de TI “y no TI. Esto implica que cumple
con las políticas y normas de la organización, y no crea un conjunto separado de sí mismo
Las otras unidades de negocio comparten los mismos objetivos y la identidad corporativa, y
están obligados a seguir las mismas reglas de gobierno
Lo que normalmente se llama “gobierno”, es generalmente una cuestión de los CIO o alto
directivo de TI, es la aplicación de gestión empresarial a través de una serie de estrategias,
políticas y planes. Sin embargo, como miembro de la ejecutiva, el CIO participa en cómo la
forma de gobierno se ha definido y trasladado a la gestión de TI

GOBIERNO EMPRESARIAL
Gobierno Corporativo Gobierno de Negocio
Gobierno de TI
Aseguramiento de Creación de Valor

Responsabilidad final Utilización de recursos
7.4.3. Gobierno y Actividades de Gestión
Propósitos y Planes
Evaluar
GOBIERNO
Dirigir Monitorizar
Estrategias
Rendimiento
y Políticas
y Conformidad
Gobernadores (los que crean y aseguran la gobernabilidad) a menudo no son los administradores de
la misma organización.
La gobernanza y la rendición de cuentas son creadas por los gobernadores. Gestión es la ejecución
de las reglas y la autoridad concedida por el gobierno. Esto permite que un sistema de frenos y
contrapesos que se mantenga y así maximiza la integridad de la organización.
Las excepciones incluyen las situaciones en que el presidente (gobernador) de la Junta es también el
director general o director gerente (manager).

7.4.4. Marco de Gobierno

Un marco de gobierno es un conjunto de documentos estructurados y categorizados que expresan
claramente la estrategia, políticas y planes de la organización
ISO/IEC 38500 describe los siguientes seis principios que se utilizan para definir los ámbitos de
gobierno o áreas que necesitan ser gobernadas:
Establecer responsabilidades
Estrategia para establecer y cumplir los objetivos de la organización
Adquirir por razones válidas
Asegurar que se realice cuando sea necesario
Asegurar la conformidad con las reglas
Asegurar el respeto a los factores humanos
Cada uno de estos seis ámbitos tendrá políticas de alto nivel, que forman parte del marco, y que
será utilizado por los Gerentes en la construcción de los procedimientos, servicios y operaciones que
cumplan los objetivos de la organización
7.4.5. Cuerpos del Gobierno
Presidente
Secretario de la compañía
Gobernadores Tesorero
Responsables del Altos Ejecutivos de la
Gobierno Corporativo Compañía
Director ejecutivo (CEO)

El Ejecutivo Director Financiero
Responsable de la ejecución Director de Operaciones
y el cumplimiento del Director de marketing
Gobierno Corporativo Jefe de información
Los Ejecutivos de Negocio
Grupo de dirección de TI (ITSG)

Responsabilidad de definir cómo
Jefe de la Oficina de
TI funciona con otras áreas de
Información (CIO)
negocio para ejecutar el Gobierno
Corporativo y la estrategia
Los líderes de negocios
Los Gestores de Relaciones
con el Negocio


7.5. Proceso de mejora de CSI

Antes de empezar con los 7 pasos de la Mejora Continua del Servicio, tenemos que
identificar los objetivos de:
VISIÓN, ESTRATEGIA, TÁCTICOS y OPERACIONALES
Visión
Alineamiento Estrategia
TI / Negocio
Capacidad
Disponibilidad
Planificación Continuidad
Entrega del Nivel de Servicio
Táctica
Servicio Finanzas de TI
Seguridad
Service Desk
Operaciones Eventos
día a día Incidentes
Soporte del
Servicio Problemas
Cambios
Entrega
Medir no debe ser nunca un objetivo en sí mismo. Antes de decidir qué se va a medir y durante
cuánto tiempo, un gestor debe pensar POR QUÉ es necesario medir y cómo se van a utilizar esos
resultados. Las cuatro respuestas más habituales para medir serían.
Validar: Para probar decisiones anteriores.
Dirigir: Para marcar el rumbo de las actividades para conseguir los objetivos.
Justificar: Para explicar las necesidades de determinadas acciones.
Intervenir: Para determinar el punto en el que es necesario cambios en el proceso
Para agregar valor al negocio hay 4 razones para monitorizar y medir que son
VALIDAR – DIRIGIR – JUSTIFICAR – INTERVENIR


7.6. El Proceso de los 7 Pasos de la Mejora
Identifique
• Visión 1.- Defina: ¿Qué 2.- Defina: ¿Qué se
• Estrategia Mediría? puede Medir? Datos
• Objetivos tácticos
• Objetivos operativos
3.- Recopilar Datos
¿Quien? ¿Cómo? ¿Cuándo?
HACER ¿Información integra?
Sabiduría
PLANEAR
REVISAR Información
7.- Implementación de
Acciones correctivas
ACTUAR 4.- Proceso de Datos
¿Frecuencia? ¿Formato?
¿Sistema? ¿Exactitud?
5.- Analizar los datos

6.- Presentación y uso de
¿Relaciones? ¿Tendencias?
Información, evaluación
¿Conforme al Plan?
Sumario, plan de acción
¿Objetivo OK?
oportunidades
¿Acciones correctoras?
Conocimiento
7.6.1. Objetivos de los 7 pasos

Identificar oportunidades para mejorar los servicios, procesos, herramientas, etc.
Reducir el coste de la prestación de servicios y garantizar que los servicios dan los resultados
de negocio esperados
Un objetivo claro será la reducción de costes, pero esto no es el único criterio pues si la
prestación de servicios o la calidad se reduce puede ser neutro o incluso negativo
Identificar lo que hay que medir, analizar, comunicar y establecer oportunidades de mejora
Revisar continuamente los logros del servicio para asegurarse de que siguen adaptando a los
requerimientos del negocio; y alinear y realinear la prestación de servicios con los requisitos
de acordados
7.6.2. Ámbito
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

7.6.3. Valor
El valor del proceso de Mejora en Siete Pasos es que mediante el seguimiento y análisis de la
prestación de servicios se garantizan los requisitos de negocio actuales y futuros para que se
puedan cumplir los objetivos del negocio
El proceso de Mejora en Siete Pasos permite la evaluación continua de la situación actual
con las necesidades del negocio e identifica oportunidades para mejorar la prestación de
servicios para los clientes

Los requisitos de control deben ser definidos e implementados
Los datos deben ser recogidos y analizados en su integridad y examinados de forma
consistente
Los Informes de tendencias se deben proporcionar en forma consistente
Los informes de Servicio con el nivel de logro se deben proporcionar en forma consistente
Las revisiones de servicios internos y externos deben ser completados dentro de TI y el
negocio en forma consistente
Los Servicios deben tener claramente definidos los niveles de servicio o los objetivos del
mismo para poder determinar si existen lagunas en los servicios prestados
Los procesos de gestión de servicios deben tener factores críticos de éxito (CSF) y los
indicadores clave de rendimiento (KPI) para determinar si hay diferencias entre los
resultados esperados y los resultados reales
7.6.5. Procesos, actividades y Métodos

Qué se debe medir:
Consultar con el negocio para saber lo que quiere
Que se puede medir
Comprobar lo que ya se ha medido
Determinar lo que se puede medir y se debe medir (p.eje.: SLA, OLA, UC)
Recopilación de datos (medición)
Determinar quien recibe los datos y qué análisis son necesarios
Procesamiento de datos
Evaluar los datos desde la perspectiva del negocio
Considerar la frecuencia con que se deben procesar los datos y comunicarlos
Análisis de datos
Compara los logros a Nivel de Servicio (rendimiento, resultados) con los SLAs
Identificar y registrar tendencias para formar posibles patrones
Determinar la necesidad de implementar el SIP
Determinar si hay que ajustar OLAs y UCs
Presentación de la información
Generar informes y comunicárselos al negocio
Organizar evaluaciones internas y externas
Ayudar a priorizar actividades
Implementación de acciones correctivas
Elaborar un Plan de Mejora de Servicio (SIP) junto a Gestión de Problemas y de la
Disponibilidad y comprobar que la organización sigue dicho plan

7.6.6. Paso UNO
7.6.6.1. Pasos 1 Definir lo que se debería medir
¿Qué se puede medir?

¿Dónde encontrar la información?
Hable con el Negocio
Elabore una lista de lo que debería medir
Identificar:
Visión, misión, metas
Factores Críticos de Éxito
Objetivos de TI
Objetivos de nivel de servicio
Entradas:
Requerimientos del Nivel de Servicio
Requisitos Legislativos
Ciclo presupuestario
Elabore una lista de lo que debería medir. Normalmente los requisitos de negocio le
ofrecerán una indicación.
No trate de cubrir todas y cada una de las eventualidades o posibles métricas del mundo.
Simplifique.
El número de elementos que debería medir puede crecer muy rápidamente. Lo mismo
puede suceder con el número de métricas y medidas.
A. Paso 1 – Defina qué es lo que Ud. mediría

Hable con el Negocio, con los clientes, con los usuarios y con los gestores responsables de la Gestión
de TI. Utilice el Catálogo de Servicios como punto de partida, así como los requisitos del porcentaje
de disponibilidad de los diversos clientes.
Éste es el momento donde nos tenemos que preguntar: ¿En un mundo perfecto, qué debo medir?
¿Qué es lo más importante para el Negocio?
Compile una lista de lo que usted debe medir
¿Qué es lo más importante para el Negocio?
En el inicio del Ciclo de Visa de los Servicios, la Estrategia de Servicio y el Diseño del Servicio deben
haber identificado esta información
CSI puede entonces comenzar su ciclo de nuevo en “¿dónde estamos ahora?”
Esto identifica la situación ideal para el Negocio y TI
Entradas:
Requisitos y objetivos del porcentaje de disponibilidad
El Catálogo de Servicios
Declaraciones de la visión y de la misión
Metas y objetivos corporativos, por división y departamentales
Requisitos legislativos
Requisitos del Gobierno
Ciclo de presupuesto
Balanced Scorecard

Roles:
Individuos implicados en la toma de decisiones de TI y el Negocio. Ellos entienden y saben de los
factores internos y externos que influencian sobre los elementos necesarios que se deben medir
para apoyar el Negocio y posiblemente la legislación reguladora.
7.6.6.2. Pasos 2 Definir lo que se puede medir
Si no se puede medir no debería

de aparecer en el SLA
Elabore una lista de las herramientas
Evite la personalización
de la configuración de las herramientas
¿Dónde encontrar la información?

Analice las BBDD existentes
¿Qué datos se están recopilando?
Realice análisis gaps de las dos listas
Comunique al Negocio esta información
Entradas:
Liste lo que se debería medir
Flujos de procesos
Procedimientos
Informes existentes
B. Paso 2 – Defina qué puede Ud. medir

Se relaciona con la recopilación de datos, el proceso de los datos en el formato requerido y analizar
los resultados para buscar respuestas a las preguntas
En algunas organizaciones este paso se ignora, pues TI cree que lo sabe todo
Lista de lo que debería medir si se puede. Si no se puede que no aparezca en el SLA.
Flujos de proceso
Procedimientos
Instrucciones de trabajo
Manuales técnicos y de usuario de las herramientas existentes
Informes existentes
Identificando los requisitos del nivel del nuevo servicio del negocio, conociendo las capacidades de
TI (identificadas en el Diseño del Servicio e implementadas vía la Transición del Servicio) y los
presupuestos disponibles, CSI pueden realizar un análisis (gap=hueco) que identificará las
posibilidades de mejorar, respondiendo a la pregunta “cómo conseguiremos llegar allí?” realizando
un análisis en profundidad entre las dos listas para informar al negocio, a los clientes de las
conclusiones.
Herramientas típicas serían
Herramientas del mercado de Gestión de Servicios
De monitorización
De informes
De investigación
Es posible que se requieran más y nuevas herramientas para medir

Compile una lista de las herramientas que actualmente puedan medir

Desarrolle un gap análisis entre las dos listas
Haga un informe para los gestores de TI y para sus clientes de las herramientas encontradas
¿Dónde encontrar información?
Dentro de cada proceso, instrucción de procedimiento y de trabajo
Mire los informes y las bases de datos existentes
Blogs
Foros
Conferencias
Manuales de los fabricantes
Google
Entradas:
Liste lo que Ud. Mediría
Flujo de los procesos
Procedimientos estandarizados
Instrucciones de trabajo
Existentes registros
Manuales técnicos
Roles
Las personas involucradas en la entrega de servicios internos o externos que entienden de las
capacidades de los procesos, procedimientos y herramientas
7.6.6.3. Paso 3 Procedimientos de monitorización y

recolección de datos
Definir los requisitos

de monitorización y
Definir la frecuencia
Determinar los requisitos
de herramientas
Desarrollar los procedimientos

Actualizar los planes de

disponibilidad y capacidad
Iniciar la
Monitorización y

C. Paso 3 – Recopilando los Datos

¿Cómo vamos a llegar?
Los datos deben primero ser recopilados (en la fase de Operaciones de Servicio), ser
procesados y ser analizados. Se recopilan los datos basados en la visión, la misión, las metas y los
objetivos. Los datos procesados, alineados con las CFS y KPIs se preparan antes de que la
información se analice para identificar las diferencias y tendencias, junto con su razonamiento antes
de que se presente al negocio.
Estas actividades tienen que estar claramente definidas como saber:
¿Quién es el responsable de monitorizar y recopilar los datos?
¿Cómo los datos serán recopilados?
¿Cuándo y con qué asiduidad serán recopilados?
Criterios para evaluar la integridad de los datos
Recopilando datos se define como el acto de monitorización y recolección de
datos. Recopilar datos requiere tener cierta forma de monitorización en cada momento
La monitorización podía ser ejecutada usando tecnología tal como aplicaciones, sistemas y
herramientas de monitorización o quizás ser un proceso manual para ciertas tareas.
La monitorización se centrará en la eficacia de un servicio, de un proceso, de una
herramienta, de una organización o de un CI.
Tres tipos de Métricas (KPIs) son usados en CSI y otras actividades
Métrica de la tecnología: Estas métricas se asocian a menudo al componente basado en
aplicaciones tal como funcionamiento, disponibilidad etc.
Métrica de proceso: Estas métricas se capturan bajo la forma de CFS, KPI y métrica de
Actividad para los procesos de la Gestión de Servicios. Pueden ayudar a determinar la salud
total de un proceso. Cuatro preguntas claves que serán respondidas con la ayuda de los KPI y
que se refieren a la calidad, funcionamiento, valor y la conformidad del proceso. CSI
utilizaría estas métricas como entrada en la identificación de oportunidades para la mejora
de cada proceso.
Métrica del servicio: Estas métricas son los resultados del servicio de extremo a extremo.
Las métricas de los componentes de la tecnología se utilizan para computar la métrica del
servicio.
¿Qué es lo que se tiene que medir ahora?
Los datos recopilados, identificados y medibles
Salud de la Gestión de Servicios
Conformidad con el Proceso: ¿Se están siguiendo los procesos? La conformidad del
proceso intenta monitorizar la conformidad de la organización TI a los nuevos o
modificados procesos de la Gestión de Servicios y también al uso de las herramientas
de gestión autorizadas e implementadas
Calidad: ¿Con qué aproximación al objetivo los procesos están trabajando?
Monitorización de las actividades individuales o claves y como se relacionan con los
objetivos del proceso de extremo a extremo
Rendimiento: ¿Cómo de rápido o de lento? Monitorización de la eficiencia de
proceso tal como duraciones del rendimiento de procesamiento o de ciclos
Valor: ¿Es esto lo que nos diferencia? Monitorización de la efectividad y de la
percepción del valor del proceso por los Interesados.

Entradas:
Requerimientos del Nuevo Negocio
Existentes SLAs
Existente monitorización y datos capturados
Service Improvement Programs (SIP)
Informes anteriores de análisis de tendencias
Lista de qué mediría
Lista de lo que puedes medir
Informes Gap análisis
Lista de lo medido
Evaluaciones de satisfacción del cliente
Salidas:
Planes de Capacidad y Disponibilidad actualizados
Procedimientos de monitorización
Plan de monitorización
Herramientas que vamos a utilizar
Input para el plan de Capacidad
Recolección de datos
Acuerdo sobre integridad de datos y que sean de aplicación
Roles:
Individuos implicados en las actividades de procesos en el día a día dentro de la Transición del
Servicio y de las fases del ciclo de las Operaciones de Servicio
La recopilación de datos es sinónimo de Medición de Servicio. Es importante recordar que hay tres
tipos de métricas que la organización tendrá que reunir para apoyar CSI y otras actividades de
proceso:
Métricas de Tecnología, de Servicios y de Procesos.
7.6.6.4. Paso 4 Actividad de procesamiento de datos
Definir los requisitos

de procesamiento
de datos
Procesar en
Definir la frecuencia
agrupamientos
de procesamiento
lógicos
de datos
Determinar los requisitos

de formato y herramientas Evaluar la
de procesamiento de datos
precisión
Desarrollar y comunicar
el plan de procesamiento
de datos
Actualizar los planes de

disponibilidad y capacidad
Iniciar el procesamiento
de datos

D. Paso 4 – Procesando los Datos

Convierta los datos en el formato requerido y para según qué audiencia. Sigue el rastro de las
métricas por los KPI hasta la CSF hasta el final. Si hay una nueva a la visión, en caso de necesidad, se
vuelve a empezar.
Visión
Misión
Metas
Objetivos
CSF
KPI
Métricas
Medidas

Los datos deben primero ser recopilados (en la fase de Operaciones de Servicio), ser procesados y
ser analizados. Se recopilan los datos basados en la visión, la misión, las metas y los objetivos. Los
datos procesados, alineados con las CFS y KPIs se preparan antes de que la información se analice
para identificar las diferencias y tendencias, junto con su razonamiento antes de que se presente al
negocio.
Las preguntas claves que se tratarán en el Actividad de proceso son:
¿Cuál es la frecuencia de procesar los datos? Esto podía ser cada hora, diario, semanal, o
mensual. Cuando se transiciones un nuevo servicio o un nuevo proceso de un servicio es una
buena idea supervisar y procesar en intervalos más cortos de lo normal. Cuantas veces se
hagan análisis de las actividades y sus tendencias, tantas veces los datos se procesarán
¿Qué formato se requiere para la salida? Esto es definido por cómo se hace el análisis y en
última instancia cómo se utiliza la información.
Hay dos formas de re coleccionar datos:
Automatizado: Más actualizado
Manual: Es importante que el personal documente correctamente sus actividades de
conformidad a Diseño de Servicios, para poner al día registros y expedientes. Las excusas
comunes son que la gente está demasiado ocupada, que esto no es importante o que no es
su trabajo. La información acerca de las ventajas de la ejecución de las tareas
“administrativas” es de vital importancia. Obligar a estas tareas administrativas tiene que ser
unidireccional para conseguir los objetivos.

Entradas:
Los datos recogidos durante la monitorización
Información requerida anteriormente
SLAs
OLAs
Lista de KPI, CFS, objetivos y metas
Plantillas divulgadas
Salidas
Planes de Disponibilidad y Capacidad actualizados
• Informes
• Agrupamientos lógicos de datos preparados para el análisis
E. Paso 5 – Analizando los Datos

Cuando analizamos los datos es importante responder a las preguntas como:
¿Las operaciones están funcionando según lo planificado? -Esto podía ser un plan del
proyecto, plan financiero, disponibilidad, capacidad o plan de Gestión de la Continuidad del
Servicio.
¿Los objetivos definidos en SLAs o en el Catálogo de Servicios se están resolviendo?
¿Hay problemas estructurales que son muy importantes y que pueden ser identificados?
¿Se requieren las acciones correctivas?
¿Hay tendencias? Si las hay ¿Cuáles son y se pueden demostrar sus tendencias?
¿Son tendencias positivas o negativas?
¿Cuáles son las que están provocando las tendencias?
El análisis de los datos transforma la información en conocimiento de los eventos que afectan a la
organización.
Se requiere una mayor experiencia y habilidad para realizar el análisis de los datos que para
realizar la recolección y procesamiento de los datos.
Esta actividad debe incluir la verificación de los mismos con respecto a las metas y objetivos.
Esta verificación valida que los objetivos estén respaldados y que se esté añadiendo valor.
No basta con generar unos simples gráficos de diversos tipos, es necesario documentar
también las observaciones y conclusiones.
Entradas:
Resultados de los datos monitorizados
Existentes objetivos y KPIs
Percepciones de los clientes y usuarios por encuestas de satisfacción

F. Paso 6 – Presentando y Uso de la Información

La información debe ser entregada en el formato y manera necesaria a los Interesados como la
representación exacta y actual de los resultados de los esfuerzos de la mejora. El conocimiento se
presenta al negocio de forma que refleje sus necesidades y les ayude en la determinación de los
pasos a seguir
Presentando el Conocimiento
El objetivo final es coger nuestro conocimiento y presentarlo; es decir, aprovechar nuestra sabiduría
para utilizarla en informes, monitorizaciones, planes de actuación, revisiones, evaluaciones y
oportunidades. Considere a quien va dirigida la información y según la audiencia cerciórese de que
usted ha identificado las excepciones al servicio, las ventajas que se han revelado que o pueden
conseguirse.
Si por ejemplo la recolección de los datos ocurre en el 4 º nivel de una organización, dé formato a
estos datos para que sean prácticos a sus niveles respectivos y hacia arriba.
Identificando:
Excepciones a los Servicios
Beneficios relevantes o que pueden ser esperados.
En este paso no existen Métricas. Hace foco en como presentar la información y dependerá del
público objetivo.
Pregunta: ¿Dónde puede encontrar la información en realidad?
Respuesta: La puede extraer de los pasos anteriores .
Normalmente existen tres audiencias diferentes:

El negocio - Su necesidad real es entender si TI proporcionó el servicio prometido en
los niveles apropiados y, si no fue así, qué acciones correctivas se están
implementando para mejorar la situación.
Gestión Sénior (TI) - Este grupo se centra más a menudo en los resultados
relacionados con los CSF y KPI, como la satisfacción del cliente, comparación de los
resultados reales con el plan, contabilidad de costes y objetivos de ingresos. La
información que se facilita a este nivel, contribuye a determinar las mejoras
estratégicas y tácticas a una mayor escala. La gestión sénior (TI) normalmente quiere
que este tipo de información se facilite en la forma de un Cuadro de Mando Integral
TI interno - Este grupo con frecuencia está interesado en los KPI y métricas de
actividad que le ayudan a planificar, coordinar, programar e identificar
oportunidades de mejora creciente.
Roles:
Individuos implicados en proporcionar el servicio (proveedores internos y externos) que entienden
de las capacidades del servicio y de los procesos de ayuda y soporte y poseen buenas habilidades de
comunicación. Personas claves implicadas con la toma de decisiones de la Gestión de TI y el Negocio.

Diagrama del logro del nivel de servicio (SLAM)
Periodo
Enero Febrero Marzo Abril Mayo Junio Julio Agosto
Objetivo
Objetivo Objetivo Objetivo

cumplido incumplido en riesgo
Gráfico de monitorización del SLA, que proporciona una representación visual de la capacidad de
una organización para alcanzar los objetivos definidos a lo largo de un periodo de meses.
Algunos de los problemas que se presentan en relación con la actividad de presentación de informes
pueden ser:
Todo el mundo obtiene el mismo informe (el negocio, la gestión sénior y los gestores de TI).
El formato no es lo que los Interesados desean ver. Es importante comprender a la audiencia
y cómo le gusta recibir la información. A algunos les gusta ver la información en formato de
texto, a otras en gráficos, diagramas circulares, etc. No es fácil contentar a todos, pero llegar
a un acuerdo sobre el formato del informe es un buen paso
Por esta razón muchas organizaciones están adoptando un concepto de Cuadro de Mando
Integral o cuadro de mando de TI. Este concepto puede iniciarse a nivel del negocio, luego a
nivel de TI y después al nivel de los grupos funcionales y/o servicios dentro de TI.
Ausencia de un resumen ejecutivo - el informe ejecutivo debería comentar los resultados
actuales, qué llevó a obtener los resultados y qué acciones se han adoptado o se adoptarán
para abordar cualquier problema.
Los informes no están vinculados con ninguna línea de referencia, cuadro de mando de TI o
Cuadro de Mando Integral.
Se facilitan demasiados datos complementarios, o irrelevantes
Los informes se presentan en términos que no resultan comprensibles. Por ejemplo, se
informa de la disponibilidad en porcentajes, cuando normalmente el negocio está
interesado en conocer el número, duración e impacto de las interrupciones temporales.
Entradas
Información recopilada
Detalles de formato, plantillas, etc.
Datos de contacto con los interesados

G. Paso 7 – Implementando Acciones Correctivas

Uso del Conocimiento adquirido
Para optimizar, mejorar y corregir los servicios.
Los gestores identifican problemas y las actuales soluciones.
Medidas correctivas que necesitan ser tomadas para mejorar el servicio se comunican y se
explican a la organización.
Después de este último paso la organización establece una nueva Línea de Referencia y el ciclo
comienza de nuevo. Mientras que estos siete Pasos de la Mejora parecen formar un sistema circular
de actividades, de hecho, constituyen una espiral del conocimiento.
En la práctica actual, el conocimiento adquirido y la sabiduría derivada de ese conocimiento, en un
nivel de la organización, se convierte en una entrada de datos al siguiente.
En el primer nivel y más alto de la organización se encuentran los responsables de la estrategia. Los
informes deben ser breves, fáciles de leer y deben alinearse con las directrices de la audiencia
objetivo.
El segundo nivel consiste en los vicepresidentes y directores. Los informes pueden ser más
detallados, pero tienen que resumir las conclusiones a lo largo del tiempo. Identificar cómo los
procesos respaldan los objetivos de negocio.
El tercer nivel consiste en los gestores y supervisores de alto nivel. La conformidad con los objetivos
establecidos, el rendimiento del equipo en general y del proceso, el conocimiento en profundidad de
las restricciones de los recursos y las iniciativas de mejora continua son sus directrices.
Finalmente, en el cuarto nivel de la jerarquía se encuentran los miembros del personal y los líderes
de los equipos. A un nivel personal, es necesario destacar los beneficios personales
Gobierno Corporativo
Paso Siete
Valor al Negocio
Ingresos
Gestión Senior TI Beneficios
Marcos de Auditoria ROI
Métricas de Actividad CSF
COSO-COBIT-SA77 CSF y KPIs Satisfacción del
ITIL ® – ISO 20000

Cliente
Detalles
-
¿Se están entregando los Cuadro de

servicios de acuerdo a los Mandos
niveles acordados? Integral
Centro de Servicio al
Usuario
Incidentes
Problemas
+
Detalles
Cambios, etc
Entradas
Los conocimientos adquiridos a partir de la presentación y uso de la información
Acuerdos de planes de implementación (del paso 6)
Un registro de CSI para aquellas iniciativas que se han iniciado a partir de otras fuentes

7.6.7. Entradas genéricas para los 7 pasos de mejora de CSI

SLRs
La reunión de revisión del servicio
Visión y misión de declaraciones
Objetivos corporativos, divisionales y departamentales
Los requisitos legales
Requisitos del Gobierno
ciclo presupuestario
Encuestas de satisfacción del cliente
La estrategia global de TI
Las expectativas del mercado (especialmente en relación a la competencia de los
proveedores de servicios de TI)
Los nuevos mentores de tecnología (por ejemplo, la entrega basada en la nube y hospedaje
externos)
Flexibles modelos comerciales (por ejemplo, los gastos de capital, modelos comerciales
operativos y modelos de alquiler)

7.6.8. Roles de los 7 pasos de mejora de CSI
PASO ROLES ACTIVIDAD HABILIDADES

1.- ¿Qué mediría Quién decida sobre el Alto nivel de Gestión Gestión de habilidades
Ud. primero? mercado Muy variada Comunicación
Service Manager Acción orientada Creación y usos de
Service Owner Comunicativa conceptos
Service Level Manager Foco en el futuro Manejo de situaciones
CSI Manager complejas
Process Owner Educación y experiencia
2.- ¿Qué puede SP internos o externos que Intelectual Análisis
Ud. medir? sepan de: Investigador Modelación
Service Manager Media o muy variada Actitud inventiva
Service Owner Orientada a Objetivos Educación
Process Owner Especializada en Programar trabajos
Process Manager Gestión de Negocios
3.- Recopilar Personal que suministre Estandarizada Exactitud
Datos servicios en: Rutinaria Previsión
Transición del Servicio y Automatizada Formación
Operación del Servicio tal Nivele Oficina Experiencia técnica
como Service Desk Procedimiento
4.- Proceso de Igual que paso 2 Especializada Habilidades numéricas
Datos Estructurada Metódico
Automatizada Exactitud
Media variación Formación
Procedimiento Programación
Experiencia con
herramientas
5.- Análisis de SP internos o externos que Igual que paso 2 Igual que paso 2
Datos sepan de:
Service Owner
Process Owner
y el Negocio de TI y su
análisis
6.- Presentar y SP internos o externos que Igual que paso 1 Igual que paso 1
usar la sepan de las posibilidades
información como:
Service Manager
Service Owner
Service Level Manager
CSI Manager
Process Owner
7.- Implementado Igual que paso 6 Igual que paso 2 Igual que paso 2
acciones
correctivas

7.6.9. Conexión entre el modelo de 6 pasos del impulso y el

proceso de los 7 pasos de mejora de CSI
6º
¿Cómo mantener
El impulso?
7.- Implantar
acciones
correctivas
Identificar : 5º Verificar
- La visión A
6.- Presentar y
- La Estrategia Usar la
- Los objetivos P Información
5.- Analizar
tácticos y los datos C
operativos. 4.- Procesar C Saber
los Datos
3.- Recopilar D
Datos Conocimiento
4º ¿Cómo D
conseguirla?
3º ¿Cuál es Planificar Información DIKW
La situación 2.- ¿Qué se
deseada? Puede
2º ¿Cuál es Medir? Datos Enfoque CSI
La Situación P ( Impulso )
Actual? Proceso de
1.- ¿Qué
SIP Mejora
Mediría? Línea de ( 7 Pasos )
1º¿Cuál es P referencia
la visión? (BL) P-D-C-A
7.6.10. Roles de CSI
7.6.10.1. Gestor de CSI

Desarrolla el dominio de CSI
Conciencia y comunica la importancia de CSI en toda la organización
Asigna los roles en CSI
Identifica oportunidades de mejora
Presenta esas oportunidades a la alta dirección
Prioriza las oportunidades en colaboración con el propietarios del servicio
Identifica requisitos de monitorización en colaboración con SLM
Garantiza la instalación de las herramientas de monitorización
Elabora los SIP’s en colaboración con SLM
Captura Líneas de Referencia con las que comparar
Define e informa los CSF, KPIs y métricas
Usa marcos de trabajo y modelos de soporte
Convierte la Gestión del Conocimiento en una rutina diaria
Evalúa los datos analizados

7.6.10.2. Propietario del Servicio

Titularidad y representación del servicio
Entendimiento de los componentes que conforman el servicio
Medición del rendimiento y la disponibilidad
Asistencia al CAB cuando sea requerido
Participación en revisiones externas e internas del servicio
Mantenimiento de datos en el Catálogo de Servicios
Participación en las SLAs y OLAs
7.6.10.3. Propietario del Proceso

Se encarga de garantizar que la organización siga un proceso
Debe de ser un gesto sénior con autoridad y credibilidad en la organización
7.6.10.4. Gestor del Conocimiento del Servicio

Diseña, mantiene e implementa una estrategia de Gestión de Conocimiento
7.6.10.5. Analista de Informes

Evalúa y analiza datos
Identifica tendencias
Debe ser un buen comunicador
7.6.10.6. Responsable de Comunicación

Diseña una buena estrategia de comunicación para CSI
7.6.11. Análisis de “gaps”

Determina la situación real de una organización y la diferencia con la situación en la que la
organización quiere situarse.
Pueden ser el resultado de una comparativa del servicio o de estudios sobre la madurez de
un servicio
Se pueden realizar a nivel estratégico, táctico u operativo
7.6.12. Análisis DAFO

Examina las Debilidades, Amenazas, Fortalezas y Oportunidades de una organización. Esto nos
permitirá responder a:
¿Cómo eliminar las debilidades?
¿Cómo gestionar y eliminar amenazas?
¿Cómo sacar partido a las fortalezas?
¿Cómo aprovechas las oportunidades?

7.6.13. Factores Críticos de Éxito para CSI

Designación de un gestor de CSI.
Adopción de CSI en toda la organización.
Participación constante y visible de la dirección en las actividades de CSI.
Criterios claros para proyectos de mejora.
Adopción de enfoque basado en el Ciclo de Vida del Servicio.
Disposición de recursos económicos.
Asignación de personal específico y no como añadido a su ya existente carga de trabajo.
Tecnología para actividades de mejora.
Adopción de procesos de Gestión de Servicios que no estén supeditados a criterios
personales.
7.6.14. Desafíos para CSI

Falta de compromiso de la alta dirección.
Mala relación entre el negocio y TI.
Falta de información sobre prioridades del negocio.
Falta de información, monitorización y medición.
Falte de recursos económicos y tiempo.
Inmadurez de los procesos de Gestión de Servicios.
Intentar de cambiarlo todo de una vez.
Resistencia a los cambios de cultura empresarial.
Falta de objetivos, estrategias y políticas.
Mala gestión de suministradores.
Ausencia de pruebas de validación.
Excesiva complejidad.
Falta de herramientas.
7.6.15. Riesgos para CSI

Exceso de ambición - no intente mejorar todo a la vez.
Falta de discusión de las oportunidades de mejora con el negocio - el negocio debe
involucrarse en las decisiones de mejora que le afectarán
Ausencia de un enfoque de mejora sobre los servicios y los procesos de gestión del servicio
Falta de asignación de prioridades a los proyectos de mejora
Implementación de una iniciativa de CSI sin recursos
Implementación de CSI sin la transferencia de conocimiento y formación
Ausencia de ejecución de todos los pasos del Proceso de Mejora en 7 Pasos
La toma de decisiones estratégicas, tácticas u operativas no se basan en el conocimiento
adquirido
Falta de iniciativa por parte de la Gerencia para recomendar oportunidades de mejora del
servicio
La campaña de comunicación/concienciación para las mejoras es deficiente, se realiza tarde
o no se realiza
No se involucra a las personas adecuadas en todos los niveles para planificar, crear, probar e
implementar la mejora


7.7. Gestión de Nivel de Servicio en la Mejora Continua de los

Servicios
SLM es el proceso más contribuye en la fase de CSI.
Este proceso negocia con el cliente sobre su negocio qué es lo que debe medir TI y qué
resultados obtener.
Al final de cada Ciclo de vida se debe monitorizar si la mejora continua se ha cumplido. Se
recomienda usar la Evaluación Post Implementación (PIR) del proceso de Gestión de
Cambios.
SLM participa en CSI en lo siguiente:
Qué se debe medir:
Consultar con el negocio para saber lo que quiere
Que se puede medir
Comprobar lo que ya se ha medido
Determinar lo que se puede medir y se debe medir (SLA, OLA, UC)
Recopilación de datos (medición)
Determinar quien recibe los datos y qué análisis son necesarios.
Procesamiento de datos
Evaluar los datos desde la perspectiva del negocio
Considerar la frecuencia con que se deben procesar los datos y comunicarlos
Análisis de datos
Compara los logros a Nivel de Servicio (rendimiento, resultados) con las SLAs
Identificar y registrar tendencias para formar posibles patrones
Determinar la necesidad de implementar SIP’s
Determinar si hay que ajustar OLAs y UCs
Presentación de la información
Generar informes y comunicárselos al negocio
Organizar evaluaciones internas y externas
Ayudar a priorizar actividades
Implementación de acciones correctivas
Elaborar un SIP junto a Gestión de Problemas y de la Disponibilidad y comprobar que la
organización sigue dicho plan.
7.7.1. Conceptos y Definiciones más comunes en SLM

Cliente: La empresa u organismo que contrata los Servicios de TI o un Departamento de
nuestra empresa.
Usuario: La persona que utiliza el Servicio. Toca el teclado.
Proveedor: La empresa u organismo que proporciona el Servicio solicitado por el cliente
externo o interno. Está certificado en la norma ISO 20000 o sigue las buenas prácticas de
ITIL®
Requisitos a Nivel de Servicio (SLR): El SLR incluye información detallada sobre las
necesidades del Cliente y sus expectativas de rendimiento. Es una Guía. Es la base para
desarrollar el SLA y posibles OLAs y UCs.

Acuerdos a Nivel de Servicio (SLA): Acuerdo entre la organización TI y un Cliente externo.

Describen los servicios a brindar desde la percepción del cliente. Documenta los Objetivos
de Nivel de Servicio y durante el tiempo que dure sirve de estándar para medir y ajustar los
servicios. Tienen estructura jerárquica. Vinculan legalmente y especifica las
responsabilidades del SP y el Cliente. Un único SLA puede cubrir varios servicios de TI o
varios Clientes.
Programa de Mejora de Servicio (SIP): Define las actividades, fases e hitos asociados con la
mejora de un servicio TI. Para los empleados de TI.
Plan de Calidad de Servicio (SQP): Documento que define los parámetros de los servicios a
brindar. El SLA es QUÉ entregaremos y SQP es CÓMO lo entregaremos. Define los
Indicadores Claves de Rendimiento (KPI) nuestros y de los de terceros que se definan en los
Contratos de Soporte (UC). Para los clientes
Acuerdo a Nivel de Operaciones (OLA): Acuerdo entre una Unidad de TI y otra parte de
nuestra misma organización TI. Detalla la provisión de los servicios que se proveen a los
Clientes así como los compromisos de ambas partes.
7.7.2. Programa de Mejora de Servicio (SIP)

Es un Plan formal para implementar mejoras en los procesos y en los servicios de TI.
Es una descripción del Servicio (Interno), responsabilidad y tiempos de entrega para alcanzar
los niveles de servicio acordados.
Va dirigidos a los empleados de TI y se documentan sus actividades con objeto de mejorar
los servicios de TI.
Usa Hojas de Especificación (Specsheets) con muy diversa información:
Responsable del proceso o Servicio
Persona a cargo de la iniciativa
Prioridad
Descripción
Fuentes de la medida
Caso de Negocio
Calendario de ejecución
Parámetros de procesos detallados y criterio.
Indicadores de Rendimiento (KPI) externos para clientes, ligados al Catálogo de Servicios
(SC) y Acuerdos de Nivel de Servicio (SLA).
Indicadores de Rendimiento (KPI) internos para procesos de Gestión de Servicio, ligados
a Acuerdos de Nivel Operacional (OLA) y Contratos Subyacentes (UC).
7.7.3. Requerimientos de Nivel de Servicio

Cubren las definiciones detalladas de las necesidades del cliente.
Es un documento interno.
Muy útiles para desarrollar, modificar y comenzar los servicios.
El SLR es una guía para el servicio y sus SLAs asociadas. Se alinea con ISO 9001 de
calidad

7.8. Informes de los Servicio

Entendiendo el orden de las personas previstas que se van a ocupar de analizar la información de los
procesos y logros de la mejora del servicio, así ha de prepararse la información (Reporting) para
presentar los problemas y las ventajas de su proceso.
En el más alto nivel de la organización están los Interesados estratégicos. Los informes
necesitan ser cortos, escuetos, rápidos de leer y alineados con sus responsabilidades
de visión y misión del Negocio.
El segundo orden o nivel consiste en vice presidentes y directores. Los informes
pueden ser más detallados, pero necesitan resumir resultados en un cierto plazo. La
identificación de cómo los procesos apoyan los objetivos del negocio, la pronta
detección de los problemas que ponen el Negocio en riesgo y la alineación a los
cuadros de trabajo, son métodos fuertes que usted puede utilizar para vender las
ventajas de proceso a la audiencia de ese nivel.
El tercer orden o nivel consiste en encargados y supervisores de alto nivel. La
conformidad a los objetivos indicados, el funcionamiento de los equipos técnicos y de
los procesos y las iniciativas continuas de la mejora son sus líneas maestras. Las
medidas y los informes sobre la posición en el mercado necesitan explicarse cómo
están siendo apoyados por las salidas de los procesos.
Y por último y en el cuarto nivel de la jerarquía están los miembros de personal y los
líderes de los equipo. A nivel personal, las ventajas personales necesitan ser
acentuadas. Por lo tanto las métricas que demuestran su funcionamiento individual,
proporcionan el reconocimiento de sus habilidades (y las diferencias en habilidades)
además de identificar oportunidades de formación que son esenciales para conseguir
que estos recursos humanos puedan participar en los procesos dispuestos.

Recopilación de datos.
Procesamiento de datos y aplicación a la organización.
Publicación de la Información.
Ajuste de los informes para el negocio.
Recopilación de datos: Los departamentos de TI recopilan enorme información de datos, pero no

todos ellos tienen el mismo interés para el negocio. Así pues hay que determinar el objetivo del
informe y al grupo al que va dirigido.
¿Lo leerán los directivos?
¿Qué pasará luego con el informe?
¿Habrá que presentarlos luego en una reunión?
¿Podrán los directivos y gestores consultarlo on line?

Procesamiento de datos y aplicación a la organización:

Al negocio se le presentas informes jerárquicos y por periodos, pero lo que de verdad le interesa es
saber que el evento pasado en qué forma va a afectar al presente y al futuro del negocio y que va a
hacer TI para combatir esta amenaza.
No hay que focalizar solo en el pasado, sino también en el futuro. TI tiene aquí la mejor oportunidad
de marketing para demostrar el valor que puede aportar al negocio y conectar con las experiencias
positivas y negativas del mismo.
Publicación de la Información:
La información se ha de publicar a todos los niveles de la organización y a las partes interesadas.
Cuantos incidentes se han resuelto al trimestre no ofrecerá mucho interés a los accionistas y al CSU
no le interesará cual ha sido el ROI. Lo general es presentar la información a tres grupos.
El negocio: Quiere saber si el SP de TI ha brindado los servicios acordados en el SLA. Si
no es así que medidas se han adoptado.
Dirección sénior de TI: Quiere saber si se han cumplido los KPIs y los CSF’s. Requiere el
Cuadro Integral de Mando.
Organización interna de TI: Quiere saber los KPIs y métricas para localizar, planificar y
coordinar planes de mejora.
Ajuste de los informes para el negocio: .Analizar cada grupo de datos con habilidad para saber si es
útil al grupo al que va dirigido.
Hay que estudiar el asunto con una perspectiva de extremo a extremo.
7.8.2. Resumen las Actividades de la Mejora Continua de los

Servicios
Monitorizar y re coleccionar datos
Procesar datos en grupos lógicos
Analizar datos para ver si cumplen los objetivos
Identificando tendencias
Identificando oportunidades de mejora
Una organización puede encontrar oportunidades de mejora a través del Ciclo de Vida entero del
servicio.
Una organización no necesita esperar hasta que el proceso de una Gestión de Servicios haga la
Transición del Servicio a Operaciones de Servicio para comenzar a identificar oportunidades de
mejora.
Las mejoras pueden ser incrementales por su naturaleza; pero también requerir una comisión
enorme para ejecutar un nuevo servicio o cumplir nuevos requisitos del Negocio.

7.8.3. Caso de Negocio (Business Case)

El Business Case (Caso de Negocio de Kaplan) es un documento empleado para evaluar o analizar el
impacto financiero y/o económico de una propuesta generada en una empresa y documentar los
aspectos más relevantes considerados al momento de hacer el análisis.
Un instrumento de toma de negocios, soporte y planificación que prevé las consecuencias probables
de una acción de negocio. (¿Si invierto en este activo, lo recupero y cuándo?)
Es una forma de justificar las iniciativas de Gestión de Servicios
El principio básico del análisis consiste en descomponer una acción comercial (como una campaña,
un evento o acciones de marketing directo) en sus procesos más relevantes, para analizar su
rendimiento y prever sus resultados.
Siete pasos para desarrollar un caso de negocio

1. El primer paso consiste en poner en contexto la acción que se desarrollará, en función
de la situación de mercado en que se encuentra la empresa y definir los objetivos
comerciales que se pretenden alcanzar.
2. En segundo lugar, se debe conceptualizar la acción. Para esto, es necesario analizarla
en función del posicionamiento global, el relevamiento de la competencia y un estudio
de segmentación de la demanda que nos permita fortalecer el modelo de negocio a
partir de la acción comercial que estamos desarrollando.
3. En tercer lugar, comenzamos a resumir la oferta comercial: establecer el precio, la
vigencia, los atributos del producto, los canales preferidos y las condiciones de acceso,
entre otros. Para esto, por supuesto, debemos conocer el comportamiento del
segmento al cual nos estamos dirigiendo. Así, podremos adaptar nuestra estrategia de
comunicación y explicar la elección del canal en función de las preferencias de los
consumidores.
4. La estrategia de comunicación, luego de resumir la oferta comercial, debemos diseñar
la estrategia de comunicación en función del segmento objetivo. Definir el estilo y el
tono de la comunicación, los conceptos a comunicar, las piezas gráficas y la estrategia
de medios.
5. En quinto lugar, debemos describir un proceso operativo en base a las oportunidades
detectadas en otras acciones comerciales referentes, que nos permita dimensionar la
capacidad actual en función de esas necesidades.
6. Acuerdos de servicio. Una vez que hemos logrado definir, contextualizar, establecer
tareas y responsables y la estrategia de comunicación, podremos coordinar los
distintos procesos y tareas mediante acuerdos de servicio entre los diferentes actores
responsables del plan de acción.
7. Finalmente, debemos presupuestar las acciones y calcular la rentabilidad de la
inversión, el plazo de recuperación, el ROI y el valor actual neto. Esto nos permitirá
identificar si la acción comercial justifica la inversión, si es factible, rentable y sinérgica
para la organización.
En definitiva, el Business Case permite plasmar diversos componentes en un documento que integra
y comparte visiones sobre la dinámica de toda la organización, resumiendo los procesos
fundamentales de una acción comercial.
Es un documento que registra la historia, consolida el trabajo de las distintas áreas y se convierte en
un instrumento fundamental en el proceso de toma de decisiones, que se retroalimenta, generando
valor para la empresa.

Se estructura de la siguiente forma:

Esquema General
Sumario ejecutivo
Introducción
Supuestos Métodos y Análisis
Alcances y Límites
Modelo Costo / Beneficio
Análisis Financiero
Riesgos, criticidad y contingencias
Conclusiones y Recomendaciones
7.8.4. Herramientas para Operaciones de TI que ayuden a CSI

Es necesario que una tecnología integrada incluya la siguiente funcionalidad central:
Autoayuda
Flujo de Trabajo o motor de procesos
CMS integrado
Tecnología de Descubrimiento, Despliegue y licenciamiento
Control remoto
Utilidades de diagnóstico
Generación de Informes
Paneles de Control
Una herramienta ITSM o conjunto de herramientas. Algunas organizaciones podrían
decidir integrar productos de diferentes proveedores o ir integrando módulos del mismo
proveedor
Herramientas de software para Incidencias

Herramientas de software para Problemas
Gestión de Sistemas de Red
Gestión de Eventos
Gestión del Conocimiento
Petición de Servicio
Gestión del Rendimiento
Resolución automatizada de Incidencias y Problemas
Monitorización de la aplicación y rendimiento del servicio
Herramientas de análisis estadísticos
Control de la versión del software
Gestión de la Configuración de Software
Gestión de las pruebas del software
Gestión de la Seguridad
Gestión de Proyectos y de la Cartera de Servicios
Gestión Financiera de Servicios de TI
Inteligencia de negocio
Generación de informes
7.8.5. Funcionalidades para Gestión de Eventos

Interfaz abierta para múltiples entornos que permita monitorizar y generar alertas
Fácil de desplegar, con mínimos costes de configuración
Agentes 'Estándar' para monitorizar la mayoría de los entornos, componentes y
sistemas
Interfaces abiertas para aceptar cualquier entrada de eventos estándar
Enrutamiento centralizado de todos los eventos a una única ubicación y programable
Soporte de las fases de diseño y prueba para que se puedan monitorizar nuevas
aplicaciones y servicios durante las fases de diseño/prueba
Evaluación programable y tratamiento de alertas dependiendo de los síntomas y del
impacto
La capacidad para que un operador reconozca una alerta y reaccionar ante ella, y si no
se da ninguna respuesta en una franja de tiempo definida, escalar la alerta
Buena funcionalidad de generación de informes
7.8.6. Funcionalidades para Gestión de Incidencias

Un CMS integral para la creación y mantenimiento de relaciones entre incidencias,
peticiones de servicio, problemas, KEs y CIs de forma automática
Un CMS que pueda ayudar a determinar la prioridad, diagnóstico e investigación
Un motor de flujo de proceso que permita generar modelos de proceso y controlarlos
para encaminamiento interno para los grupos de soporte y con interfaces externas de
correo electrónico/SMS
Capacidades de escalado y de alerta automáticos para evitar retrasos de incidencias
Interfaz con herramientas de Gestión de Eventos para que los fallos puedan plantearse
automáticamente como incidencias
Una interfaz web que permita autoayuda y que las peticiones de servicio entren a
través de pantallas de Internet / Intranet
Una KEDB integrada para que los problemas, incidencias resueltas o diagnosticadas se
puedan registrar para acelerar la resolución de futuras incidencias
Facilidades de generación de informes para permitir generar métricas de incidencias y
facilitar análisis de incidencias para propósitos de Gestión de Problemas y Gestión de la
Disponibilidad.

7.8.7. Funcionalidades para Gestión de Peticiones

Hay disponibles en el mercado diversas tecnologías integradas de ITSM que permiten
que las Peticiones de Servicio se puedan vincular con incidencias o con eventos que las
hayan iniciado y que se almacenen en el mismo CMS
Las organizaciones podrían estar satisfechas con el uso software de Gestión de
Incidencias de tales herramientas y con el tratamiento de las Peticiones de Servicio
como un subconjunto y categoría definidos de incidencias
Las capacidades de Autoayuda del front-end serán necesarias para que los usuarios
puedan enviar sus peticiones a través de un canal predefinido para el proceso de
selección, y que esté dirigido por menús basados en web
7.8.8. Funcionalidades para Gestión de Problemas y Cambios

Será necesario una herramienta de ITSM integrada que diferencie entre incidencias y
problemas para poder crear Registros de Problemas independientes de las incidencias,
aunque vinculados con las incidencias relacionadas. La funcionalidad de los Registros
de Problemas deberá ser similar a los Registros de Incidencias, y también deberá
permitir la correspondencia de múltiples incidencias con respecto a Registros de
Problemas
Una KEDB eficaz es un requisito, pues debe facilitar el almacenamiento y recuperación
de los datos de Errores Conocidos
Será necesario disponer de utilidades para crear informes de gestión, que permita
cargar datos automáticamente
Se debe integrar con Gestión de Cambios, para que los Registros de Peticiones,
Eventos, Incidencias y Problemas puedan asociarse con las RFCs que hayan causado
problemas
7.8.9. Funcionalidades para Gestión de Accesos

Tecnología de Gestión de Recursos Humanos para validar la identidad de los usuarios y
hacer el seguimiento de su estado
Tecnología de Servicios de Directorio que permita a los responsables asignar nombres a
recursos en una red y a proporcionar acceso a esos recursos basándose en el perfil del
usuario (UP)
Las herramientas de Servicios de Directorio también permiten que la Gestión de
Accesos cree roles y grupos y los vincule con usuarios y recursos
Funcionalidades de Gestión de Accesos en Aplicaciones, Middleware, Sistemas
Operativos y Sistemas Operativos en Red
Sistemas de Gestión de Cambios
Tecnología de Gestión de Peticiones

7.8.10. Funcionalidades para Gestión de Redes

Gestión de Red también es responsable, a veces junto con Soporte al Puesto de
Trabajo, de conectividad remota como las funcionalidades de recepción y devolución
de llamadas, VPN para los tele trabajadores, trabajadores remotos y proveedores.
Algunos equipos o departamentos de Gestión de Red también son responsables de los
servicios de voz/telefonía, incluyendo la provisión y soporte de correos, líneas, ACD,
paquetes de software estadístico, etc., y de los sistemas de Voz sobre el Protocolo de
Internet (VolP) y de Monitorización Remota (Rmon)
7.8.11. Funcionalidades para SACM

Identificar, controlar, registrar, informar, auditar, y verificar activos del servicio y CIs,
incluyendo versiones, líneas de referencia (BL), sus atributos y relaciones
Gestionar y proteger la integridad de los activos del servicio y de los CIs, y si es
apropiado, los de sus clientes, a lo largo del Ciclo de Vida del Servicio, garantizando que
sólo se utilicen componentes autorizados y que sólo se realicen cambios autorizados
Garantizar la integridad de los activos y de las configuraciones requeridas para
controlar los servicios y la infraestructura de TI, estableciendo y manteniendo un
Sistema de Gestión de la Configuración (CMS)
7.8.12. Herramientas para de Gestión del Rendimiento de TI

Herramientas que permiten el análisis de rendimiento de la capacidad de respuesta, de
transacciones y el tráfico y los niveles de utilización, para promover el equilibrio de los
recursos para optimizar el rendimiento de los servicios de TI
Que permitan la evaluación de la carga de trabajo con el análisis de tendencias de
crecimiento futuro y la capacidad necesarias para cada uno de los servicios de TI que se
prestan
Que construyan perfiles de uso de desempeño, recursos y datos, permitiendo
comparar la utilización real con los modelos previstos
Generación de los datos necesarios para informar sobre los SLA, identificar
oportunidades de mejora para incluir en el registro de CSI, y para la confección de
Planes de Mejora de los Servicios (SIP)
7.8.13. Herramientas para Análisis Estadísticos

La mayoría de las herramientas que están disponibles en el mercado para dar soporte a
ITSM y entornos de sistemas de gestión proporcionan capacidades de informes, pero
esto no suele ser suficiente para apoyar la Gestión de la Disponibilidad y de Gestión de
la Capacidad
Los datos en bruto de muchos de las anteriores herramientas tienen que ser
capturados en un repositorio único para el análisis colectivo
Estos datos proporcionan la entrada a Gestión de la Demanda, a Gestión de la
Disponibilidad y a Gestión de la Capacidad, para dar soporte al análisis de MTRS y
MTBF
También para el análisis de la carga de trabajo, el modelado de servicios,
dimensionamiento de aplicaciones y sus oportunidades para la mejora

7.8.14. Herramientas para Gestión de la Cartera

Estas herramientas ayudan al registro, a la toma de decisiones sobre costes, gestión de
recursos, a la visibilidad de la Cartera de Servicios y Gestión de Proyectos de nuevas
funcionalidades de negocios y los servicios y sistemas que los sustentan
Estas herramientas se utilizan normalmente para gestionar los aspectos relacionados
con el negocio de las TI
Los puntos de integración en general incluyen: la asignación de tareas para las
actividades de desarrollo, el cambio y la versión de despliegue de información sobre la
base de la cartera de contratos, captura de datos de los recursos de ITSM, el total coste
de propiedad (TCO) de la Cartera de Servicios, y los datos de utilización de recursos
para la Gestión Financiera de Servicios de TI
7.8.15. Herramientas de Gestión Financiera de Servicios de TI

Las herramientas de Gestión Financiera de Servicios de TI disponibles en el mercado,
permiten el control de presupuestos, contabilidad y análisis del ROI, además de otros
aspectos relacionados con el manejo de efectivo para el negocio
La Gestión Financiera es un proceso crítico en la misión de los servicios de TI, pues
tiene que asegurar que haya suficientes recursos financieros para mantener y
desarrollar la infraestructura de TI y las capacidades profesionales de soporte a las
necesidades actuales y futuras del negocio
Un presupuesto equilibrado en TI es necesario a través de la recuperación de los costes
de TI, con una sólida comprensión de los aspectos fiscales de sus operaciones, para
permitir a los ejecutivos de TI justificar sus gastos en los servicios de negocio a los que
den soporte
7.8.16. Inteligencia del Negocio / Información

Además de que para un entorno de análisis estadístico se requiera un conjunto de
herramientas para dar soporte a los datos técnicos, también se tiene necesidad de que
exista un repositorio común de todos los servicios de información y datos relacionados
con la empresa
A menudo estas herramientas son proporcionadas por los mismos vendedores que dan
soporte al software de análisis estadístico, pero el enfoque en este caso es
proporcionar datos relacionados con el negocio de todos los conjuntos de
herramientas que existan en la organización, lo que representa una guía para dirigir las
actividades, de TI en su conjunto, en apoyo de la empresa de los clientes

7.9. Por dónde empezar a implementar CSI

Antes de implementar CSI es importante haber identificado y designado los roles que se
han descrito en la Unidad CSI05. Entre ellos se incluye un Gestor de CSI, Propietario del
Servicio y analista de informes. Es necesario que haya un Gestor de Nivel de Servicio que
sirva de enlace entre el negocio y TI.
Debe haber monitorización y generación de informes sobre las métricas de la tecnología,
de los procesos y del servicio.
¿Dónde comenzar? – Enfoque en el servicio
Lo fundamental es empezar por algún sitio. Si piensa que no cuenta con datos
adecuados de ningún monitor u otro proceso, entonces el primer paso es identificar
qué monitorizar, definir los requisitos de monitorización y comenzar a utilizar la
tecnología necesaria para monitorizar.
¿Dónde comenzar? – Enfoque en el Ciclo de Vida
Otro enfoque es comenzar el análisis en la transferencia de la salida de los diferentes
dominios del ciclo de vida. El Diseño del Servicio tiene que monitorizar e informar
sobre las actividades y, a través de la evaluación y análisis de tendencias, identificar las
oportunidades de mejora a implementar. Esto debe realizarse en cada parte del ciclo
de vida, y más en el Diseño del Servicio, Transición del Servicio y Operación del
Servicio. CSI se implica en esta actividad. Es posible que no conozcamos si hemos
elegido la estrategia correcta hasta que el servicio esté implementado, por lo que es
posible que no recibamos información para la mejora de la Estrategia del Servicio hasta
ese momento.
Dónde comenzar? - Enfoque en el grupo funcional
Puede que su organización esté experimentando fallos o problemas con los servidores.
Si fuera el caso, es buena idea centrar las actividades de CSI dentro del grupo funcional
responsable de los servidores, pues los fallos de los servidores provocan un impacto
negativo sobre la disponibilidad del servicio.
Esto sólo sería una solución a corto plazo, puesto que las actividades de CSI deberían
revisar las actividades desde una perspectiva extremo a extremo; no obstante, a
menudo es más fácil tener a un grupo reducido centrado en las actividades de CSI.
7.9.1. Reingeniería de los Procesos

La implementación de CSI afectará a muchas partes de la organización de TI. Los procesos, las
personas, la tecnología y la gestión experimentarán cambios. CSI tiene que convertirse en una forma
de vida dentro de la organización. Esto puede requerir una nueva estructura de gestión, nueva
tecnología, cambios en los procesos para dar apoyo a CSI, y las personas deberán recibir formación y
comprender la importancia de CSI dentro de la organización.
CSI no será eficaz si solo se centra en cambiar un proceso o tecnología.

 Punto único de  Gestión del Compromiso

responsabilidad  Gestión de la Participación
 Grupo lógico de actividades  Compensación / Recompensas
 Interdepartamental  Valores / Creencias
 Procedimientos definidos Procesos  Coaching / Facilitador
 Repetibles y consistentes  Oportunidades profesionales
 Estándares Globales  Diseño Organizativo
Personas Gestión
 Habilidades mejoradas  Facilitación del trabajo en Equipo

 Equipos Multifuncionales  Herramientas de Gestión
 Valores / Creencias Tecnología de Servicios
 Predisposiciones culturales  Compartición de Datos Integrada
 Formación  Gestión del conocimiento
 Desarrollo profesional  Gestión de la Información
7.9.2. Gestión del Cambio de la organización y de los interesados

Qué problemas resuelve el cambio propuesto?
¿Qué ofrece el servicio nuevo o modificado?
¿Cómo es necesario modificar las actividades actuales?
¿Cuáles son los objetivos del cambio definidos por la dirección?
¿Quién estará implicado y quién no lo estará previsiblemente?
¿Quién se verá afectado dentro y fuera de la organización?
¿Cuál es la escala de tiempo planificada?
¿Quién ayuda en la planificación de la implementación?
¿Qué habilidades y medidas deben considerarse?
¿Cómo se verá afectada la vida 'normal'?
7.9.3. Productos del cambio organizativo

Correspondencia de los interesados
Evaluación de la organización y habilidades actuales
Modelo de competencias requerido y actual, y evaluaciones de las competencias
Restricciones (incluyendo la organización, habilidades, recursos)
Modelo de proceso de Gestión del Servicio
Políticas, procesos y procedimientos
Roles y definiciones de responsabilidades, por ejemplo, una matriz RACI (Encargado,
Responsables, Consultados e Informados)
Gestión de relaciones con el negocio
Plan de comunicación
Marco de trabajo de suministradores, específicamente si hay múltiples suministradores
implicados

7.9.4. Estrategias del cambio organizativo

El proceso de Transición del Servicio estará interesado en las estrategias propuestas para gestionar
el cambio organizativo. Éstas podrán utilizarse para evaluar el método de Diseño del Servicio,
gestionar el cambio durante Transición del Servicio y para identificar los problemas y riesgos
asociados con el cambio organizativo.
Kotter y Schlesinger (1979) sugirieron las siguientes estrategias que funcionan bien en la práctica y
que se exponen en esta diapositiva
 Educación y compromiso
 Participación e implicación
 Facilitación y soporte Kotter y Schlesinger
 Negociación y acuerdo
 Manipulación y cooptación
 Coacción explícita e implícita
 Pérdida de control
 Excesiva incertidumbre del personal
 Evitar sorpresas
 El efecto de la diferencia Moss Kanter
 Pérdida de credibilidad
 Temor con respecto a la competencia
 Efectos en cadena
 Aumento de la carga de trabajo
 Antiguos resentimientos
 Amenazas reales
7.9.5. Estrategias y Plan de comunicación

Definición de un plan de comunicación
¿Quién es el mensajero? – No todos
¿Cuál es el mensaje? – No exagerar
¿Quién es la audiencia objetivo?
Puntualidad y frecuencia de la comunicación
Método de comunicación
Proporcionar un mecanismo de retroalimentación

7.9.6. La Visión se vuelve confusa

La iniciativa de CSI se transmite en cascada desde el nivel estratégico hasta el nivel táctico y después
hasta el operativo. Es normal que cada nivel experimente su propio proceso de transformación.
Es importante que se envíe y se reciba el mismo mensaje a medida que se comunique la visión hacia
abajo en la organización. El resultado de este proceso es la causa y, frecuentemente, la petición de
transformación al siguiente nivel en una organización.
Ocasionalmente se transmite hacia abajo la información sobre este proceso y sobre cómo las
personas lo abordan. Desafortunadamente, el nivel superior proporciona muy poca
retroalimentación sobre este proceso al siguiente nivel.
También puede ocurrir que el entendimiento del contenido de la visión y las razones que justifican el
cambio organizativo se dificulte a medida que se vaya comunicando hacia abajo a través de la
organización. Sólo algunas partes de los fundamentos que respaldan el cambio organizativo llegan
hasta el nivel operativo. La siguiente figura ilustra el hecho de que sólo una parte del contenido
original de la visión se transmite hacia abajo ('la sombra del nivel superior') hasta el nivel operativo.
A medida que el mensaje se transmite a través de los niveles organizativos, la claridad y el contenido
de la visión se vuelven aún más ambiguos.
Visión
Líneas de Comunicación
Transformación
Estratégica
Táctica Transformación
Operativa Transformación
El desarrollo de una estructura de gobierno es importante para la formalización de CSI en su

organización. En CSI, será necesario que las funciones clave tengan informes de tendencias de
evaluación, análisis y toma de decisiones.
El cumplimiento de procesos es fundamental para garantizar la salida adecuada para las métricas de
proceso que se utilizará para la identificación de iniciativas de mejora de procesos.
La comunicación es fundamental para ayudar a cambiar el comportamiento de los empleados y será
necesario identificar el público objetivo, quien es el mensajero, el mensaje que se comunica y la
manera mejor de comunicar el mensaje.

Estrategia ejecutiva
2. - ¿Dónde (Objetivos, Nuevas direcciones)
queremos estar? Objetivos de Servicio (Optimización
Datos de la Línea de de la integración de procesos a nivel
referencia de valor añadido) Benchmarks
Promotores ejecutivos externos
Evaluación Interna o Externa Patrocinadores
Informe de la Mejora Continua Gestión Senior
Conclusiones de Auditorías Gestor de la Mejora Continua de
Internas (Corporativas) ITSM
Planificació
n 3. ¿Cómo Reunión del responsable del
Estrategia proceso
1. - ¿Dónde estamos de TI llegar?
Lista de acciones de mejora
ahora? Servicios continua
Procesos de Gestor de la MejoraRevisión
Continuadel
de estado
ITSM del
patrocinador
Responsable de Procesos/Gestores de
Gestor de la Mejora Continua de Gestión del
ITSM Servicio del
Operaciones Procesos
Patrocinador Centro de Gestores de Infraestructura
Propietarios de los Procesos proceso de
Datos
Métricas de Servicio 4.- ¿Estamos

Métricas de la mejorando?
Tecnología
Métrica de los KPI de Proceso e Informe de Gestión
Procesos Planes de Mejora del Servicio
Actualización de la lista de Acciones de Mejora
ENTRADAS Continua
(asignación y re-priorización)
Gestor de la Mejora Continua de ITSM
ACTIVIDAD Responsable de Procesos/Gestores de
Proceso
ROLES


Glosario por orden alfabético Inglés .8
Términos y Definiciones
Term Definition
Acceptance Formal agreement that an TI Service, Process, Plan, or other Deliverable is
complete, accurate, Reliable and meets its specified Requirements. Acceptance
is usually preceded by Evaluation or Testing and is often required before
proceeding to the next stage of a Project or Process.
See Service Acceptance Criteria.
Access (Service Operation) The Process responsible for allowing Users to make use
Management of TI Services, data, or other Assets. Access Management helps to protect the
Confidentiality, Integrity and Availability of Assets by ensuring that only
authorized Users are able to access or modify the Assets. Access Management
is sometimes referred to as Rights Management or Identity Management.
Account (Service Strategy) A Role that is very similar to Business Relationship

Manager Manager, but includes more commercial aspects. Most commonly used when
dealing with External Customers.
Accounting (Service Strategy) The Process responsible for identifying actual Costs of
delivering TI Services, comparing these with budgeted costs, and managing
variance from the Budget.
Accredited Officially authorised to carry out a Role. For example an Accredited body may
be authorised to provide training or to conduct Audits.
Active (Service Operation) Monitoring of a Configuration Item or an TI Service that

Monitoring uses automated regular checks to discover the current estado.
See Passive Monitoring.
Actividad A set of actions designed to achieve a particular result. Activities are usually
defined as part of Processes or Plans, and are documented in Procedures.
Agreed Service (Service Design) A synonym for Service Hours, commonly used in formal
Time calculations of Availability. See Downtime.
Agreement A Document that describes a formal understanding between two or more

parties. An Agreement is not legally binding, unless TI forms part of a Contract.
See Service Level Agreement, Operational Level Agreement.
Alert (Service Operation) A warning that a threshold has been reached, something
has changed, or a Failure has occurred. Alerts are often created and managed
by System Management tools and are managed by the Event Management
Process.

Term Definition
Analytical (Service Strategy) (Service Design) (Continual Service Improvement) A
Modelling technique that uses mathematical Models to predict the behaviour of a
Configuration Item or TI Service. Analytical Models are commonly used in
Capacity Management and Availability Management.
See Modelling.
Application Software that provides Functions that are required by an TI Service. Each
Application may be part of more than one TI Service. An Application runs on one
or more Servers or Clients.
See Application Management, Application Portfolio.
Application (Service Design) (Service Operation) The Function responsible for managing
Management Applications throughout their Lifecycle.
Application (Service Design) A database or structured Document used to manage

Portfolio Applications throughout their Lifecycle. The Application Portfolio contains key
Attributes of all Applications. The Application Portfolio is sometimes
implemented as part of the Service Portfolio, or as part of the Configuration
Management System.
Application (Service Design) An External Proveedor de Servicios that provides TI Services

Proveedor de using Applications running at the Proveedor de Servicios's premises. Users
Servicios (ASP) access the Applications by network connections to the Proveedor de Servicios.
Application (Service Design) The Actividad responsible for understanding the Resource
Sizing Requirements needed to support a new Application, or a major Change to an
existing Application. Application Sizing helps to ensure that the TI Service can
meet its agreed Service Level Targets for Capacity and Performance.
Architecture (Service Design) The structure of a System or TI Service, including the

Relationships of Components to each other and to the environment they are in.
Architecture also includes the Standards and Guidelines which guide the design
and evolution of the System.
Assembly (Service Transition) A Configuration Item that is made up from a number of

other CIs. For example a Server CI may contain CIs for CPUs, Disks, Memory
etc.; an TI Service CI may contain many Hardware, Software and other CIs.
See Component CI, Build.
Assessment Inspection and analysis to check whether a Standard or set of Guidelines is

being followed, that Records are accurate, or that Efficiency and Effectiveness
targets are being met.
See AudTI.
Asset (Service Strategy) Any Resource or Capability. Assets of a Proveedor de Servicios include
anything that could contribute to the delivery of a Service. Assets can be one of the following types:
Management, Organisation, Process, Knowledge, People, Information, Applications, Infrastructure,
and Financial Capital.
Asset (Service Transition) Asset Management is the Process responsible for tracking
Management and reporting the value and ownership of financial Assets throughout their
Lifecycle. Asset Management is part of an overall Service Asset and
Configuration Management Process.
See Asset Register.
Asset Register (Service Transition) A list of Assets, which includes their ownership and value.
The Asset Register is maintained by Asset Management.

Term Definition
Attribute (Service Transition) A piece of information about a Configuration Item.
Examples are name, location, Version number, and Cost. Attributes of CIs are
recorded in the Configuration Management Database (CMDB).
See Relationship.
Audit Formal inspection and verification to check whether a Standard or set of

Guidelines is being followed, that Records are accurate, or that Efficiency and
Effectiveness targets are being met. An Audit may be carried out by internal or
external groups.
See Certification, Assessment.
Authority Matrix Synonym for RACI.
Automatic Call (Service Operation) Use of Information Technology to direct an incoming

Distribution telephone call to the most appropriate person in the shortest possible time. ACD
(ACD) is sometimes called Automated Call Distribution.
Availability (Service Design) Ability of a Configuration Item or TI Service to perform its

agreed Function when required. Availability is determined by Reliability,
Maintainability, Serviceability, Performance, and Security. Availability is usually
calculated as a percentage. This calculation is often based on Agreed Service
Time and Downtime. TI is Best Practice to calculate Availability using
measurements of the Business output of the TI Service.
Availability (Service Design) The Process responsible for defining, analysing, Planning,
Management measuring and improving all aspects of the Availability of TI Services.
Availability Management is responsible for ensuring that all TI Infrastructure,
Processes, Tools, Roles etc are appropriate for the agreed Service Level
Targets for Availability.
Availability (Service Design) A virtual repository of all Availability Management data,

Management usually stored in multiple physical locations.
Information See Service Knowledge Management System.
System (AMIS)
Availability Plan (Service Design) A Plan to ensure that existing and future Availability
Requirements for TI Services can be provided Cost Effectively.
Back-out Synonym for Remediation.
Backup (Service Design) (Service Operation) Copying data to protect against loss of
Integrity or Availability of the original.
Balanced (Continual Service Improvement) A management tool developed by Drs.

Scorecard Robert Kaplan (Harvard Business School) and David Norton. A Balanced
Scorecard enables a Strategy to be broken down into Key Performance
Indicators. Performance against the KPIs is used to demonstrate how well the
Strategy is being achieved. A Balanced Scorecard has 4 major áreas, each of
which has a small number of KPIs. The same 4 áreas are considered at different
levels of detail throughout the Organisation.

Term Definition
Baseline (Continual Service Improvement) A Benchmark used as a reference point. For
example:
 An ITSM Baseline can be used as a starting point to measure the effect of
a Service Improvement Plan
 A Performance Baseline can be used to measure changes in Performance
over the lifetime of an TI Service
 A Configuration Management Baseline can be used to enable the TI
Infrastructure to be restored to a known Configuration if a Change or
Release fails
Benchmark (Continual Service Improvement) The recorded state of something at a

specific point in time. A Benchmark can be created for a Configuration, a
Process, or any other set of data. For example, a benchmark can be used in:
 Continual Service Improvement, to establish the current state for managing
improvements.
 Capacity Management, to document Performance characteristics during
normal operations.
 See Benchmarking, Baseline.
Benchmarking (Continual Service Improvement) Comparing a Benchmark with a Baseline or

with Best Practice. The term Benchmarking is also used to mean creating a
series of Benchmarks over time, and comparing the results to measure progress
or improvement.
Best Practice Proven Activities or Processes that have been successfully used by multiple
Organisations. ITIL® is an example of Best Practice.
Brainstorming (Service Design) A technique that helps a team to generate ideas. Ideas are
not reviewed during the Brainstorming session, but at a later stage.
Brainstorming is often used by Problem Management to identify possible
causes.
British The UK National Standards body, responsible for creating and maintaining
Standards British Standards. See http://www.bsi-global.com for more information.
Institution (BSI) See ISO.
Budget A list of all the money an Organisation or Business Unit plans to receive, and
plans to pay out, over a specified period of time.
See Budgeting, Planning.
Budgeting The Actividad of predicting and controlling the spending of money. Consists of a
periodic negotiation cycle to set future Budgets (usually annual) and the day-to-
day monitoring and adjusting of current Budgets.
Build (Service Transition) The Actividad of assembling a number of Configuration

Items to create part of an TI Service. The term Build is also used to refer to a
Release that is authorised for distribution. For example Server Build or laptop
Build.
See Configuration Baseline.
Build (Service Transition) A controlled Environment where Applications, TI Services

Environment and other Builds are assembled prior to being moved into a Test or Live
Environment.

Term Definition
Business (Service Strategy) An overall corporate entity or Organisation formed of a
number of Unidades de Negocio. In the context of ITSM, the term Business
includes public sector and not-for-profit organisations, as well as companies. An
TI Proveedor de Servicios provides TI Services to a Customer within a
Business. The TI Proveedor de Servicios may be part of the same Business as
their Customer (Internal Proveedor de Servicios), or part of another Business
(External Proveedor de Servicios).
Business (Service Design) In the context of ITSM, Business Capacity Management is the
Capacity Actividad responsible for understanding future Business Requirements for use in
Management the Capacity Plan.
(BCM)
See Service Capacity Management.
Business Case (Service Strategy) Justification for a significant item of expenditure. Includes
information about Costs, benefits, options, issues, Risks, and possible
problems.
See Cost Benefit Analysis.
Business (Service Design) The Business Process responsible for managing Risks that
Continuity could seriously impact the Business. BCM safeguards the interests of kee
Management Interesados, reputation, brand and value creating activities. The BCM Process
(BCM)
involves reducing Risks to an acceptable level and planning for the recovery of
Business Processes should a disruption to the Business occur. BCM sets the
Objetivos, Scope and Requirements for TI Service Continuity Management.
Business (Service Design) A Plan defining the Pasos required to Restore Business
Continuity Plan Processes following a disruption. The Plan will also identify the triggers for
(BCP) Invocation, people to be involved, communications etc. TI Service Continuity
Plans form a significant part of Business Continuity Plans.
Business (Service Strategy) A recipient of a product or a Service from the Business. For
Customer example if the Business is a car manufacturer then the Business Customer is
someone who buys a car.
Business Impact (Service Strategy) BIA is the Actividad in Business Continuity Management that
Analysis (BIA) identifies Vital Business Functions and their dependencies. These
dependencies may include Suppliers, people, other Business Processes, TI
Services etc.
BIA defines the recovery requirements for TI Services. These requirements
include Recovery Time Objetivos, Recovery Point Objetivos and minimum
Service Level Targets for each TI Service.
Business (Service Strategy) The Objetivo of a Business Process, or of the Business as a

Objetivo whole. Business Objetivos support the Business Vision, provide guidance for the
TI Strategy, and are often supported by TI Services.
Business (Service Strategy) The day-to-day execution, monitoring and management of

Operations Business Processes.
Business (Continual Service Improvement) An understanding of the Proveedor de

Perspective Servicios and TI Services from the point of view of the Business, and an
understanding of the Business from the point of view of the Proveedor de
Servicios.

Term Definition
Business A Process that is owned and carried out by the Business. A Business Process
Process contributes to the delivery of a product or Service to a Business Customer. For
example, a retailer may have a purchasing Process which helps to deliver
Services to their Business Customers. Many Business Processes rely on TI
Services.
Business (Service Strategy) The Process or Function responsible for maintaining a

Relationship Relationship with the Business. BRM usually includes:
Management  Managing personal Relationships with Business managers
 Providing input to Service Portfolio Management
 Ensuring that the TI Proveedor de Servicios is satisfying the Business
needs of the Customers
This Process has strong links with Service Level Management.
Business (Service Strategy) A Role responsible for maintaining the Relationship with one
Relationship or more Customers. This Role is often combined with the Service Level
Manager (BRM) Manager Role.
See Account Manager.
Business An TI Service that directly supports a Business Process, as opposed to an

Service Infrastructure Service which is used internally by the TI Proveedor de Servicios
and is not usually visible to the Business.
The term Business Service is also used to mean a Service that is delivered to
Business Customers by Unidades de Negocio. For example delivery of financial
services to Customers of a bank, or goods to the Customers of a retail store.
Successful delivery of Business Services often depends on one or more TI
Services.
Business (Service Strategy) (Service Design) An approach to the management of TI

Service Services that considers the Business Processes supported and the Business
Management value provided.
(BSM) This term also means the management of Business Services delivered to
Business Customers.
Business Unit (Service Strategy) A segment of the Business which has its own Plans,
Metrics, income and Costs. Each Business Unit owns Assets and uses these to
create value for Customers in the form of goods and Services.
Call (Service Operation) A telephone call to the Service Desk from a User. A Call
could result in an Incident or a Service Request being logged.
Call Centre (Service Operation) An Organisation or Business Unit which handles large
numbers of incoming and outgoing telephone calls.
See Service Desk.
Call Type (Service Operation) A Category that is used to distinguish incoming requests to
a Service Desk. Common Call Types are Incident, Service Request and
Complaint.
Capability (Service Strategy) The ability of an Organisation, person, Process, Application,

Configuration Item or TI Service to carry out an Actividad. Capabilities are
intangible Assets of an Organisation.
See Resource.

Term Definition
Capability (Continual Service Improvement) The Capability Maturity Model for Software
Maturity Model (also known as the CMM and SW-CMM) is a model used to identify Best
(CMM) Practices to help increase Process Maturity. CMM was developed at the
Software Engineering Institute (SEI) of Carnegie Mellon University. In 2000, the
SW-CMM was upgraded to CMMI® (Capability Maturity Model Integration). The
SEI no longer maintains the SW-CMM model, its associated appraisal methods,
or training materials.
Capability (Continual Service Improvement) Capability Maturity Model® Integration

Maturity Model (CMMI) is a process improvement approach developed by the Software
Integration Engineering Institute (SEI) of Carnegie Melon University. CMMI provides
(CMMI)
organizations with the essential elements of effective processes. TI can be used
to guide process improvement across a project, a division, or an entire
organization. CMMI helps integrate traditionally separate organizational
functions, set process improvement Metas and priorities, provide guidance for
quality processes, and provide a point of reference for appraising current
processes. See http://www.sei.cmu.edu/cmmi/ for more information.
See CMM, Continuous Improvement, Maturity.
Capacity (Service Design) The maximum Throughput that a Configuration Item or TI

Service can deliver whilst meeting agreed Service Level Targets. For some
types of CI, Capacity may be the size or volume, for example a disk drive.
Capacity (Service Design) The Process responsible for ensuring that the Capacity of TI
Management Services and the TI Infrastructure is able to deliver agreed Service Level
Targets in a Cost Effective and timely manner. Capacity Management considers
all Resources required to deliver the TI Service, and plans for short, medium
and long term Business Requirements.
Capacity (Service Design) A virtual repository of all Capacity Management data, usually
Management stored in multiple physical locations.
Information See Service Knowledge Management System.
System (CMIS)
Capacity Plan (Service Design) A Capacity Plan is used to manage the Resources required to
deliver TI Services. The Plan contains scenarios for different predictions of
Business demand, and costed options to deliver the agreed Service Level
Targets.
Capacity (Service Design) The Actividad within Capacity Management responsible for
Planning creating a Capacity Plan.
Capital (Service Strategy) The Cost of purchasing something that will become a
Expenditure financial Asset, for example computer equipment and buildings. The value of the
(CAPEX) Asset is Depreciated over multiple accounting periods.
Capital Item (Service Strategy) An Asset that is of interest to Financial Management

because TI is above an agreed financial value.
Capitalization (Service Strategy) Identifying major Cost as capital, even though no Asset is
purchased. This is done to spread the impact of the Cost over multiple
accounting periods. The most common example of this is software development,
or purchase of a software license.
Category A named group of things that have something in common. Categories are used
to group similar things together. For example Cost Types are used to group
similar types of Cost. Incident Categories are used to group similar types of
Incident, CI Types are used to group similar types of Configuration Item.

Term Definition
Certification Issuing a certificate to confirm Compliance to a Standard. Certification includes
a formal Audit by an independent and Accredited body. The term Certification is
also used to mean awarding a certificate to verify that a person has achieved a
qualification.
Change (Service Transition) The addition, modification or removal of anything that

could have an effect on TI Services. The Scope should include all TI Services,
Configuration Items, Processes, Documentation etc.
Change Advisory (Service Transition) A group of people that advises the Change Manager in the
Board (CAB) Assessment, prioritisation and scheduling of Changes. This board is usually
made up of representatives from all áreas within the TI Proveedor de Servicios,
the Business, and Third Parties such as Suppliers.
Change Case (Service Operation) A technique used to predict the impact of proposed
Changes. Change Cases use specific scenarios to clarify the scope of proposed
Changes and to help with Cost Benefit Analysis.
See Use Case.
Change History (Service Transition) Information about all changes made to a Configuration
Item during its life. Change History consists of all those Change Records that
apply to the CI.
Change (Service Transition) The Process responsible for controlling the Lifecycle of all
Management Changes. The primary Objetivo of Change Management is to enable beneficial
Changes to be made, with minimum disruption to TI Services.
Change Model (Service Transition) A repeatable way of dealing with a particular Category of
Change. A Change Model defines specific pre-defined Pasos that will be
followed for a Change of this Category. Change Models may be very simple,
with no requirement for approval (e.g. Password Reset) or may be very complex
with many Pasos that require approval (e.g. major software Release).
See Standard Change, Change Advisory Board.
Change Record (Service Transition) A Record containing the details of a Change. Each
Change Record documents the Lifecycle of a single Change. A Change Record
is created for every Request for Change that is received, even those that are
subsequently rejected. Change Records should reference the Configuration
Items that are affected by the Change. Change Records are stored in the
Configuration Management System.
Change Request Synonym for Request for Change.
Change (Service Transition) A Document that lists all approved Changes and their
Schedule planned implementation dates. A Change Schedule is sometimes called a
Forward Schedule of Change, even though TI also contains information about
Changes that have already been implemented.
Change Window (Service Transition) A regular, agreed time when Changes or Releases may
be implemented with minimal impact on Services. Change Windows are usually
documented in SLAs.
Charging (Service Strategy) Requiring payment for TI Services. Charging for TI Services
is optional, and many Organisations choose to treat their TI Proveedor de
Servicios as a Cost Centre.

Term Definition
Chronological (Service Operation) A technique used to help identify possible causes of
Analysis Problems. All available data about the Problem is collected and sorted by date
and time to provide a detailed timeline. This can make TI possible to identify
which Events may have been triggered by others.
CI Type (Service Transition) A Category that is used to Classify CIs. The CI Type
identifies the required Attributes and Relationships for a Configuration Record.
Common CI Types include: hardware, Document, User etc.
Classification The act of assigning a Category to something. Classification is used to ensure

consistent management and reporting. CIs, Incidents, Problems, Changes etc.
are usually classified.
Client A generic term that means a Customer, the Business or a Business Customer.
For example Client Manager may be used as a synonym for Account Manager.
The term client is also used to mean:
 A computer that is used directly by a User, for example a PC, Handheld
Computer, or Workstation.
 The part of a Client-Server Application that the User directly interfaces
with. For example an email Client.
Closed (Service Operation) The final Estado in the Lifecycle of an Incident, Problem,
Change etc. When the Estado is Closed, no further action is taken.
Closure (Service Operation) The act of changing the Estado of an Incident, Problem,
Change etc. to Closed.
COBIT (Continual Service Improvement) Control Objetivos for Information and

related Technology (COBIT) provides guidance and Best Practice for the
management of TI Processes. COBIT is published by the TI Governance
Institute. See http://www.isaca.org/ for more information.
Code of Practice A Guideline published by a public body or a Standards Organisation, such as

ISO or BSI. Many Standards consist of a Code of Practice and a Specification.
The Code of Practice describes recommended Best Practice.
Cold Standby Synonym for Gradual Recovery.
Commercial off (Service Design) Application software or Middleware that can be purchased
the Shelf (COTS) from a Third Party.
Compliance Ensuring that a Standard or set of Guidelines is followed, or that proper,

consistent accounting or other practices are being employed.
Component A general term that is used to mean one part of something more complex. For
example, a computer System may be a component of an TI Service, an
Application may be a Component of a Release UnTI. Components that need to
be managed should be Configuration Items.
Component (Service Design) (Continual Service Improvement) The Process responsible

Capacity for understanding the Capacity, Utilisation, and Performance of Configuration
Management Items. Data is collected, recorded and analysed for use in the Capacity Plan.
(CCM)
See Service Capacity Management.
Component CI (Service Transition) A Configuration Item that is part of an Assembly. For

example, a CPU or Memory CI may be part of a Server CI.

Term Definition
Component (Service Design) A technique that helps to identify the impact of CI failure on TI
Failure Impact Services. A matrix is created with TI Services on one edge and CIs on the other.
Analysis (CFIA) This enables the identification of critical CIs (that could cause the failure of
multiple TI Services) and of fragile TI Services (that have multiple Single Points
of Failure).
Computer (Service Operation) CTI is a general term covering any kind of integration
Telephony between computers and telephone Systems. TI is most commonly used to refer
Integration (CTI) to Systems where an Application displays detailed screens relating to incoming
or outgoing telephone calls.
See Automatic Call Distribution, Interactive Voice Response.
Concurrency A measure of the number of Users engaged in the same Operation at the same
time.
Confidentiality (Service Design) A security principle that requires that data should only be
accessed by authorised people.
Configuration (Service Transition) A generic term, used to describe a group of Configuration

Items that work together to deliver an TI Service, or a recognizable part of an TI
Service. Configuration is also used to describe the parameter settings for one or
more CIs.
Configuration (Service Transition) A Baseline of a Configuration that has been formally

Baseline agreed and is managed through the Change Management process. A
Configuration Baseline is used as a basis for future Builds, Releases and
Changes.
Configuration (Service Transition) The Actividad responsible for ensuring that adding,
Control modifying or removing a CI is properly managed, for example by submitting a
Request for Change or Service Request.
Configuration (Service Transition) The Actividad responsible for collecting information about
Identification Configuration Items and their Relationships, and loading this information into the
CMDB. Configuration Identification is also responsible for labelling the CIs
themselves, so that the corresponding Configuration Records can be found.
Configuration (Service Transition) Any Component that needs to be managed in order to

Item (CI) deliver an TI Service. Information about each CI is recorded in a Configuration
Record within the Configuration Management System and is maintained
throughout its Lifecycle by Configuration Management. CIs are under the control
of Change Management. CIs typically include TI Services, hardware, software,
buildings, people, and formal documentation such as Process documentation
and SLAs.
Configuration (Service Transition) The Process responsible for maintaining information about
Management Configuration Items required to deliver an TI Service, including their
Relationships. This information is managed throughout the Lifecycle of the CI.
Configuration Management is part of an overall Service Asset and Configuration
Management Process.
Configuration (Service Transition) A database used to store Configuration Records

Management throughout their Lifecycle. The Configuration Management System maintains
Database one or more CMDBs, and each CMDB stores Attributes of CIs, and
(CMDB)
Relationships with other CIs.

Term Definition
Configuration (Service Transition) A set of tools and databases that are used to manage an
Management TI Proveedor de Servicios's Configuration data. The CMS also includes
System (CMS) information about Incidents, Problems, Known Errors, Changes and Releases;
and may contain data about employees, Suppliers, locations, Unidades de
Negocio, Customers and Users. The CMS includes tools for collecting, storing,
managing, updating, and presenting data about all Configuration Items and their
Relationships. The CMS is maintained by Configuration Management and is
used by all TI Service Management Processes.
See Configuration Management Database, Service Knowledge Management
System.
Configuration (Service Transition) A Record containing the details of a Configuration Item.

Record Each Configuration Record documents the Lifecycle of a single CI.
Configuration Records are stored in a Configuration Management Database.
Configuration (Service Transition) The hierarchy and other Relationships between all the
Structure Configuration Items that comprise a Configuration.
Continual (Continual Service Improvement) A stage in the Lifecycle of an TI Service and

Service the title of one of the Core ITIL® publications.
Improvement Continual Service Improvement is responsible for managing improvements to TI
(CSI)
Service Management Processes and TI Services. The Performance of the TI
Proveedor de Servicios is continually measured and improvements are made to
Processes, TI Services and TI Infrastructure in order to increase Efficiency,
Effectiveness, and Cost Effectiveness.
See Plan-Do-Check-Act.
Continuous (Service Design) An approach or design to achieve 100% Availability. A

Availability Continuously Available TI Service has no planned or unplanned Downtime.
Continuous (Service Design) An approach or design to eliminate planned Downtime of an

Operation TI Service. Note that individual Configuration Items may be down even though
the TI Service is Available.
Contract A legally binding Agreement between two or more parties.
Contract (Service Strategy) A database or structured Document used to manage

Portfolio Service Contracts or Agreements between an TI Proveedor de Servicios and
their Customers. Each TI Service delivered to a Customer should have a
Contract or other Agreement which is listed in the Contract Portfolio.
See Service Portfolio, Service Catalogue.
Control A means of managing a Risk, ensuring that a Business Objetivo is achieved, or

ensuring that a Process is followed. Example Controls include Policies,
Procedures, Roles, RAID, door-locks etc. A control is sometimes called a
Countermeasure or safeguard.
Control also means to manage the utilization or behaviour of a Configuration
Item, System or TI Service.
Control See COBTI.

Objetivos for
Information and
related
Technology
(COBIT)

Term Definition
Control (Service Strategy) An approach to the management of TI Services, Processes,
perspective Functions, Assets etc. There can be several different Control Perspectives on
the same TI Service, Process etc., allowing different individuals or teams to
focus on what is important and relevant to their specific Role. Example Control
Perspectives include Reactive and Proactive management within TI Operations,
or a Lifecycle view for an Application Project team.
Control The ISO/IEC 20000 Process group that includes Change Management and
Processes Configuration Management.
Core Service (Service Strategy) An TI Service that delivers basic Outcomes desired by one
or more Customers.
See Supporting Service, Core Service Package.
Core Service (Service Strategy) A detailed description of a Core Service that may be shared
Package (CSP) by two or more Service Level Packages.
See Service Package.
Cost The amount of money spent on a specific Actividad, TI Service, or Business

UnTI. Costs consist of real cost (money), notional cost such as people's time,
and Depreciation.
Cost Benefit An Actividad that analyses and compares the Costs and the benefits involved in
Analysis one or more alternative courses of action.
See Business Case, Net Present Value, Internal Rate of Return, Return on
Investment, Value on Investment.
Cost Centre (Service Strategy) A Business Unit or Project to which Costs are assigned. A
Cost Centre does not charge for Services provided. An TI Proveedor de
Servicios can be run as a Cost Centre or a Profit Centre.
Cost A measure of the balance between the Effectiveness and Cost of a Service,
Effectiveness Process or Actividad, A Cost Effective Process is one which achieves its
Objetivos at minimum Cost.
See KPI, Return on Investment, Value for Money.
Cost Element (Service Strategy) The middle level of category to which Costs are assigned in
Budgeting and Accounting. The highest level category is Cost Type. For
example a Cost Type of “people” could have cost elements of payroll, staff
benefits, expenses, training, overtime etc. Cost Elements can be further broken
down to give Cost Units. For example the Cost Element “expenses” could
include Cost Units of Hotels, Transport, Meals etc.
Cost (Service Strategy) A general term that is used to refer to Budgeting and
Management Accounting, sometimes used as a synonym for Financial Management
Cost Type (Service Strategy) The highest level of category to which Costs are assigned in
Budgeting and Accounting. For example hardware, software, people,
accommodation, external and Transfer.
See Cost Element, Cost Type.
Cost Unit (Service Strategy) The lowest level of category to which Costs are assigned,
Cost Units are usually things that can be easily counted (e.g. staff numbers,
software licences) or things easily measured (e.g. CPU usage, Electricity
consumed). Cost Units are included within Cost Elements. For example a Cost
Element of “expenses” could include Cost Units of Hotels, Transport, Meals etc.
See Cost Type.

Term Definition
Countermeasure Can be used to refer to any type of Control. The term Countermeasure is most
often used when referring to measures that increase Resilience, Fault Tolerance
or Reliability of an TI Service.
Course Changes made to a Plan or Actividad that has already started, to ensure that TI
Corrections will meet its Objetivos. Course corrections are made as a result of Monitoring
progress.
CRAMM A methodology and tool for analysing and managing Risks. CRAMM was
developed by the UK Government, but is now privately owned. Further
information is available from http://www.cramm.com/
Crisis The Process responsible for managing the wider implications of Business
Management Continuity. A Crisis Management team is responsible for Strategic issues such
as managing media relations and shareholder confidence, and decides when to
invoke Business Continuity Plans.
Critical Success Something that must happen if a Process, Project, Plan, or TI Service is to
Factor (CSF) succeed. KPIs are used to measure the achievement of each CSF. For example
a CSF of "protect TI Services when making Changes" could be measured by
KPIs such as "percentage reduction of unsuccessful Changes", "percentage
reduction in Changes causing Incidents" etc.
Culture A set of values that is shared by a group of people, including expectations about
how people should behave, ideas, beliefs, and practices.
See Vision.
Customer Someone who buys goods or Services. The Customer of an TI Proveedor de

Servicios is the person or group who defines and agrees the Service Level
Targets. The term Customers is also sometimes informally used to mean Users,
for example "this is a Customer focussed Organisation".
Customer (Service Strategy) A database or structured Document used to record all

Portfolio Customers of the TI Proveedor de Servicios. The Customer Portfolio is the
Business Relationship Manager's view of the Customers who receive Services
from the TI Proveedor de Servicios.
See Contract Portfolio, Service Portfolio.
Dashboard (Service Operation) A graphical representation of overall TI Service

Performance and Availability. Dashboard images may be updated in real-time,
and can also be included in management reports and web pages. Dashboards
can be used to support Service Level Management, Event Management or
Incident Diagnosis.
Data-to- A way of understanding the relationships between data, information, knowledge,

Information-to- and wisdom. DIKW shows how each of these builds on the others.
Knowledge-to-
Wisdom (DIKW)
Definitive Media (Service Transition) One or more locations in which the definitive and
Library (DML) approved versions of all software Configuration Items are securely stored. The
DML may also contain associated CIs such as licenses and documentation. The
DML is a single logical storage area even if there are multiple locations. All
software in the DML is under the control of Change and Release Management
and is recorded in the Configuration Management System. Only software from
the DML is acceptable for use in a Release.

Term Definition
Deliverable Something that must be provided to meet a commitment in a Service Level
Agreement or a Contract. Deliverable is also used in a more informal way to
mean a planned output of any Process.
Demand Activities that understand and influence Customer demand for Services and the
Management provision of Capacity to meet these demands. At a Strategic level Demand
Management can involve analysis of Patterns of Business Actividad and User
Profiles. At a Tactical level TI can involve use of Differential Charging to
encourage Customers to use TI Services at less busy times.
See Capacity Management.
Deming Cycle Synonym for Plan Do Check Act.
Dependency The direct or indirect reliance of one Process or Actividad upon another.
Deployment (Service Transition) The Actividad responsible for movement of new or

changed hardware, software, documentation, Process, etc to the Live
Environment. Deployment is part of the Release and Deployment Management
Process.
See Rollout.
Depreciation (Service Strategy) A measure of the reduction in value of an Asset over its life.
This is based on wearing out, consumption or other reduction in the useful
economic value.
Design (Service Design) An Actividad or Process that identifies Requirements and then
defines a solution that is able to meet these Requirements.
See Service Design.
Detection (Service Operation) A stage in the Incident Lifecycle. Detection results in the
Incident becoming known to the Proveedor de Servicios. Detection can be
automatic, or can be the result of a User logging an Incident.
Development (Service Design) The Process responsible for creating or modifying an TI

Service or Application. Also used to mean the Role or group that carries out
Development work.
Development (Service Design) An Environment used to create or modify TI Services or

Environment Applications. Development Environments are not typically subjected to the same
degree of control as Test Environments or Live Environments.
See Development.
Diagnosis (Service Operation) A stage in the Incident and Problem Lifecycles. The
purpose of Diagnosis is to identify a Workaround for an Incident or the Root
Cause of a Problem.
Diagnostic Script (Service Operation) A structured set of questions used by Service Desk staff to
ensure they ask the correct questions, and to help them Classify, Resolve and
assign Incidents. Diagnostic Scripts may also be made available to Users to
help them diagnose and resolve their own Incidents.
Differential A technique used to support Demand Management by charging different

Charging amounts for the same TI Service Function at different times.
Direct Cost (Service Strategy) A cost of providing an TI Service which can be allocated in
full to a specific Customer, Cost Centre, Project etc. For example cost of
providing non-shared servers or software licenses.
See Indirect Cost.

Term Definition
Directory Service (Service Operation) An Application that manages information about TI
Infrastructure available on a network, and corresponding User access Rights.
Do Nothing (Service Design) A Recovery Option. The Proveedor de Servicios formally

agrees with the Customer that Recovery of this TI Service will not be performed.
Document Information in readable form. A Document may be paper or electronic. For

example a Policy statement, Service Level Agreement, Incident Record,
diagram of computer room layout.
See Record.
Downtime (Service Design) (Service Operation) The time when a Configuration Item or
TI Service is not Available during its Agreed Service Time. The Availability of an
TI Service is often calculated from Agreed Service Time and Downtime.
Driver Something that influences Strategy, Objetivos or Requirements. For example

new legislation or the actions of competitors.
Early Life (Service Transition) Support provided for a new or Changed TI Service for a
Support period of time after TI is Released. During Early Life Support the TI Proveedor
de Servicios may review the KPIs, Service Levels and Monitoring Thresholds,
and provide additional Resources for Incident and Problem Management.
Economies of (Service Strategy) The reduction in average Cost that is possible from
scale increasing the usage of an TI Service or Asset.
See Economies of Scope.
Economies of (Service Strategy) The reduction in Cost that is allocated to an TI Service by

scope using an existing Asset for an additional purpose. For example delivering a new
TI Service from existing TI Infrastructure.
See Economies of Scale.
Effectiveness (Continual Service Improvement) A measure of whether the Objetivos of a

Process, Service or Actividad have been achieved. An Effective Process or
Actividad is one that achieves its agreed Objetivos.
See KPI.
Efficiency (Continual Service Improvement) A measure of whether the right amount of

resources have been used to deliver a Process, Service or Actividad. An
Efficient Process achieves its Objetivos with the minimum amount of time,
money, people or other resources.
See KPI.
Emergency (Service Transition) A Change that must be introduced as soon as possible.

Change For example to resolve a Major Incident or implement a Security patch. The
Change Management Process will normally have a specific Procedure for
handling Emergency Changes.
See Emergency Change Advisory Board (ECAB).
Emergency (Service Transition) A sub-set of the Change Advisory Board who make
Change Advisory decisions about high impact Emergency Changes. Membership of the ECAB
Board (ECAB) may be decided at the time a meeting is called, and depends on the nature of
the Emergency Change.

Term Definition
Environment (Service Transition) A subset of the TI Infrastructure that is used for a
particular purpose. For Example: Live Environment, Test Environment, Build
Environment. TI is possible for multiple Environments to share a Configuration
Item, for example Test and Live Environments may use different partitions on a
single mainframe computer. Also used in the term Physical Environment to
mean the accommodation, air conditioning, power system etc.
Environment is also used as a generic term to mean the external conditions that
influence or affect something.
Error (Service Operation) A design fLey or malfunction that causes a Failure of one
or more Configuration Items or TI Services. A mistake made by a person or a
faulty Process that impacts a CI or TI Service is also an Error.
Escalation (Service Operation) An Actividad that obtains additional Resources when these
are needed to meet Service Level Targets or Customer expectations. Escalation
may be needed within any TI Service Management Process, but is most
commonly associated with Incident Management, Problem Management and the
management of Customer complaints. There are two types of Escalation,
Functional Escalation and Hierarchic Escalation.
eSourcing (Service Strategy) A framework to help Organisations guide their analysis and
Capability Model decisions on Service Sourcing Models and Strategies. eSCM-CL was developed
for Client by Carnegie Mellon University.
Organizations
See eSCM-SP.
(eSCM-CL)
eSourcing (Service Strategy) A framework to help TI Proveedor de Servicioss develop

Capability Model their TI Service Management Capabilities from a Service Sourcing perspective.
for Proveedor de eSCM-SP was developed by Carnegie Mellon University.
Servicioss
See eSCM-CL.
(eSCM-SP)
Estimation The use of experience to provide an approximate value for a Metric or Cost.
Estimation is also used in Capacity and Availability Management as the
cheapest and least accurate Modelling method.
Evaluation (Service Transition) The Process responsible for assessing a new or Changed
TI Service to ensure that Risks have been managed and to help determine
whether to proceed with the Change.
Evaluation is also used to mean comparing an actual Outcome with the intended
Outcome, or comparing one alternative with another.
Event (Service Operation) A change of state which has significance for the
management of a Configuration Item or TI Service.
The term Event is also used to mean an Alert or notification created by any TI
Service, Configuration Item or Monitoring tool. Events typically require TI
Operations personnel to take actions, and often lead to Incidents being logged.
Event (Service Operation) The Process responsible for managing Events throughout
Management their Lifecycle. Event Management is one of the main Activities of TI Operations.
Exception A Document containing details of one or more KPIs or other important targets
Report that have exceeded defined Thresholds. Examples include SLA targets being
missed or about to be missed, and a Performance Metric indicating a potential
Capacity problem.

Term Definition
Expanded (Availability Management) Detailed stages in the Lifecycle of an Incident. The
Incident stages are Detection, Diagnosis, Repair, Recovery, Restoration. The Expanded
Lifecycle Incident Lifecycle is used to help understand all contributions to the Impact of
Incidents and to Plan how these could be controlled or reduced.
External A Customer who works for a different Business to the TI Proveedor de

Customer Servicios.
See External Proveedor de Servicios, Internal Customer.
External Metric A Metric that is used to measure the delivery of TI Service to a Customer.
External Metrics are usually defined in SLAs and reported to Customers.
See Internal Metric.
External (Service Strategy) An TI Proveedor de Servicios which is part of a different

Proveedor de Organisation to their Customer. An TI Proveedor de Servicios may have both
Servicios Internal Customers and External Customers.
See Type III Proveedor de Servicios.
External Synonym for Outsourcing.

Sourcing
Facilities (Service Operation) The Function responsible for managing the physical
Management Environment where the TI Infrastructure is located. Facilities Management
includes all aspects of managing the physical Environment, for example power
and cooling, building Access Management, and environmental Monitoring.
Failure (Service Operation) Loss of ability to Operate to Specification, or to deliver the

required output. The term Failure may be used when referring to TI Services,
Processes, Activities, Configuration Items etc. A Failure often causes an
Incident.
Failure Modes An approach to assessing the potential Impact of Failures. FMEA involves
and Effects analysing what would happen after Failure of each Configuration Item, all the
Analysis (FMEA) way up to the effect on the Business. FMEA is often used in Information Security
Management and in TI Service Continuity Planning.
Fast Recovery (Service Design) A Recovery Option which is also known as Hot Standby.
Provision is made to Recover the TI Service in a short period of time, typically
less than 24 hours. Fast Recovery typically uses a dedicated Fixed Facility with
computer Systems, and software configured ready to run the TI Services.
Immediate Recovery may take up to 24 hours if there is a need to Restore data
from Backups.
Fault Synonym for Error.
Fault Tolerance (Service Design) The ability of an TI Service or Configuration Item to continue
to Operate correctly after Failure of a Component part.
See Resilience, Countermeasure.
Fault Tree (Service Design) (Continual Service Improvement) A technique that can be
Analysis (FTA) used to determine the chain of Events that leads to a Problem. Fault Tree
Analysis represents a chain of Events using Boolean notation in a diagram.
Financial (Service Strategy) The Function and Processes responsible for managing an TI
Management Proveedor de Servicios's Budgeting, Accounting and Charging Requirements.

Term Definition
First-line (Service Operation) The first level in a hierarchy of Support Groups involved in
Support the resolution of Incidents. Each level contains more specialist skills, or has
more time or other Resources.
See Escalation.
Fishbone Synonym for Ishikawa Diagram.

Diagram
Fit for Purpose An informal term used to describe a Process, Configuration Item, TI Service etc.
that is capable of meeting its Objetivos or Service Levels. Being Fit for Purpose
requires suitable Design, implementation, Control and maintenance.
Fixed Cost (Service Strategy) A Cost that does not vary with TI Service usage. For
example the cost of Server hardware.
See Variable Cost.
Fixed Facility (Service Design) A permanent building, available for use when needed by an TI
Service Continuity Plan.
See Recovery Option, Portable Facility.
Follow the Sun (Service Operation) A methodology for using Service Desks and Support
Groups around the world to provide seamless 24 * 7 Service. Calls, Incidents,
Problems and Service Requests are passed between groups in different time
zones.
Fulfilment Performing Activities to meet a need or Requirement. For example by providing

a new TI Service, or meeting a Service Request.
Function A team or group of people and the tools they use to carry out one or more
Processes or Activities. For example the Service Desk.
The term Function also has two other meanings
 An intended purpose of a Configuration Item, Person, Team, Process, or TI
Service. For example one Function of an Email Service may be to store
and forward outgoing mails, one Function of a Business Process may be to
dispatch goods to Customers.
 To perform the intended purpose correctly, "The computer is Functioning"
Functional (Service Operation) Transferring an Incident, Problem or Change to a technical

Escalation team with a higher level of expertise to assist in an Escalation.
Gap Analysis (Continual Service Improvement) An Actividad which compares two sets of
data and identifies the differences. Gap Analysis is commonly used to compare
a set of Requirements with actual delivery.
See Benchmarking.
Governance Ensuring that Policies and Strategy are actually implemented, and that required
Processes are correctly followed. Governance includes defining Roles and
responsibilities, measuring and reporting, and taking actions to resolve any
issues identified.
Gradual (Service Design) A Recovery Option which is also known as Cold Standby.
Recovery Provision is made to Recover the TI Service in a period of time greater than 72
hours. Gradual Recovery typically uses a Portable or Fixed Facility that has
environmental support and network cabling, but no computer Systems. The
hardware and software are installed as part of the TI Service Continuity Plan.

Term Definition
Guideline A Document describing Best Practice, that recommends what should be done.
Compliance to a guideline is not normally enforced.
See Standard.
Help Desk (Service Operation) A point of contact for Users to log Incidents. A Help Desk
is usually more technically focussed than a Service Desk and does not provide a
Single Point of Contact for all interaction. The term Help Desk is often used as a
synonym for Service Desk.
Hierarchic (Service Operation) Informing or involving more senior levels of management

Escalation to assist in an Escalation.
High Availability (Service Design) An approach or Design that minimises or hides the effects of
Configuration Item Failure on the Users of an TI Service. High Availability
solutions are Designed to achieve an agreed level of Availability and make use
of techniques such as Fault Tolerance, Resilience and fast Recovery to reduce
the number of Incidents, and the Impact of Incidents.
Hot Standby Synonym for Fast Recovery or Immediate Recovery.
Identity (Service Operation) A unique name that is used to identify a User, person or
Role. The Identity is used to grant Rights to that User, person, or Role. Example
identities might be the username SmithJ or the Role "Change manager".
Immediate (Service Design) A Recovery Option which is also known as Hot Standby.
Recovery Provision is made to Recover the TI Service with no loss of Service. Immediate
Recovery typically uses mirroring, load balancing and split site technologies.
Impact (Service Operation) (Service Transition) A measure of the effect of an

Incident, Problem or Change on Business Processes. Impact is often based on
how Service Levels will be affected. Impact and Urgency are used to assign
Priority.
Incident (Service Operation) An unplanned interruption to an TI Service or a reduction

in the Quality of an TI Service. Failure of a Configuration Item that has not yet
impacted Service is also an Incident. For example Failure of one disk from a
mirror set.
Incident (Service Operation) The Process responsible for managing the Lifecycle of all
Management Incidents. The primary Objetivo of Incident Management is to return the TI
Service to Users as quickly as possible.
Incident Record (Service Operation) A Record containing the details of an Incident. Each
Incident record documents the Lifecycle of a single Incident.
Indirect Cost (Service Strategy) A Cost of providing an TI Service which cannot be allocated
in full to a specific Customer. For example Cost of providing shared Servers or
software licenses. Also known as Overhead.
See Direct Cost.
Information (Service Design) The Process that ensures the Confidentiality, Integrity and
Security Availability of an Organisation's Assets, information, data and TI Services.
Management Information Security Management usually forms part of an Organisational
(ISM) approach to Security Management which has a wider scope than the TI
Proveedor de Servicios, and includes handling of paper, building access, phone
calls etc., for the entire Organisation.

Term Definition
Information (Service Design) The framework of Policy, Processes, Standards, Guidelines
Security and tools that ensures an Organisation can achieve its Information Security
Management Management Objetivos.
System (ISMS)
Information (Service Design) The Policy that governs the Organisation’s approach to
Security Policy Information Security Management.
Information The use of technology for the storage, communication or processing of

Technology (TI) information. The technology typically includes computers, telecommunications,
Applications and other software. The information may include Business data,
voice, images, video, etc. Information Technology is often used to support
Business Processes through TI Services.
Infrastructure An TI Service that is not directly used by the Business, but is required by the TI
Service Proveedor de Servicios so they can provide other TI Services. For example
Directory Services, naming services, or communication services.
Insourcing Synonym for Internal Sourcing.
Integrity (Service Design) A security principle that ensures data and Configuration Items
are only modified by authorised personnel and Activities. Integrity considers all
possible causes of modification, including software and hardware Failure,
environmental Events, and human intervention.
Interactive Voice (Service Operation) A form of Automatic Call Distribution that accepts User
Response (IVR) input, such as key presses and spoken commands, to identify the correct
destination for incoming Calls.
Intermediate (Service Design) A Recovery Option which is also known as Warm Standby.
Recovery Provision is made to Recover the TI Service in a period of time between 24 and
72 hours. Intermediate Recovery typically uses a shared Portable or Fixed
Facility that has computer Systems and network Components. The hardware
and software will need to be configured, and data will need to be restored, as
part of the TI Service Continuity Plan.
Internal A Customer who works for the same Business as the TI Proveedor de Servicios.
Customer See Internal Proveedor de Servicios, External Customer.
Internal Metric A Metric that is used within the TI Proveedor de Servicios to Monitor the
Efficiency, Effectiveness or Cost Effectiveness of the TI Proveedor de
Servicios's internal Processes. Internal Metrics are not normally reported to the
Customer of the TI Service. See External Metric.
Internal Rate of (Service Strategy) A technique used to help make decisions about Capital
Return (IRR) Expenditure. IRR calculates a figure that allows two or more alternative
investments to be compared. A larger IRR indicates a better investment.
See Net Present Value, Return on Investment.
Internal (Service Strategy) An TI Proveedor de Servicios which is part of the same

Proveedor de Organisation as their Customer. An TI Proveedor de Servicios may have both
Servicios Internal Customers and External Customers.
See Type I Proveedor de Servicios, Type II Proveedor de Servicios, Insource.
Internal Sourcing (Service Strategy) Using an Internal Proveedor de Servicios to manage TI

Services.
See Service Sourcing, Type I Proveedor de Servicios, Type II Proveedor de
Servicios.

Term Definition
International The International Organization for Standardization (ISO) is the world's largest
Organization for developer of Standards. ISO is a non-governmental organization which is a
Standardization network of the national standards institutes of 156 countries.
(ISO)
Further information about ISO is available from http://www.iso.org/
International See International Organization for Standardization (ISO)

Standards
Organisation
Internet An External Proveedor de Servicios that provides access to the Internet. Most
Proveedor de ISPs also provide other TI Services such as web hosting.
Servicios (ISP)
Invocation (Service Design) Initiation of the Pasos defined in a plan. For example initiating
the TI Service Continuity Plan for one or more TI Services.
Ishikawa (Service Operation) (Continual Service Improvement) A technique that helps

Diagram a team to identify all the possible causes of a Problem. Originally devised by
Kaoru Ishikawa, the output of this technique is a diagram that looks like a
fishbone.
ISO 9000 A generic term that refers to a number of international Standards and Guidelines
for Quality Management Systems.
See http://www.iso.org/ for more information.
See ISO.
ISO 9001 An international Standard for Quality Management Systems.

See ISO 9000, Standard.
ISO/IEC 17799 (Continual Service Improvement) ISO Code of Practice for Information
Security Management.
See Standard.
ISO/IEC 20000 ISO Specification and Code of Practice for TI Service Management. ISO/IEC
20000 is aligned with ITIL® Best Practice.
ISO/IEC 27002 (Service Design) (Continual Service Improvement) ISO Specification for
Information Security Management. The corresponding Code of Practice is
ISO/IEC 17799.
See Standard.
TI Directorate (Continual Service Improvement) Senior Management within a Proveedor de

Servicios, charged with developing and delivering TI services. Most commonly
used in UK Government departments.
TI Infrastructure All of the hardware, software, networks, facilities etc. that are required to
Develop, Test, deliver, Monitor, Control or support TI Services. The term TI
Infrastructure includes all of the Information Technology but not the associated
people, Processes and documentation.
TI Operations (Service Operation) Activities carried out by TI Operations Control, including

Console Management, Job Scheduling, Backup and Restore, and Print and
Output Management.
TI Operations is also used as a synonym for Service Operation.
TI Operations (Service Operation) The Function responsible for Monitoring and Control of the
Control TI Services and TI Infrastructure.
See Operations Bridge.

Term Definition
TI Operations (Service Operation) The Function within an TI Proveedor de Servicios which
Management performs the daily Activities needed to manage TI Services and the supporting
TI Infrastructure. TI Operations Management includes TI Operations Control and
Facilities Management.
TI Service A Service provided to one or more Customers by an TI Proveedor de Servicios.

An TI Service is based on the use of Information Technology and supports the
Customer's Business Processes. An TI Service is made up from a combination
of people, Processes and technology and should be defined in a Service Level
Agreement.
TI Service (Service Design) The Process responsible for managing Risks that could
Continuity seriously impact TI Services. ITSCM ensures that the TI Proveedor de Servicios
Management can always provide minimum agreed Service Levels, by reducing the Risk to an
(ITSCM)
acceptable level and Planning for the Recovery of TI Services. ITSCM should be
designed to support Business Continuity Management.
TI Service (Service Design) A Plan defining the Pasos required to Recover one or more TI
Continuity Plan Services. The Plan will also identify the triggers for Invocation, people to be
involved, communications etc. The TI Service Continuity Plan should be part of
a Business Continuity Plan.
TI Service The implementation and management of Quality TI Services that meet the
Management needs of the Business. TI Service Management is performed by TI Proveedor
(ITSM) de Servicioss through an appropriate mix of people, Process and Information
Technology.
See Service Management.
TI Service The TI Service Management Forum is an independent Organisation dedicated

Management to promoting a professional approach to TI Service Management. The itSMF is
Forum (itSMF) a not-for-profit membership Organisation with representation in many countries
around the world (itSMF Chapters). The itSMF and its membership contribute to
the development of ITIL® and associated TI Service Management Standards.
See http://www.itsmf.com/ for more information.
TI Proveedor de (Service Strategy) A Proveedor de Servicios that provides TI Services to

Servicios Internal Customers or External Customers.
TI Steering A formal group that is responsible for ensuring that Business and TI Proveedor
Group (ISG) de Servicios Strategies and Plans are closely aligned. An TI Steering Group
includes senior representatives from the Business and the TI Proveedor de
Servicios.
ITIL A set of Best Practice guidance for TI Service Management. ITIL® is owned by
the OGC and consists of a series of publications giving guidance on the
provision of Quality TI Services, and on the Processes and facilities needed to
support them. See http://www.itil.co.uk/ for more information.
Job Description A Document which defines the Roles, responsibilities, skills and knowledge
required by a particular person. One Job Description can include multiple Roles,
for example the Roles of Configuration Manager and Change Manager may be
carried out by one person.
Job Scheduling (Service Operation) Planning and managing the execution of software tasks
that are required as part of an TI Service. Job Scheduling is carried out by TI
Operations Management, and is often automated using software tools that run
batch or online tasks at specific times of the day, week, month or year.

Term Definition
Kano Model (Service Strategy) A Model developed by Noriaki Kano that is used to help
understand Customer preferences. The Kano Model considers Attributes of an
TI Service grouped into áreas such as Basic Factors, Excitement Factors,
Performance Factors etc.
Kepner & Tregoe (Service Operation) (Continual Service Improvement) A structured approach
Analysis to Problem solving. The Problem is analysed in terms of what, where, when and
extent. Possible causes are identified. The most probable cause is tested. The
true cause is verified.
Key Performance (Continual Service Improvement) A Metric that is used to help manage a
Indicator (KPI) Process, TI Service or Actividad. Many Metrics may be measured, but only the
most important of these are defined as KPIs and used to actively manage and
report on the Process, TI Service or Actividad. KPIs should be selected to
ensure that Efficiency, Effectiveness, and Cost Effectiveness are all managed.
See Critical Success Factor.
Knowledge Base (Service Transition) A logical database containing the data used by the Service
Knowledge Management System.
Knowledge (Service Transition) The Process responsible for gathering, analysing, storing
Management and sharing knowledge and information within an Organisation. The primary
purpose of Knowledge Management is to improve Efficiency by reducing the
need to rediscover knowledge.
See Data-to-Information-to-Knowledge-to-Wisdom, Service Knowledge
Management System.
Known Error (Service Operation) A Problem that has a documented Root Cause and a
Workaround. Known Errors are created and managed throughout their Lifecycle
by Problem Management. Known Errors may also be identified by Development
or Suppliers.
Known Error (Service Operation) A database containing all Known Error Records. This
Database (KEDB) database is created by Problem Management and used by Incident and
Problem Management. The Known Error Database is part of the Service
Knowledge Management System.
Known Error (Service Operation) A Record containing the details of a Known Error. Each
Record Known Error Record documents the Lifecycle of a Known Error, including the
Estado, Root Cause and Workaround. In some implementations a Known Error
is documented using additional fields in a Problem Record.
Lifecycle The various stages in the life of an TI Service, Configuration Item, Incident,
Problem, Change etc. The Lifecycle defines the Categories for Estado and the
Estado transitions that are permitted. For example:
 The Lifecycle of an Application includes Requirements, Design, Build,
Deploy, Operate, Optimise.
 The Expanded Incident Lifecycle includes Detect, Respond, Diagnose,
Repair, Recover, Restore.
 The lifecycle of a Server may include: Ordered, Received, In Test, Live,
Disposed etc.
Line of Service (Service Strategy) A Core Service or Supporting Service that has multiple
(LOS) Service Level Packages. A line of Service is managed by a Product Manager
and each Service Level Package is designed to support a particular market
segment.

Term Definition
Live (Service Transition) Refers to an TI Service or Configuration Item that is being
used to deliver Service to a Customer.
Live (Service Transition) A controlled Environment containing Live Configuration

Environment Items used to deliver TI Services to Customers.
Maintainability (Service Design) A measure of how quickly and Effectively a Configuration Item
or TI Service can be restored to normal working after a Failure. Maintainability is
often measured and reported as MTRS.
Maintainability is also used in the context of Software or TI Service Development
to mean ability to be Changed or Repaired easily.
Major Incident (Service Operation) The highest Category of Impact for an Incident. A Major
Incident results in significant disruption to the Business.
Managed (Service Strategy) A perspective on TI Services which emphasizes the fact that
Services they are managed. The term Managed Services is also used as a synonym for
Outsourced TI Services.
Management Information that is used to support decision making by managers. Management

Information Information is often generated automatically by tools supporting the various TI
Service Management Processes. Management Information often includes the
values of KPIs such as "Percentage of Changes leading to Incidents", or "first
time fix rate".
Management of The OGC methodology for managing Risks. MoR includes all the Activities
Risk (MoR) required to identify and Control the exposure to Risk which may have an impact
on the achievement of an Organisation’s Business Objetivos.
See http://www.m-o-r.org/ for more details.
Management The framework of Policy, Processes and Functions that ensures an

System Organisation can achieve its Objetivos.
Manual A Workaround that requires manual intervention. Manual Workaround is also

Workaround used as the name of a Recovery Option in which The Business Process
Operates without the use of TI Services. This is a temporary measure and is
usually combined with another Recovery Option.
Marginal Cost (Service Strategy) The Cost of continuing to provide the TI Service. Marginal
Cost does not include investment already made, for example the cost of
developing new software and delivering training.
Market Space (Service Strategy) All opportunities that an TI Proveedor de Servicios could
exploit to meet business needs of Customers. The Market Space identifies the
possible TI Services that an TI Proveedor de Servicios may wish to consider
delivering.
Maturity (Continual Service Improvement) A measure of the Reliability, Efficiency and

Effectiveness of a Process, Function, Organisation etc. The most mature
Processes and Functions are formally aligned to Business Objetivos and
Strategy, and are supported by a framework for continual improvement.
Maturity Level A named level in a Maturity model such as the Carnegie Mellon Capability
Maturity Model Integration.

Term Definition
Mean Time (Service Design) A Metric for measuring and reporting Reliability. MTBF is the
Between Failures average time that a Configuration Item or TI Service can perform its agreed
(MTBF) Function without interruption. This is measured from when the CI or TI Service
starts working, until TI next fails.
Mean Time (Service Design) A Metric used for measuring and reporting Reliability. MTBSI
Between Service is the mean time from when a System or TI Service fails, until TI next fails.
Incidents MTBSI is equal to MTBF + MTRS.
(MTBSI)
Mean Time To The average time taken to repair a Configuration Item or TI Service after a
Repair (MTTR) Failure. MTTR is measured from when the CI or TI Service fails until TI is
Repaired. MTTR does not include the time required to Recover or Restore.
MTTR is sometimes incorrectly used to mean Mean Time to Restore Service.
Mean Time to The average time taken to Restore a Configuration Item or TI Service after a
Restore Service Failure. MTRS is measured from when the CI or TI Service fails until TI is fully
(MTRS) Restored and delivering its normal functionality.
See Maintainability, Mean Time to Repair.
Metric (Continual Service Improvement) Something that is measured and reported to

help manage a Process, TI Service or Actividad.
See KPI.
Middleware (Service Design) Software that connects two or more software Components or
Applications. Middleware is usually purchased from a Supplier, rather than
developed within the TI Proveedor de Servicios.
See Off the Shelf.
Mission The Mission Statement of an Organisation is a short but complete description of

Statement the overall purpose and intentions of that Organisation. TI states what is to be
achieved, but not how this should be done.
Model A representation of a System, Process, TI Service, Configuration Item etc. that

is used to help understand or predict future behaviour.
Modelling A technique that is used to predict the future behaviour of a System, Process, TI
Service, Configuration Item etc. Modelling is commonly used in Financial
Management, Capacity Management and Availability Management.
Monitor Control (Service Operation) Monitoring the output of a Task, Process, TI Service or
Loop Configuration Item; comparing this output to a predefined norm; and taking
appropriate action based on this comparison.
Monitoring (Service Operation) Repeated observation of a Configuration Item, TI Service

or Process to detect Events and to ensure that the current estado is known.
Near-Shore (Service Strategy) Provision of Services from a country near the country where
the Customer is based. This can be the provision of an TI Service, or of
supporting Functions such as Service Desk.
See On-shore, Off-shore.
Net Present (Service Strategy) A technique used to help make decisions about Capital
Value (NPV) Expenditure. NPV compares cash inflows to cash outflows. Positive NPV
indicates that an investment is worthwhile.
See Internal Rate of Return, Return on Investment.

Term Definition
Notional (Service Strategy) An approach to Charging for TI Services. Charges to
Charging Customers are calculated and Customers are informed of the charge, but no
money is actually transferred. Notional Charging is sometimes introduced to
ensure that Customers are aware of the Costs they incur, or as a stage during
the introduction of real Charging.
Objetivo The defined purpose or aim of a Process, an Actividad or an Organisation as a

whole. Objetivos are usually expressed as measurable targets. The term
Objetivo is also informally used to mean a Requirement.
See Outcome.
Off the Shelf Synonym for Commercial Off the Shelf.
Office of OGC owns the ITIL® brand (copyright and trademark). OGC is a UK
Government Government department that supports the delivery of the government's
Commerce procurement agenda through its work in collaborative procurement and in
(OGC) raising levels of procurement skills and capability with departments. TI also
provides support for complex public sector projects.
Office of Public OPSI license the Crown Copyright material used in the ITIL® publications. They
Sector are a UK Government department who provide online access to UK legislation,
Information license the re-use of Crown copyright material, manage the Information Fair
(OPSI)
Trader Scheme, maintain the Government’s Information Asset Register and
provide advice and guidance on official publishing and Crown copyright.
Off-shore (Service Strategy) Provision of Services from a location outside the country
where the Customer is based, often in a different continent. This can be the
provision of an TI Service, or of supporting Functions such as Service Desk.
See On-shore, Near-shore.
On-shore (Service Strategy) Provision of Services from a location within the country
where the Customer is based. See Off-shore, Near-shore.
Operate To perform as expected. A Process or Configuration Item is said to Operate if TI

is delivering the Required outputs. Operate also means to perform one or more
Operations. For example, to Operate a computer is to do the day-to-day
Operations needed for TI to perform as expected.
Operation (Service Operation) Day-to-day management of an TI Service, System, or

other Configuration Item. Operation is also used to mean any pre-defined
Actividad or Transaction. For example loading a magnetic tape, accepting
money at a point of sale, or reading data from a disk drive.
Operational The lowest of three levels of Planning and delivery (Strategic, Tactical,
Operational). Operational Activities include the day-to-day or short term
Planning or delivery of a Business Process or TI Service Management Process.
The term Operational is also a synonym for Live.
Operational Cost Cost resulting from running the TI Services. Often repeating payments. For
example staff costs, hardware maintenance and electricity (also known as
"current expenditure" or "revenue expenditure").
See Capital Expenditure.
Operational Synonym for Operational Cost.

Expenditure
(OPEX)

Term Definition
Operational (Service Design) (Continual Service Improvement) An Agreement between
Level Agreement an TI Proveedor de Servicios and another part of the same Organisation. An
(OLA) OLA supports the TI Proveedor de Servicios's delivery of TI Services to
Customers. The OLA defines the goods or Services to be provided and the
responsibilities of both parties. For example there could be an OLA
 between the TI Proveedor de Servicios and a procurement department to
obtain hardware in agreed times
 between the Service Desk and a Support Group to provide Incident
Resolution in agreed times.
See Service Level Agreement.
Operations (Service Operation) A physical location where TI Services and TI Infrastructure

Bridge are monitored and managed.
Operations Synonym for TI Operations Control.

Control
Operations Synonym for TI Operations Management.

Management
Opportunity Cost (Service Strategy) A Cost that is used in deciding between investment choices.
Opportunity Cost represents the revenue that would have been generated by
using the Resources in a different way. For example the Opportunity Cost of
purchasing a new Server may include not carrying out a Service Improvement
Actividad that the money could have been spent on. Opportunity cost analysis is
used as part of a decision making processes, but is not treated as an actual
Cost in any financial statement.
Optimise Review, Plan and request Changes, in order to obtain the maximum Efficiency
and Effectiveness from a Process, Configuration Item, Application etc.
Organisation A company, legal entity or other institution. Examples of Organisations that are
not companies include International Standards Organisation or itSMF. The term
Organisation is sometimes used to refer to any entity which has People,
Resources and Budgets. For example a Project or Business UnTI.
Outcome The result of carrying out an Actividad; following a Process; delivering an TI

Service etc. The term Outcome is used to refer to intended results, as well as to
actual results.
See Objetivo.
Outsourcing (Service Strategy) Using an External Proveedor de Servicios to manage TI

Services.
See Service Sourcing, Type III Proveedor de Servicios.
Overhead Synonym for Indirect cost
Pain Value (Service Operation) A technique used to help identify the Business Impact of
Analysis one or more Problems. A formula is used to calculate Pain Value based on the
number of Users affected, the duration of the Downtime, the Impact on each
User, and the cost to the Business (if known).
Pareto Principle (Service Operation) A technique used to prioritise Activities. The Pareto
Principle says that 80% of the value of any Actividad is created with 20% of the
effort. Pareto Analysis is also used in Problem Management to prioritise
possible Problem causes for investigation.

Term Definition
Partnership A relationship between two Organisations which involves working closely
together for common Metas or mutual benefTI. The TI Proveedor de Servicios
should have a Partnership with the Business, and with Third Parties who are
critical to the delivery of TI Services.
See Value Network.
Passive (Service Operation) Monitoring of a Configuration Item, an TI Service or a

Monitoring Process that relies on an Alert or notification to discover the current estado. See
Active Monitoring.
Pattern of (Service Strategy) A Workload profile of one or more Business Activities.

Business Patterns of Business Actividad are used to help the TI Proveedor de Servicios
Actividad (PBA) understand and plan for different levels of Business Actividad.
See User Profile.
Percentage (Service Design) The amount of time that a Component is busy over a given
utilisation period of time. For example, if a CPU is busy for 1800 seconds in a one hour
period, its utilisation is 50%
Performance A measure of what is achieved or delivered by a System, person, team,

Process, or TI Service.
Performance (Service Strategy) An approach to Organisational Culture that integrates, and

Anatomy actively manages, leadership and strategy, people development, technology
enablement, performance management and innovation.
Performance (Continual Service Improvement) The Process responsible for day-to-day

Management Capacity Management Activities. These include Monitoring, Threshold detection,
Performance analysis and Tuning, and implementing Changes related to
Performance and Capacity.
Pilot (Service Transition) A limited Deployment of an TI Service, a Release or a

Process to the Live Environment. A Pilot is used to reduce Risk and to gain User
feedback and Acceptance.
See Test, Evaluation.
Plan A detailed proposal which describes the Activities and Resources needed to
achieve an Objetivo. For example a Plan to implement a new TI Service or
Process. ISO/IEC 20000 requires a Plan for the management of each TI
Service Management Process.
Plan-Do-Check- (Continual Service Improvement) A four stage cycle for Process

Act management, attributed to Edward Deming. Plan-Do-Check-Act is also called
the Deming Cycle.
PLAN: Design or revise Processes that support the TI Services.
DO: Implement the Plan and manage the Processes.
CHECK: Measure the Processes and TI Services, compare with Objetivos and
produce reports
ACT: Plan and implement Changes to improve the Processes.
Planned (Service Design) Agreed time when an TI Service will not be available. Planned
Downtime Downtime is often used for maintenance, upgrades and testing.
See Change Window, Downtime.
Planning An Actividad responsible for creating one or more Plans. For example, Capacity
Planning.

Term Definition
PMBOK A Project management Standard maintained and published by the Project
Management Institute. PMBOK stands for Project Management Body of
Knowledge. See http://www.pmi.org/ for more information.
See PRINCE2.
Policy Formally documented management expectations and intentions. Policies are

used to direct decisions, and to ensure consistent and appropriate development
and implementation of Processes, Standards, Roles, Activities, TI Infrastructure
etc.
Portable Facility (Service Design) A prefabricated building, or a large vehicle, provided by a

Third Party and moved to a site when needed by an TI Service Continuity Plan.
See Recovery Option, Fixed Facility.
Post A Review that takes place after a Change or a Project has been implemented. A
Implementation PIR determines if the Change or Project was successful, and identifies
Review (PIR) opportunities for improvement.
Practice A way of working, or a way in which work must be done. Practices can include
Activities, Processes, Functions, Standards and Guidelines.
See Best Practice.
Prerequisite for An Actividad that needs to be completed, or a condition that needs to be met, to
Success (PFS) enable successful implementation of a Plan or Process. A PFS is often an
output from one Process that is a required input to another Process.
Pricing (Service Strategy) The Actividad for establishing how much Customers will be
Charged.
PRINCE2 The standard UK government methodology for Project management. See

http://www.ogc.gov.uk/prince2/ for more information.
See PMBOK.
Priority (Service Transition) (Service Operation) A Category used to identify the

relative importance of an Incident, Problem or Change. Priority is based on
Impact and Urgency, and is used to identify required times for actions to be
taken. For example the SLA may state that Priority2 Incidents must be resolved
within 12 hours.
Proactive (Service Operation) Monitoring that looks for patterns of Events to predict
Monitoring possible future Failures.
See Reactive Monitoring.
Proactive (Service Operation) Part of the Problem Management Process. The Objetivo of
Problem Proactive Problem Management is to identify Problems that might otherwise be
Management missed. Proactive Problem Management analyses Incident Records, and uses
data collected by other TI Service Management Processes to identify trends or
significant Problems.
Problem (Service Operation) A cause of one or more Incidents. The cause is not usually
known at the time a Problem Record is created, and the Problem Management
Process is responsible for further investigation.
Problem (Service Operation) The Process responsible for managing the Lifecycle of all
Management Problems. The primary Objetivos of Problem Management are to prevent
Incidents from happening, and to minimise the Impact of Incidents that cannot
be prevented.

Term Definition
Problem Record (Service Operation) A Record containing the details of a Problem. Each
Problem Record documents the Lifecycle of a single Problem.
Procedure A Document containing Pasos that specify how to achieve an Actividad.

Procedures are defined as part of Processes.
See Work Instruction.
Process A structured set of Activities designed to accomplish a specific Objetivo. A

Process takes one or more defined inputs and turns them into defined outputs.
A Process may include any of the Roles, responsibilities, tools and management
Controls required to reliably deliver the outputs. A Process may define Policies,
Standards, Guidelines, Activities, and Work Instructions if they are needed.
Process Control The Actividad of planning and regulating a Process, with the Objetivo of
performing the Process in an Effective, Efficient, and consistent manner.
Process A Role responsible for Operational management of a Process. The Process

Manager Manager's responsibilities include Planning and co-ordination of all Activities
required to carry out, monitor and report on the Process. There may be several
Process Managers for one Process, for example regional Change Managers or
TI Service Continuity Managers for each data centre. The Process Manager
Role is often assigned to the person who carries out the Process Owner Role,
but the two Roles may be separate in larger Organisations.
Process Owner A Role responsible for ensuring that a Process is Fit for Purpose. The Process
Owner’s responsibilities include sponsorship, Design, Change Management and
continual improvement of the Process and its Metrics. This Role is often
assigned to the same person who carries out the Process Manager Role, but
the two Roles may be separate in larger Organisations.
Production Synonym for Live Environment.

Environment
Profit Centre (Service Strategy) A Business Unit which charges for Services provided. A
Profit Centre can be created with the Objetivo of making a profit, recovering
Costs, or running at a loss. An TI Proveedor de Servicios can be run as a Cost
Centre or a Profit Centre.
pro-forma A template, or example Document containing example data that will be replaced
with the real values when these are available.
Programme A number of Projects and Activities that are planned and managed together to
achieve an overall set of related Objetivos and other Outcomes.
Project A temporary Organisation, with people and other Assets required to achieve an
Objetivo or other Outcome. Each Project has a Lifecycle that typically includes
initiation, Planning, execution, Closure etc. Projects are usually managed using
a formal methodology such as PRINCE2.
Projected (Service Transition) A Document that identifies the effect of planned Changes,
Service Outage maintenance Activities and Test Plans on agreed Service Levels.
(PSO)
PRojects IN See PRINCE2

Controlled
Environments
(PRINCE2)

Term Definition
Qualification (Service Transition) An Actividad that ensures that TI Infrastructure is
appropriate, and correctly configured, to support an Application or TI Service.
See Validation.
Quality The ability of a product, Service, or Process to provide the intended value. For
example, a hardware Component can be considered to be of high Quality if TI
performs as expected and delivers the required Reliability. Process Quality also
requires an ability to monitor Effectiveness and Efficiency, and to improve them
if necessary.
See Quality Management System.
Quality (Service Transition) The Process responsible for ensuring that the Quality of a
Assurance (QA) product, Service or Process will provide its intended Value.
Quality (Continual Service Improvement) The set of Processes responsible for

Management ensuring that all work carried out by an Organisation is of a suitable Quality to
System (QMS) reliably meet Business Objetivos or Service Levels.
See ISO 9000.
Quick Win (Continual Service Improvement) An improvement Actividad which is

expected to provide a Return on Investment in a short period of time with
relatively small Cost and effort.
See Pareto Principle.
RACI (Service Design) (Continual Service Improvement) A Model used to help

define Roles and Responsibilities. RACI stands for Responsible, Accountable,
Consulted and Informed.
See Stakeholder.
Reactive (Service Operation) Monitoring that takes action in response to an Event. For
Monitoring example submitting a batch job when the previous job completes, or logging an
Incident when an Error occurs.
See Proactive Monitoring.
Reciprocal (Service Design) A Recovery Option. An agreement between two

Arrangement Organisations to share resources in an emergency. For example, Computer
Room space or use of a mainframe.
Record A Document containing the results or other output from a Process or Actividad.
Records are evidence of the fact that an Actividad took place and may be paper
or electronic. For example, an Audit report, an Incident Record, or the minutes
of a meeting.
Recovery (Service Design) (Service Operation) Returning a Configuration Item or an TI

Service to a working state. Recovery of an TI Service often includes recovering
data to a known consistent state. After Recovery, further Pasos may be needed
before the TI Service can be made available to the Users (Restoration).
Recovery Option (Service Design) A Strategy for responding to an interruption to Service.

Commonly used Strategies are Do Nothing, Manual Workaround, Reciprocal
Arrangement, Gradual Recovery, Intermediate Recovery, Fast Recovery,
Immediate Recovery. Recovery Options may make use of dedicated facilities, or
Third Party facilities shared by multiple Businesses.

Term Definition
Recovery Point (Service Operation) The maximum amount of data that may be lost when
Objetivo (RPO) Service is Restored after an interruption. Recovery Point Objetivo is expressed
as a length of time before the Failure. For example a Recovery Point Objetivo of
one day may be supported by daily Backups, and up to 24 hours of data may be
lost. Recovery Point Objetivos for each TI Service should be negotiated, agreed
and documented, and used as Requirements for Service Design and TI Service
Continuity Plans.
Recovery Time (Service Operation) The maximum time allowed for recovery of an TI Service
Objetivo (RTO) following an interruption. The Service Level to be provided may be less than
normal Service Level Targets. Recovery Time Objetivos for each TI Service
should be negotiated, agreed and documented.
See Business Impact Analysis.
Redundancy Synonym for Fault Tolerance.

The term Redundant also has a generic meaning of obsolete, or no longer
needed.
Relationship A connection or interaction between two people or things. In Business

Relationship Management TI is the interaction between the TI Proveedor de
Servicios and the Business. In Configuration Management TI is a link between
two Configuration Items that identifies a dependency or connection between
them. For example Applications may be linked to the Servers they run on, TI
Services have many links to all the CIs that contribute to them.
Relationship The ISO/IEC 20000 Process group that includes Business Relationship
Processes Management and Supplier Management.
Release (Service Transition) A collection of hardware, software, documentation,

Processes or other Components required to implement one or more approved
Changes to TI Services. The contents of each Release are managed, Tested,
and Deployed as a single entity.
Release and (Service Transition) The Process responsible for both Release Management
Deployment and Deployment.
Management
Release (Service Transition) A naming convention used to uniquely identify a Release.

Identification The Release Identification typically includes a reference to the Configuration
Item and a version number. For example Microsoft Office 2003 SR2.
Release (Service Transition) The Process responsible for Planning, scheduling and
Management controlling the movement of Releases to Test and Live Environments. The
primary Objetivo of Release Management is to ensure that the integrity of the
Live Environment is protected and that the correct Components are released.
Release Management is part of the Release and Deployment Management
Process.
Release Process The name used by ISO/IEC 20000 for the Process group that includes Release
Management. This group does not include any other Processes.
Release Process is also used as a synonym for Release Management Process.
Release Record (Service Transition) A Record in the CMDB that defines the content of a
Release. A Release Record has Relationships with all Configuration Items that
are affected by the Release.

Term Definition
Release Unit (Service Transition) Components of an TI Service that are normally Released
together. A Release Unit typically includes sufficient Components to perform a
useful Function. For example one Release Unit could be a Desktop PC,
including Hardware, Software, Licenses, Documentation etc. A different Release
Unit may be the complete Payroll Application, including TI Operations
Procedures and User training.
Release Window Synonym for Change Window.
Reliability (Service Design) (Continual Service Improvement) A measure of how long a

Configuration Item or TI Service can perform its agreed Function without
interruption. Usually measured as MTBF or MTBSI. The term Reliability can also
be used to state how likely TI is that a Process, Function etc. will deliver its
required outputs.
See Availability.
Remediation (Service Transition) Recovery to a known state after a failed Change or

Release.
Repair (Service Operation) The replacement or correction of a failed Configuration

Item.
Request for (Service Transition) A formal proposal for a Change to be made. An RFC
Change (RFC) includes details of the proposed Change, and may be recorded on paper or
electronically. The term RFC is often misused to mean a Change Record, or the
Change itself.
Request (Service Operation) The Process responsible for managing the Lifecycle of all
Fulfilment Service Requests.
Requirement (Service Design) A formal statement of what is needed. For example a Service
Level Requirement, a Project Requirement or the required Deliverables for a
Process.
See Statement of Requirements.
Resilience (Service Design) The ability of a Configuration Item or TI Service to resist

Failure or to Recover quickly following a Failure. For example, an armoured
cable will resist failure when put under stress.
See Fault Tolerance.
Resolution (Service Operation) Action taken to repair the Root Cause of an Incident or
Problem, or to implement a Workaround.
In ISO/IEC 20000, Resolution Processes is the Process group that includes
Incident and Problem Management.
Resolution The ISO/IEC 20000 Process group that includes Incident Management and
Processes Problem Management.
Resource (Service Strategy) A generic term that includes TI Infrastructure, people,

money or anything else that might help to deliver an TI Service. Resources are
considered to be Assets of an Organisation.
See Capability, Service Asset.
Response Time A measure of the time taken to complete an Operation or Transaction. Used in
Capacity Management as a measure of TI Infrastructure Performance, and in
Incident Management as a measure of the time taken to answer the phone, or to
start Diagnosis.

Term Definition
Responsiveness A measurement of the time taken to respond to something. This could be
Response Time of a Transaction, or the speed with which an TI Proveedor de
Servicios responds to an Incident or Request for Change etc.
Restoration of See Restore.

Service
Restore (Service Operation) Taking action to return an TI Service to the Users after
Repair and Recovery from an Incident. This is the primary Objetivo of Incident
Management.
Retire (Service Transition) Permanent removal of an TI Service, or other

Configuration Item, from the Live Environment. Retired is a stage in the
Lifecycle of many Configuration Items.
Return on (Service Strategy) (Continual Service Improvement) A measurement of the

Investment (ROI) expected benefit of an investment. In the simplest sense TI is the net profit of an
investment divided by the net worth of the assets invested.
See Net Present Value, Value on Investment.
Return to Normal (Service Design) The phase of an TI Service Continuity Plan during which full
normal operations are resumed. For example, if an alternate data centre has
been in use, then this phase will bring the primary data centre back into
operation, and restore the ability to invoke TI Service Continuity Plans again.
Review An evaluation of a Change, Problem, Process, Project etc. Reviews are typically
carried out at predefined points in the Lifecycle, and especially after Closure.
The purpose of a Review is to ensure that all Deliverables have been provided,
and to identify opportunities for improvement.
See Post Implementation Review.
Rights (Service Operation) Entitlements, or permissions, granted to a User or Role.

For example the Right to modify particular data, or to authorize a Change.
Risk A possible Event that could cause harm or loss, or affect the ability to achieve
Objetivos. A Risk is measured by the probability of a Threat, the Vulnerability of
the Asset to that Threat, and the Impact TI would have if TI occurred.
Risk The initial Pasos of Risk Management. Analysing the value of Assets to the
Assessment business, identifying Threats to those Assets, and evaluating how Vulnerable
each Asset is to those Threats. Risk Assessment can be quantitative (based on
numerical data) or qualitative.
Risk The Process responsible for identifying, assessing and controlling Risks.
Management See Risk Assessment.
Role A set of responsibilities, Activities and authorities granted to a person or team. A

Role is defined in a Process. One person or team may have multiple Roles, for
example the Roles of Configuration Manager and Change Manager may be
carried out by a single person.
Rollout (Service Transition) Synonym for Deployment. Most often used to refer to
complex or phased Deployments or Deployments to multiple locations.
Root Cause (Service Operation) The underlying or original cause of an Incident or Problem.

Term Definition
Root Cause (Service Operation) An Actividad that identifies the Root Cause of an Incident
Analysis (RCA) or Problem. RCA typically concentrates on TI Infrastructure failures.
See Service Failure Analysis.
Running Costs Synonym for Operational Costs
Scalability The ability of an TI Service, Process, Configuration Item etc. to perform its
agreed Function when the Workload or Scope changes.
Scope The boundary, or extent, to which a Process, Procedure, Certification, Contract

etc. applies. For example the Scope of Change Management may include all
Live TI Services and related Configuration Items, the Scope of an ISO/IEC
20000 Certificate may include all TI Services delivered out of a named data
centre.
Second-line (Service Operation) The second level in a hierarchy of Support Groups

Support involved in the resolution of Incidents and investigation of Problems. Each level
contains more specialist skills, or has more time or other Resources.
Security See Information Security Management
Security Synonym for Information Security Management

Management
Security Policy Synonym for Information Security Policy
Separation of (Service Strategy) An approach to Designing a solution or TI Service that

Concerns (SoC) divides the problem into pieces that can be solved independently. This approach
separates "what" is to be done from "how" TI is to be done.
Server (Service Operation) A computer that is connected to a network and provides

software Functions that are used by other computers.
Service A means of delivering value to Customers by facilitating Outcomes Customers

want to achieve without the ownership of specific Costs and Risks.
Service (Service Transition) A set of criteria used to ensure that an TI Service meets its
Acceptance functionality and Quality Requirements and that the TI Proveedor de Servicios is
Criteria (SAC) ready to Operate the new TI Service when TI has been Deployed.
See Acceptance.
Service (Service Strategy) A technique used in the Assessment of the Business Impact
Analytics of Incidents. Service Analytics Models the dependencies between Configuration
Items, and the dependencies of TI Services on Configuration Items.
Service Asset Any Capability or Resource of a Proveedor de Servicios.

See Asset.
Service Asset (Service Transition) The Process responsible for both Configuration
and Management and Asset Management.
Configuration
Management
(SACM)
Service Capacity (Service Design) (Continual Service Improvement) The Actividad responsible
Management for understanding the Performance and Capacity of TI Services. The Resources
(SCM) used by each TI Service and the pattern of usage over time are collected,
recorded, and analysed for use in the Capacity Plan.
See Business Capacity Management, Component Capacity Management.

Term Definition
Service (Service Design) A database or structured Document with information about all
Catalogue Live TI Services, including those available for Deployment. The Service
Catalogue is the only part of the Service Portfolio published to Customers, and
is used to support the sale and delivery of TI Services. The Service Catalogue
includes information about deliverables, prices, contact points, ordering and
request Processes.
See Contract Portfolio.
Service Synonym for TI Service Continuity Management.

Continuity
Management
Service Contract (Service Strategy) A Contract to deliver one or more TI Services. The term
Service Contract is also used to mean any Agreement to deliver TI Services,
whether this is a legal Contract or an SLA.
See Contract Portfolio.
Service Culture A Customer oriented Culture. The major Objetivos of a Service Culture are
Customer satisfaction and helping the Customer to achieve their Business
Objetivos.
Service Design (Service Design) A stage in the Lifecycle of an TI Service. Service Design
includes a number of Processes and Functions and is the title of one of the Core
ITIL® publications.
See Design.
Service Design (Service Design) Document(s) defining all aspects of an TI Service and its
Package Requirements through each stage of its Lifecycle. A Service Design Package is
produced for each new TI Service, major Change, or TI Service Retirement.
Service Desk (Service Operation) The Single Point of Contact between the Proveedor de
Servicios and the Users. A typical Service Desk manages Incidents and Service
Requests, and also handles communication with the Users.
Service Failure (Service Design) An Actividad that identifies underlying causes of one or more
Analysis (SFA) TI Service interruptions. SFA identifies opportunities to improve the TI
Proveedor de Servicios's Processes and tools, and not just the TI Infrastructure.
SFA is a time constrained, project-like Actividad, rather than an ongoing process
of analysis.
See Root Cause Analysis.
Service Hours (Service Design) (Continual Service Improvement) An agreed time period
when a particular TI Service should be Available. For example, "Monday-Friday
08:00 to 17:00 except public holidays". Service Hours should be defined in a
Service Level Agreement.
Service (Continual Service Improvement) A formal Plan to implement improvements

Improvement to a Process or TI Service.
Plan (SIP)
Service (Service Transition) A set of tools and databases that are used to manage
Knowledge knowledge and information. The SKMS includes the Configuration Management
Management System, as well as other tools and databases. The SKMS stores, manages,
System (SKMS)
updates, and presents all information that an TI Proveedor de Servicios needs
to manage the full Lifecycle of TI Services.
Service Level Measured and reported achievement against one or more Service Level
Targets. The term Service Level is sometimes used informally to mean Service
Level Target.

Term Definition
Service Level (Service Design) (Continual Service Improvement) An Agreement between
Agreement (SLA) an TI Proveedor de Servicios and a Customer. The SLA describes the TI
Service, documents Service Level Targets, and specifies the responsibilities of
the TI Proveedor de Servicios and the Customer. A single SLA may cover
multiple TI Services or multiple Customers.
See Operational Level Agreement.
Service Level (Service Design) (Continual Service Improvement) The Process responsible
Management for negotiating Service Level Agreements, and ensuring that these are met. SLM
(SLM) is responsible for ensuring that all TI Service Management Processes,
Operational Level Agreements, and Underpinning Contracts, are appropriate for
the agreed Service Level Targets. SLM monitors and reports on Service Levels,
and holds regular Customer reviews.
Service Level (Service Strategy) A defined level of Utility and Warranty for a particular
Package (SLP) Service Package. Each SLP is designed to meet the needs of a particular
Pattern of Business Actividad.
See Line of Service.
Service Level (Service Design) (Continual Service Improvement) A Customer Requirement

Requirement for an aspect of an TI Service. SLRs are based on Business Objetivos and are
(SLR) used to negotiate agreed Service Level Targets.
Service Level (Service Design) (Continual Service Improvement) A commitment that is

Target documented in a Service Level Agreement. Service Level Targets are based on
Service Level Requirements, and are needed to ensure that the TI Service
design is Fit for Purpose. Service Level Targets should be SMART, and are
usually based on KPIs.
Service (Service Operation) The expected time that a Configuration Item will be
Maintenance unavailable due to planned maintenance Actividad.
Objetivo
Service Service Management is a set of specialized organizational capabilities for

Management providing value to customers in the form of services.
Service An approach to TI Service Management that emphasizes the importance of

Management coordination and Control across the various Functions, Processes, and Systems
Lifecycle necessary to manage the full Lifecycle of TI Services. The Service Management
Lifecycle approach considers the Strategy, Design, Transition, Operation and
Continuous Improvement of TI Services.
Service Manager A manager who is responsible for managing the end-to-end Lifecycle of one or
more TI Services. The term Service Manager is also used to mean any manager
within the TI Proveedor de Servicios. Most commonly used to refer to a
Business Relationship Manager, a Process Manager, an Account Manager or a
senior manager with responsibility for TI Services overall.
Service (Service Operation) A stage in the Lifecycle of an TI Service. Service

Operation Operation includes a number of Processes and Functions and is the title of one
of the Core ITIL® publications.
See Operation.
Service Owner (Continual Service Improvement) A Role which is accountable for the delivery
of a specific TI Service.
Service Package (Service Strategy) A detailed description of an TI Service that is available to be

delivered to Customers. A Service Package includes a Service Level Package
and one or more Core Services and Supporting Services.
Term Definition
Service Pipeline (Service Strategy) A database or structured Document listing all TI Services
that are under consideration or Development, but are not yet available to
Customers. The Service Pipeline provides a Business view of possible future TI
Services and is part of the Service Portfolio which is not normally published to
Customers.
Service Portfolio (Service Strategy) The complete set of Services that are managed by a
Proveedor de Servicios. The Service Portfolio is used to manage the entire
Lifecycle of all Services, and includes three Categories: Service Pipeline
(proposed or in Development); Service Catalogue (Live or available for
Deployment); and Retired Services.
See Service Portfolio Management, Contract Portfolio.
Service Portfolio (Service Strategy) The Process responsible for managing the Service Portfolio.
Management Service Portfolio Management considers Services in terms of the Business
(SPM) value that they provide.
Service Potential (Service Strategy) The total possible value of the overall Capabilities and
Resources of the TI Proveedor de Servicios.
Proveedor de (Service Strategy) An Organisation supplying Services to one or more Internal

Servicios Customers or External Customers. Proveedor de Servicios is often used as an
abbreviation for TI Proveedor de Servicios.
See Type I Proveedor de Servicios, Type II Proveedor de Servicios, Type III
Proveedor de Servicios.
Proveedor de (Service Strategy) An interface between the TI Proveedor de Servicios and a

Servicios User, Customer, Business Process, or a Supplier. Analysis of Proveedor de
Interface (SPI) Servicios Interfaces helps to coordinate end-to-end management of TI Services.
Service (Service Strategy) Analysing the finances and constraints of an TI Service to

Provisioning decide if alternative approaches to Service delivery might reduce Costs or
Optimization improve Quality.
(SPO)
Service (Continual Service Improvement) The Process responsible for producing and
Reporting delivering reports of achievement and trends against Service Levels. Service
Reporting should agree the format, content and frequency of reports with
Customers.
Service Request (Service Operation) A request from a User for information, or advice, or for a
Standard Change or for Access to an TI Service. For example to reset a
password, or to provide standard TI Services for a new User. Service Requests
are usually handled by a Service Desk, and do not require an RFC to be
submitted.
See Request Fulfilment.
Service Sourcing (Service Strategy) The Strategy and approach for deciding whether to provide
a Service internally or to Outsource TI to an External Proveedor de Servicios.
Service Sourcing also means the execution of this Strategy.
Service Sourcing includes:
 Internal Sourcing - Internal or Shared Services using Type I or Type II
Proveedor de Servicioss.
 Traditional Sourcing - Full Service Outsourcing using a Type III Proveedor
de Servicios.
 Multivendor Sourcing - Prime, Consortium or Selective Outsourcing using
Type III Proveedor de Servicioss.

Term Definition
Service Strategy (Service Strategy) The title of one of the Core ITIL® publications. Service
Strategy establishes an overall Strategy for TI Services and for TI Service
Management.
Service (Service Transition) A stage in the Lifecycle of an TI Service. Service

Transition Transition includes a number of Processes and Functions and is the title of one
of the Core ITIL® publications.
See Transition.
Service Utility (Service Strategy) The Functionality of an TI Service from the Customer's
perspective. The Business value of an TI Service is created by the combination
of Service Utility (what the Service does) and Service Warranty (how well TI
does TI).
See Utility.
Service (Service Transition) The Process responsible for Validation and Testing of a
Validation and new or Changed TI Service. Service Validation and Testing ensures that the TI
Testing Service matches its Design Specification and will meet the needs of the
Business.
Service (Service Strategy) A measurement of the total Cost of delivering an TI Service,

Valuation and the total value to the Business of that TI Service. Service Valuation is used
to help the Business and the TI Proveedor de Servicios agree on the value of
the TI Service.
Service Warranty (Service Strategy) Assurance that an TI Service will meet agreed
Requirements. This may be a formal Agreement such as a Service Level
Agreement or Contract, or may be a marketing message or brand image. The
Business value of an TI Service is created by the combination of Service Utility
(what the Service does) and Service Warranty (how well TI does TI).
See Warranty.
Serviceability (Service Design) (Continual Service Improvement) The ability of a Third

Party Supplier to meet the terms of their Contract. This Contract will include
agreed levels of Reliability, Maintainability or Availability for a Configuration
Item.
Shift (Service Operation) A group or team of people who carry out a specific Role for
a fixed period of time. For example there could be four shifts of TI Operations
Control personnel to support an TI Service that is used 24 hours a day.
Simulation (Service Design) (Continual Service Improvement) A technique that creates

modelling a detailed Model to predict the behaviour of a Configuration Item or TI Service.
Simulation Models can be very accurate but are expensive and time consuming
to create. A Simulation Model is often created by using the actual Configuration
Items that are being modelled, with artificial Workloads or Transactions. They
are used in Capacity Management when accurate results are important. A
simulation model is sometimes called a Performance Benchmark.
Single Point of (Service Operation) Providing a single consistent way to communicate with an
Contact Organisation or Business UnTI. For example, a Single Point of Contact for an TI
Proveedor de Servicios is usually called a Service Desk.
Single Point of (Service Design) Any Configuration Item that can cause an Incident when TI
Failure (SPOF) fails, and for which a Countermeasure has not been implemented. A SPOF may
be a person, or a Paso in a Process or Actividad, as well as a Component of the
TI Infrastructure.
See Failure.

Term Definition
SLAM Chart (Continual Service Improvement) A Service Level Agreement Monitoring
Chart is used to help monitor and report achievements against Service Level
Targets. A SLAM Chart is typically colour coded to show whether each agreed
Service Level Target has been met, missed, or nearly missed during each of the
previous 12 months.
SMART (Service Design) (Continual Service Improvement) An acronym for helping to

remember that targets in Service Level Agreements and Project Plans should be
Specific, Measurable, Achievable, Relevant and Timely.
Snapshot (Service Transition) The current state of a Configuration as captured by a

discovery tool.
Also used as a synonym for Benchmark.
See Baseline.
Source See Service Sourcing.
Specification A formal definition of Requirements. A Specification may be used to define

technical or Operational Requirements, and may be internal or external. Many
public Standards consist of a Code of Practice and a Specification. The
Specification defines the Standard against which an Organisation can be
Audited.
Stakeholder All people who have an interest in an Organisation, Project, TI Service etc.
Interesados may be interested in the Activities, targets, Resources, or
Deliverables. Interesados may include Customers, Partners, employees,
shareholders, owners, etc.
See RACI.
Standard A mandatory Requirement. Examples include ISO/IEC 20000 (an international

Standard), an internal security Standard for Unix configuration, or a government
Standard for how financial Records should be maintained. The term Standard is
also used to refer to a Code of Practice or Specification published by a
Standards Organisation such as ISO or BSI.
See Guideline.
Standard (Service Transition) A pre-approved Change that is low Risk, relatively

Change common and follows a Procedure or Work Instruction. For example password
reset or provision of standard equipment to a new employee. RFCs are not
required to implement a Standard Change, and they are logged and tracked
using a different mechanism, such as a Service Request.
See Change Model.
Standard (Service Operation) Procedures used by TI Operations Management.

Operating
Procedures
(SOP)
Standby (Service Design) Used to refer to Resources that are not required to deliver the
Live TI Services, but are available to support TI Service Continuity Plans. For
example a Standby data centre may be maintained to support Hot Standby,
Warm Standby or Cold Standby arrangements.
Statement of (Service Design) A Document containing all Requirements for a product

requirements purchase, or a new or changed TI Service.
(SOR) See Terms of Reference.

Term Definition
Estado The name of a required field in many types of Record. TI shows the current
stage in the Lifecycle of the associated Configuration Item, Incident, Problem
etc.
Estado (Service Transition) The Actividad responsible for recording and reporting the
Accounting Lifecycle of each Configuration Item.
Storage (Service Operation) The Process responsible for managing the storage and
Management maintenance of data throughout its Lifecycle.
Strategic (Service Strategy) The highest of three levels of Planning and delivery
(Strategic, Tactical, Operational). Strategic Activities include Objetivo setting
and long term Planning to achieve the overall Vision.
Strategy (Service Strategy) A Strategic Plan designed to achieve defined Objetivos.
Super User (Service Operation) A User who helps other Users, and assists in
communication with the Service Desk or other parts of the TI Proveedor de
Servicios. Super Users typically provide support for minor Incidents and training.
Supplier (Service Strategy) (Service Design) A Third Party responsible for supplying
goods or Services that are required to deliver TI services. Examples of suppliers
include commodity hardware and software vendors, network and telecom
providers, and Outsourcing Organisations.
See Underpinning Contract, Supply Chain.
Supplier and (Service Design) A database or structured Document used to manage Supplier
Contract Contracts throughout their Lifecycle. The SCMIS contains key Attributes of all
Database Contracts with Suppliers, and should be part of the Service Knowledge
(SCMIS)
Management System.
Supplier (Service Design) The Process responsible for ensuring that all Contracts with
Management Suppliers support the needs of the Business, and that all Suppliers meet their
contractual commitments.
Supply Chain (Service Strategy) The Activities in a Value Chain carried out by Suppliers. A
Supply Chain typically involves multiple Suppliers, each adding value to the
product or Service.
See Value Network.
Support Group (Service Operation) A group of people with technical skills. Support Groups
provide the Technical Support needed by all of the TI Service Management
Processes.
See Technical Management.
Support Hours (Service Design) (Service Operation) The times or hours when support is
available to the Users. Typically this is the hours when the Service Desk is
available. Support Hours should be defined in a Service Level Agreement, and
may be different from Service Hours. For example, Service Hours may be 24
hours a day, but the Support Hours may be 07:00 to 19:00.
Supporting (Service Strategy) A Service that enables or enhances a Core Service. For
Service example a Directory Service or a Backup Service.
See Service Package.

Term Definition
SWOT Analysis (Continual Service Improvement) A technique that reviews and analyses the
internal strengths and weaknesses of an Organisation and the external
opportunities and threats which TI faces SWOT stands for Strengths,
Weaknesses, Opportunities and Threats.
System A number of related things that work together to achieve an overall Objetivo. For
example:
 A computer System including hardware, software and Applications.
 A management System, including multiple Processes that are planned and
managed together. For example a Quality Management System.
 A Database Management System or Operating System that includes many
software modules that are designed to perform a set of related Functions.
System The part of TI Service Management that focuses on the management of TI

Management Infrastructure rather than Process.
Tactical The middle of three levels of Planning and delivery (Strategic, Tactical,
Operational). Tactical Activities include the medium term Plans required to
achieve specific Objetivos, typically over a period of weeks to months.
Tag (Service Strategy) A short code used to identify a Category. For example tags
EC1, EC2, EC3 etc. might be used to identify different Customer outcomes
when analysing and comparing Strategies. The term Tag is also used to refer to
the Actividad of assigning Tags to things.
Technical (Service Operation) The Function responsible for providing technical skills in
Management support of TI Services and management of the TI Infrastructure. Technical
Management defines the Roles of Support Groups, as well as the tools,
Processes and Procedures required.
Technical (Continual Service Improvement) A technique used in Service Improvement,

Observation (TO) Problem investigation and Availability Management. Technical support staff
meet to monitor the behaviour and Performance of an TI Service and make
recommendations for improvement.
Technical Synonym for Infrastructure Service.

Service
Technical Synonym for Technical Management.

Support
Tension Metrics (Continual Service Improvement) A set of related Metrics, in which

improvements to one Metric have a negative effect on another. Tension Metrics
are designed to ensure that an appropriate balance is achieved.
Terms of (Service Design) A Document specifying the Requirements, Scope,

Reference (TOR) Deliverables, Resources and schedule for a Project or Actividad.
Test (Service Transition) An Actividad that verifies that a Configuration Item, TI

Service, Process, etc. meets its Specification or agreed Requirements.
See Service Validation and Testing, Acceptance.
Test (Service Transition) A controlled Environment used to Test Configuration

Environment Items, Builds, TI Services, Processes etc.

Term Definition
Third Party A person, group, or Business who is not part of the Service Level Agreement for
an TI Service, but is required to ensure successful delivery of that TI Service.
For example a software Supplier, a hardware maintenance company, or a
facilities department. Requirements for Third Parties are typically specified in
Underpinning Contracts or Operational Level Agreements.
Third-line (Service Operation) The third level in a hierarchy of Support Groups involved in
Support the resolution of Incidents and investigation of Problems. Each level contains
more specialist skills, or has more time or other Resources.
Threat Anything that might exploit a Vulnerability. Any potential cause of an Incident
can be considered to be a Threat. For example a fire is a Threat that could
exploit the Vulnerability of flammable floor coverings. This term is commonly
used in Information Security Management and TI Service Continuity
Management, but also applies to other áreas such as Problem and Availability
Management.
Threshold The value of a Metric which should cause an Alert to be generated, or

management action to be taken. For example "Priority1 Incident not solved
within 4 hours", "more than 5 soft disk errors in an hour", or "more than 10 failed
changes in a month".
Throughput (Service Design) A measure of the number of Transactions, or other

Operations, performed in a fixed time. For example 5000 emails sent per hour,
or 200 disk I/Os per second.
Total Cost of (Service Strategy) A methodology used to help make investment decisions.
Ownership (TCO) TCO assesses the full Lifecycle Cost of owning a Configuration Item, not just the
initial Cost or purchase price.
See Total Cost of Utilization.
Total Cost of (Service Strategy) A methodology used to help make investment and Service
Utilization (TCU) Sourcing decisions. TCU assesses the full Lifecycle Cost to the Customer of
using an TI Service.
See Total Cost of Ownership.
Total Quality (Continual Service Improvement) A methodology for managing continual

Management Improvement by using a Quality Management System. TQM establishes a
(TQM) Culture involving all people in the Organisation in a Process of continual
monitoring and improvement.
Transaction A discrete Function performed by an TI Service. For example transferring

money from one bank account to another. A single Transaction may involve
numerous additions, deletions and modifications of data. Either all of these
complete successfully or none of them is carried out.
Transition (Service Transition) A change in state, corresponding to a movement of an TI

Service or other Configuration Item from one Lifecycle estado to the next.
Transition (Service Transition) The Process responsible for Planning all Service
Planning and Transition Processes and co-ordinating the resources that they require. These
Support Service Transition Processes are Change Management, Service Asset and
Configuration Management, Release and Deployment Management, Service
Validation and Testing, Evaluation, and Knowledge Management.

Term Definition
Trend Analysis (Continual Service Improvement) Analysis of data to identify time related
patterns. Trend Analysis is used in Problem Management to identify common
Failures or fragile Configuration Items, and in Capacity Management as a
Modelling tool to predict future behaviour. TI is also used as a management tool
for identifying deficiencies in TI Service Management Processes.
Tuning The Actividad responsible for Planning Changes to make the most efficient use
of Resources. Tuning is part of Performance Management, which also includes
Performance Monitoring and implementation of the required Changes.
Type I Proveedor (Service Strategy) An Internal Proveedor de Servicios that is embedded within
de Servicios a Business UnTI. There may be several Type I Proveedor de Servicioss within
an Organisation.
Type II (Service Strategy) An Internal Proveedor de Servicios that provides shared TI

Proveedor de Services to more than one Business UnTI.
Servicios
Type III (Service Strategy) A Proveedor de Servicios that provides TI Services to

Proveedor de External Customers.
Servicios
Underpinning (Service Design) A Contract between an TI Proveedor de Servicios and a Third

Contract (UC) Party. The Third Party provides goods or Services that support delivery of an TI
Service to a Customer. The Underpinning Contract defines targets and
responsibilities that are required to meet agreed Service Level Targets in an
SLA.
Unit Cost (Service Strategy) The Cost to the TI Proveedor de Servicios of providing a
single Component of an TI Service. For example the Cost of a single desktop
PC, or of a single Transaction.
Urgency (Service Transition) (Service Design) A measure of how long TI will be until
an Incident, Problem or Change has a significant Impact on the Business. For
example a high Impact Incident may have low Urgency, if the Impact will not
affect the Business until the end of the financial year. Impact and Urgency are
used to assign Priority.
Usability (Service Design) The ease with which an Application, product, or TI Service
can be used. Usability Requirements are often included in a Statement of
Requirements.
Use Case (Service Design) A technique used to define required functionality and
Objetivos, and to Design Tests. Use Cases define realistic scenarios that
describe interactions between Users and an TI Service or other System.
See Change Case.
User A person who uses the TI Service on a day-to-day basis. Users are distinct from
Customers, as some Customers do not use the TI Service directly.
User Profile (UP) (Service Strategy) A pattern of User demand for TI Services. Each User Profile
includes one or more Patterns of Business Actividad.
Utility (Service Strategy) Functionality offered by a Product or Service to meet a

particular need. Utility is often summarised as "what TI does".
See Service Utility.

Term Definition
Validation (Service Transition) An Actividad that ensures a new or changed TI Service,
Process, Plan, or other Deliverable meets the needs of the Business. Validation
ensures that Business Requirements are met even though these may have
changed since the original Design.
See Verification, Acceptance, Qualification, Service Validation and Testing.
Value Chain (Service Strategy) A sequence of Processes that creates a product or Service
that is of value to a Customer. Each Paso of the sequence builds on the
previous Pasos and contributes to the overall product or Service.
See Value Network.
Value for Money An informal measure of Cost Effectiveness. Value for Money is often based on a
comparison with the Cost of alternatives.
See Cost Benefit Analysis.
Value Network (Service Strategy) A complex set of Relationships between two or more groups
or organisations. Value is generated through exchange of knowledge,
information, goods or Services.
See Value Chain, Partnership.
Value on (Continual Service Improvement) A measurement of the expected benefit of

Investment (VOI) an investment. VOI considers both financial and intangible benefits.
See Return on Investment.
Variable Cost (Service Strategy) A Cost that depends on how much the TI Service is used,
how many products are produced, the number and type of Users, or something
else that cannot be fixed in advance.
See Variable Cost Dynamics.
Variable Cost (Service Strategy) A technique used to understand how overall Costs are
Dynamics impacted by the many complex variable elements that contribute to the provision
of TI Services.
Variance The difference between a planned value and the actual measured value.
Commonly used in Financial Management, Capacity Management and Service
Level Management, but could apply in any area where Plans are in place.
Verification (Service Transition) An Actividad that ensures a new or changed TI Service,

Process, Plan, or other Deliverable is complete, accurate, Reliable and matches
its Design Specification.
See Validation, Acceptance, Service Validation and Testing.
Verification and (Service Transition) The Activities responsible for ensuring that information in
Audit the CMDB is accurate and that all Configuration Items have been identified and
recorded in the CMDB. Verification includes routine checks that are part of other
Processes. For example, verifying the serial number of a desktop PC when a
User logs an Incident. Audit is a periodic, formal check.
Version (Service Transition) A Version is used to identify a specific Baseline of a

Configuration Item. Versions typically use a naming convention that enables the
sequence or date of each Baseline to be identified. For example Payroll
Application Version 3 contains updated functionality from Version 2.
Vision A description of what the Organisation intends to become in the future. A Vision
is created by senior management and is used to help influence Culture and
Strategic Planning.

Term Definition
Vital Business (Service Design) A Function of a Business Process which is critical to the
Function (VBF) success of the Business. Vital Business Functions are an important
consideration of Business Continuity Management, TI Service Continuity
Management and Availability Management.
Vulnerability A weakness that could be exploited by a Threat. For example an open firewall
port, a password that is never changed, or a flammable carpet. A missing
Control is also considered to be a Vulnerability.
Warm Standby Synonym for Intermediate Recovery.
Warranty (Service Strategy) A promise or guarantee that a product or Service will meet
its agreed Requirements.
See Service Validation and Testing, Service Warranty.
Work in A Estado that means Activities have started but are not yet complete. TI is
Progress (WIP) commonly used as a Estado for Incidents, Problems, Changes etc.
Work Instruction A Document containing detailed instructions that specify exactly what Pasos to
follow to carry out an Actividad. A Work Instruction contains much more detail
than a Procedure and is only created if very detailed instructions are needed.
Workaround (Service Operation) Reducing or eliminating the Impact of an Incident or

Problem for which a full Resolution is not yet available. For example by
restarting a failed Configuration Item. Workarounds for Problems are
documented in Known Error Records. Workarounds for Incidents that do not
have associated Problem Records are documented in the Incident Record.
Workload The Resources required to deliver an identifiable part of an TI Service.

Workloads may be Categorised by Users, groups of Users, or Functions within
the TI Service. This is used to assist in analysing and managing the Capacity,
Performance and Utilisation of Configuration Items and TI Services. The term
Workload is sometimes used as a synonym for Throughput.

Glosario por orden alfabético Español .9
C. Términos y Definiciones
Término Definición
Aceptación [Acceptance] Acuerdo formal que indica que un Servicio de TI, Proceso, Plan, u otro
Entregable se han completado, es preciso, Confiable y cumple con los
Requisitos especificados. Normalmente la Aceptación es precedida por
una Evaluación o Prueba y es requerida antes de proceder con la
siguiente fase de un Proyecto o Proceso. Ver Criterio de Aceptación del
Servicio.
Acreditado [Accredited] Autorizado oficialmente para un Rol. Por ejemplo, una organización
acreditada podría estar autorizada para impartir cursos o para dirigir una
Auditoría.
Actividad [Actividad] Un conjunto de acciones diseñadas para alcanzar un resultado específico.
Normalmente, las Actividades se definen como parte de Procesos o
Planes, y se documentan en Procedimientos.
Activo [Asset] (Estrategia del Servicio) Cualquier Recurso o Capacidad. Los Activos de
un Proveedor de Servicio incluyen todo aquello que se pueda atribuir a la
entrega del Servicio. Los Activos pueden ser de los siguientes tipos:
Administrativos, Organizativos, de Proceso, de Conocimiento, Personas,
Información, Aplicaciones, Infraestructura, y de Capital.
Activos de Servicio [Service Cualquier Capacidad o Recurso de un Proveedor de Servicio. Ver Activos.
Asset]
Activos de Servicio y Gestión (Transición del Servicio) El Proceso responsable por ambos, Gestión de
de Configuración [Service Configuración y Gestión de Activos.
Asset and Configuration
Management] (SACM)
Acuerdo [Agreement] Documento que describe el entendimiento formal entre dos o más partes.
Un Acuerdo no tiene fuerza legal, a menos que forme parte de un
Contrato. Ver Acuerdo de Nivel de Servicio, Acuerdo de Nivel de
Operación.
Acuerdo de Nivel de Servicio (Diseño del Servicio) (Mejora Continua del Servicio) Acuerdo entre un
[Service Level Agreement] Proveedor de Servicio de TI y un Cliente. El SLA describe el Servicio de
(SLA) TI, documenta los Objetivos de Nivel de Servicio y especifica las
responsabilidades del Proveedor de Servicio de TI y del Cliente. Un único
SLA puede curbir varios Servicios de TI o varios Clientes. Ver Acuerdo de
Nivel Operacional.
Acuerdo de Nivel Operativo (Diseño del Servicio) (Mejora Continua del Servicio) Consiste en el
[Operational Level Acuerdo entre la Unidad de TI y otra parte de la misma Organización. El
Agreement] (OLA) OLA contiene la descripción de los Servicios TI que se ofrecen a los
Clientes, e incluye la definición de los bienes y Servicios que se proveen,
así como los compromisos de ambas partes. Por ejemplo, podrá haber un
OLA:
Entre la Unidad de TI y el departamento de Compras, para la obtención de
hardware en plazos previamente comprometidos.
Entre el Centro de Servicio al Usuarios y un Grupo de Soporte para la
realización de la Resolución del Incidente en plazos previamente
acordados..
Ver también Acuerdo de Nivel de Servicio (SLA).

Afinado [Tuning] La Actividad responsable de la Planificación de Cambios para hacer el
más eficiente uso de los Recursos. El Afinado es parte de la Gestión del
Rendimiento, que incluye Monitorización del Rendimiento y la
implementación de los cambios requeridos.
Ajuste a intención [Fit for Un término informal usado para describir un Proceso, Elemento de
Purpose] Configuración, Servicio de TI etc. que es capaz de cumplir sus Objetivos o
Niveles de Servicio. Ser Ajustado a la Intención requiere un Diseño,
implementación, Control y Mantenimiento adecuados.
Alcance [Scope] El límite, o grado, al que un Procedimiento de Proceso, Certificación,

Contrato, etc. se aplica. Por ejemplo, el Alcance de la Gestión de Cambio
puede incluir todos los Servicios TI Vivos y relatar Elementos de
Configuración, el Alcance de un Certificado ISO/IEC 20000 puede incluir
todos los Servicios de TI implementados desde un centro de datos en
cuestión.
Alerta [Alert] (Operación del Servicio) Advertencia de que se ha superado un umbral,
de que algo ha cambiado, o de que hubo un Fallo. De forma regular, las
Alertas se crean y gestionan con herramientas de Gestión de Sistemas y
administradas por el Proceso de Gestión de Eventos.
Alta Disponibilidad [High (Diseño del Servicio) Una alineación o Diseño que minimiza u oculta a
Availability] los Usuarios de un Servicio de TI los efectos del Fallo de un Elemento de
Configuración. Las soluciones de Alta disponibilidad se diseñan para
alcanzar los niveles acordados de disponibilidad y para hacer uso de
técnicas como la Tolerancia a Fallos, Resistencia y recuperación rápida
para reducir el número de Incidentes y el Impacto de los mismos.
Alternativa [Workaround] (Operación del Servicio) Reducción o eliminación del Impacto de un

Incidente o Problema para el que una Resolución completa no está
todavía disponible. Por ejemplo, re arrancando un Elemento de
Configuración fallado. Las Alternativas para Problemas se documentan en
los Registros de Errores Conocidos. Las Alternativas para Incidentes que
no tienen asociados Registros
Amenaza [Threat] Cualquier cosa que pueda aprovechar un Vulnerabilidad. Cualquier causa
potencial de un Incidente puede ser considerada una Amenaza. Por
ejemplo un fuego es una Amenaza que puede aprovechar la
Vulnerabilidad de moquetas inflamables. Este término es comúnmente
usado en la Gestión de la Información de Seguridad y la Gestión de
Continuidad del Servicio de TI, pero también aplica a otras áreas tales
como Gestión de Disponibilidad y Problemas.
Análisis Coste Beneficio Una Actividad que analiza y compara los Costes y los beneficios
[Cost Benefit Analysis] involucrados en uno o más cursos de acción alternativos. Ver Causa de
Negocio (Business Case), Valor Neto Presente, Tasa de Retorno Interna,
Retorno sobre la Inversión, Valor sobre la Inversión.
Análisis Cronológico (Operación del Servicio) Técnica usada para la ayuda en la

[Chronological Analysis] identificación de las posibles causas de los Problemas. Todos los datos
disponibles sobre el Problema se recopilan y clasifican por fecha y hora
para proporcionar una sucesión de hechos detallada. Esto permite
identificar que Eventos pueden haber sido desencadenados por otros.
Análisis de Fallo en el (Diseño del Servicio) Una Actividad que identifica las causas
Servicio [Service Failure subyacentes de una o más interrupciones del Servicio de TI. SFA
Analysis] (SFA) identifica oportunidades y herramientas de mejora tanto de Procesos del
Proveedor de Servicios de TI como de la Infraestructura de TI. SFA es
más una Actividad de tipo projecto limitada en tiempo que un proceso
continuo de análisis. Ver Análisis de la Causa Raíz.

Análisis de Huecos [Gap (Mejora Continua del Servicio) Una Actividad que compara dos
Analysis] conjuntos de datos e identifica las diferencias. El Análisis de huecos se
usa normalmente para contrastar los Requerimientos con las entregas
reales. Ver Comparativa
Análisis de Impacto de Fallos (Diseño del Servicio) Técnica utilizada para ayudar a identificar el
en Componentes impacto que produce un fallo de CI sobre los Servicios de TI. Se elabora a
[Component Failure Impact partir de una matriz que contiene los Servicios de TI en un extremo y los
Analysis] (CFIA)
CIs en el otro. Estos permite la identificación de los CIs críticos (que
podrían causar el fallo de múltiples Servicios de TI) y de los Servicios de
TI poco robustos (que tienen múltiples Puntos Singulares de Fallo).
Amenaza [Threat] Cualquier cosa que pueda aprovechar un Vulnerabilidad. Cualquier causa
potencial de un Incidente puede ser considerada una Amenaza. Por
ejemplo un fuego es una Amenaza que puede aprovechar la
Vulnerabilidad de moquetas inflamables. Este término es comúnmente
usado en la Gestión de la Información de Seguridad y la Gestión de
Continuidad del Servicio de TI, pero también aplica a otras áreas tales
como Gestión de Disponibilidad y Problemas.
Análisis Coste Beneficio Una Actividad que analiza y compara los Costes y los beneficios
[Cost Benefit Analysis] involucrados en uno o más cursos de acción alternativos. Ver Causa de
Negocio (Business Case), Valor Neto Presente, Tasa de Retorno Interna,
Retorno sobre la Inversión, Valor sobre la Inversión.
Análisis Cronológico (Operación del Servicio) Técnica usada para la ayuda en la

[Chronological Analysis] identificación de las posibles causas de los Problemas. Todos los datos
disponibles sobre el Problema se recopilan y clasifican por fecha y hora
para proporcionar una sucesión de hechos detallada. Esto permite
identificar que Eventos pueden haber sido desencadenados por otros.
Análisis de Fallo en el (Diseño del Servicio) Una Actividad que identifica las causas
Servicio [Service Failure subyacentes de una o más interrupciones del Servicio de TI. SFA
Analysis] (SFA) identifica oportunidades y herramientas de mejora tanto de Procesos del
Proveedor de Servicios de TI como de la Infraestructura de TI. SFA es
más una Actividad de tipo projecto limitada en tiempo que un proceso
continuo de análisis. Ver Análisis de la Causa Raíz.
Análisis de Huecos [Gap (Mejora Continua del Servicio) Una Actividad que compara dos
Analysis] conjuntos de datos e identifica las diferencias. El Análisis de huecos se
usa normalmente para contrastar los Requerimientos con las entregas
reales. Ver Comparativa
Análisis de Impacto de Fallos (Diseño del Servicio) Técnica utilizada para ayudar a identificar el
en Componentes impacto que produce un fallo de CI sobre los Servicios de TI. Se elabora a
[Component Failure Impact partir de una matriz que contiene los Servicios de TI en un extremo y los
Analysis] (CFIA)
CIs en el otro. Estos permite la identificación de los CIs críticos (que
podrían causar el fallo de múltiples Servicios de TI) y de los Servicios de
TI poco robustos (que tienen múltiples Puntos Singulares de Fallo).
Análisis de Impacto del (Estrategia del Servicio) BIA es la Actividad de la Gestión de

Negocio [Business Impact Continuidad del Negocio que identifica las Funciones Vitales del Negocio
Analysis] (BIA) y sus dependencias. Estas dependencias pueden incluir Proveedores,
personas, otros Procesos de Negocio, Servicios TI, etc. BIA define los
requerimientos de recuperación para los Servicios TI. Dichos
requerimientos incluyen Objetivos de Tiempos de Recuperación, Objetivos
del Punto de Recuperación y los Objetivos de Nivel de Servicio mínimos
para cada Servicio TI.
Análisis de Kepner & Tregoe (Operación del Servicio) (Mejora Continua del Servicio) Enfoque
[Kepner & Tregoe Analysis] estructurado a la resolución de Problemas. El Problema es analizado en
términos de qué, dónde, cuándo y medida. Se identifican las posibles
causas. Se prueba la causa más probable. Se verifica la causa verdadera.

Análisis de la Causa Raíz (Operación del Servicio) Una Actividad que identifica la Causa Raíz que
[Root Cause Analysis] (RCA) un Incidente o Problema. El RCA se concentra habitualmente en fallos de
la Infraestructura de TI. Ver Análisis de Fallos de Servicio.
Análisis de Tendencias (Mejora Continua del Servicio) El análisis de datos para identificar
[Trend Analysis] patrones en el tiempo. Análisis de Tendencias es usado en Gestión de
Problemas para identificar Fallos comunes o Items de Configuración
frágiles, y en Gestión de la Capacidad como una herramienta de
modelización para predecir el comportamiento futuro. También es usado
como una herramienta de gestión para identificar deficiencias en los
Procesos de Gestión del Servicio de TI.
Análisis de Valor de Daños (Operación del Servicio) Técnica utilizada para ayudar a identificar el
[Pain Value Analysis] Impacto en el Negocio de uno o más Problemas. La fórmula para el
cálculo del Análisis de Valor de Daños se basa en el número de Usuarios
afectados, la duración del Tiempo de Parada, el Impacto para cada
Usuario, y el coste para el Negocio (si es posible calcularlo).
Análisis SWOT [SWOT (Mejora Continua del Servicio) Una técnica que revisa y analiza los
Analysis] puntos fuertes y débiles internos de una Organización y alas
oportunidades externas y amenazas que afronta. SWOT es el acrónimo
de Fuerzas (Strengths), Debilidades( Weaknesses), Oportunidades
(Opportunities) y Amenazas (Threats).
Analítica de Servicio [Service (Estrategia del Servicio) Técnica utilizada en el Gravamen del Impacto
Analytics] de Negocio de los Incidentes. La Analítica de Servicio Modela las
dependencias entre Elementos de Configuración, y las dependencias de
los Servicios de TI en los Elementos de Configuración.
Anatomía del Rendimiento (Estrategia del Servicio) Alineación a la Cultura Organizativa que integra
[Performance Anatomy] y gestiona activamente tanto la estrategia y el liderazgo, como el
desarrollo del personal, la capacitación tecnológica, la gestión del
rendimiento o la innovación.
Aplicación [Application] Programa que provee Funciones requeridas por un Servicio TI. Cada
Aplicación podría ser parte de más de un Servicio TI. Una Aplicación se
puede ejecutar en uno o más Servidores o Clientes. Ver Gestión de
Aplicaciones, Portafolio de Aplicaciones.
Aprovisionamiento Externo Sinónimo de Outsourcing
[External Sourcing]
Aprovisionamiento Interno (Estrategia del Servicio) Uso de un Proveedor Interno de Servicio para
[Internal Sourcing] gestionar los Servios de TI. Ver Aprovisionamiento de Servicio, Proveedor
de Servicio de tipo I, Proveedor de Servicio de tipo II.
Aprovisionamiento Local (Estrategia del Servicio) Provisión de Servicios desde un país cercano al
[Near-Shore] país donde tiene sede el Cliente. Puede tratarse de la provisión de un
Servicio de TI, o de Funciones de soporte como por ejemplo el Centro de
Servicio al Usuario. Ver Aprovisionamiento Cercano, Aprovisionamiento
Lejano.
Árbol de Análisis de Fallos (Diseño del Servicio) (Mejora Continua del Servicio) Una técnica que
[Fault Tree Analysis] (FTA) puede usarse para determinar la cadena de Eventos que lleva a un
Problema. El Árbol de Análisis de Fallos representa la cadena de Eventos
empleando notación Booleana en un diagrama.
Arquitectura [Architecture] (Diseño del Servicio) La estructura de un Sistema o un Servicio TI,
incluyendo las Relaciones de sus Componentes y del ambiente en el que
se encuentran. La Arquitectura también incluye los Estándares y las Guías
que dirigen el diseño y evolución del Sistema.
Arreglo Recíproco (Diseño del Servicio) Es una Opción de Recuperación. Un acuerdo entre
[Reciprocal Arrangement] dos organizaciones para compartir recursos en caso de emergencia. Por
ejemplo, espacio de la Sala de ordenadores o uso de un mainframe

Aseguramiento de la Calidad (Transición del Servicio) Es el Proceso responsable de garantizar que la
[Quality Assurance] (QA) Calidad de un producto, Servicio o Proceso estará al nivel de su Valor
previsto.
Atributo [Attribute] (Transición del Servicio) Una parte de información de un Elemento de
Configuración. Ejemplos: nombre, ubicación, Versión, número y Costo.
Los Atributos de un CIs se registran en la Base de Datos de la
Configuración (CMDB). Ver Relaciones.
Auditoría [Audit] Inspección formal para verificar si un Estándar o un conjunto de Guías se

está siguiendo, que sus Registros son precisos, o que las metas de
Eficiencia y Efectividad se están cumpliendo. Una Auditoría la puede
realizar tanto un grupo interno como uno externo Ver Certificación,
Evaluación.
Back-out [Back-out] Sinónimo de Refuerzo
Base de Conocimiento (Transición del Servicio) Base de datos lógica que contiene los datos
[Knowledge Base] empleados por el Sistema de Gestión del Conocimiento del Servicio.
Base Datos de Errores (Operación del Servicio) Base de datos que contiene todos los Registros
Conocidos [Known Error de Errores Conocidos. Esta base de datos es creada por la Gestión de
Database](KEDB)
Problemas y utilizada por Gestión de Incidencias y Gestión de Problemas.
La Base de Datos de Errores Conocidos es parte del Sistema de Gestión
del Conocimiento del Servicio.
Base de Datos de Gestión de (Transición del Servicio) Base de Datos usada para almacenar
Configuración [Configuration Registros de Configuración durante todo su Ciclo de Vida. El Sistema de
Management Database] Gestión de Configuración mantiene una o más CMDBs, y cada CMDB
(CMDB)
contiene Atributos de CIs, y Relaciones con otros CIs.
Base de datos de (Diseño del Servicio) Base de datos o Documento estructurado usado
proveedores y contratos para gestionar los Contratos con los Proveedores durante su ciclo de vida.
[Supplier and Contract La SCMIS contiene los Atributos clave de todos los Contratos y
Database] (SCMIS)
Proveedores, y debe formar parte del Sistema de Gestión del Servicio de
Conocimiento.
Biblioteca Definitiva de (Transición del Servicio) Uno o más lugares donde se almacenan con
Medios [Definitive Media seguridad las versiones definitivas aprobadas de Elementos de
Library] (DML) Configuración de Software. La DML también puede contener CIs asociado
tales como licencias y documentación. La DML es un área de
almacenamiento lógico única cuando haya múltiples localizaciones. Todo
el software en la DML está bajo el control de Cambios y Gestión de
Entrega y es registrada en el Sistema de Gestión de Configuración.
Solamente el software que está en la DML es aceptable para utilizar en
una nueva Entrega.
British Standards Institution Organización de Estándares Nacionales del Reino Unido. Es responsable
[British Standards de crear y mantener los Estándares británicos. Vaya a http://www.bsi-
Institution] (BSI) global.com para mayor información. Ver ISO.
Bucle de Control de la (Operación del Servicio) Monitorización de la salida de una Tarea,

Monitorización [Monitor Proceso, Servicio de TI o Elemento de Configuración; comparando dicha
Control Loop] salida con un patrón predefinido; y tomando las acciones apropiadas en
base a esta comparación.
Buena Práctica [Best Actividades o Procesos que se han usado con éxito por más de una
Practice] Organización. ITIL® es un ejemplo de Buenas Prácticas.
Cadena de (Estrategia del Servicio) Actividades en la Cadena de Valor acometidas
Aprovisionamiento [Supply por Proveedores. Una Cadena de Aprovisionamiento típicamente implica
Chain] a múltiples Proveedores, cada uno de ellos aporta valor al producto o
Servicio.
Cadena de Valor [Value (Estrategia del Servicio) Una secuencia de Procesos que crea un
Chain] producto o Servicio que proporciona valor a un Cliente. Cada paso de la
secuencia se apoya en los pasos anteriores y contribuye al conjunto del
producto o Servicio. Ver Red de Valor.

Calendario de Cambios (Transición del Servicio) Documento que enumera todos los Cambios
[Change Schedule] aprobados y su fecha prevista de implementación. Un Calendario de
Cambios también se conoce también como Lista de Cambios
Planificados, incluso puede contener información sobre Cambios que ya
han sido implementados.
Calidad [Quality] Característica de un producto, Servicio o Proceso para proporcionar su
propio valor. Por ejemplo, un Componente hardware puede ser
considerado de alta Calidad si rinde según lo esperado y proporciona la
Fiabilidad requerida. La Calidad de un Proceso requiere la capacidad para
medir su Eficacia y Eficiencia, o incluso para mejorarlas si resultase
necesario. Ver también Sistema de Gestión de Calidad.
Cambio [Change] (Transición del Servicio) 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.
Cambio de Emergencia (Transición del Servicio) Un Cambio que debe ser introducido lo más
[Emergency Change] rápido posible. Por ejemplo para resolver un Incidente Mayor o
implementar un parche de Seguridad. La Gestión de Cambios
normalmente tiene un Procedimiento específico para manejar Cambios de
Emergencia. Ver Comité de Emergencia (ECAB).
Cambio Estándar [Standard (Transición del Servicio) Un cambio pre-aprobado que es de bajo
Change] Riesgo, relativamente común y sigue un Procedimiento o Instrucción de
Trabajo. Por ejemplo reset de claves de acceso o provisión de
equipamiento estándar para un nuevo empleado. No se necesitan RFCs
para implementar Cambios Estándar y son registrados y seguidos
empleando otros mecanismos como Peticiones de Servicio. Ver Modelo
de Cambio.
Canal de Entrada de (Estrategia del Servicio) Una base de datos o Documento estructurado
Servicios [Service Pipeline] enumerando todos los Servicios de TI que se están evaluando o en
Desarrollo, pero que todavía no están disponibles para los Clientes. El
Canal de Entrada de Servicios proporciona una perspectiva de Negocio
de los posibles futuros Servicios de TI y es parte de la Cartera de
Servicios, que normalmente no se publica a los Clientes.
Capacidad [Capacity] (Diseño del Servicio) Rendimiento máximo que se puede obtener de un
Elemento de Configuración o Servicio de TI en el cumplimiento de los
Objetivos de Nivel de Servicio acordados. Para algunos tipos de CI, la
Capacidad puede ser el tamaño o el volumen, por ejemplo en una unidad
de disco.
Capitalización (Estrategia del Servicio) Identificación de un Coste como de capital, aún
[Capitalization] no habiendo adquirido ningún Activo. Esto se hace con el objeto de
dispersar el impacto de un Coste a través de múltiples periodos contables.
El ejemplo más común de ello es el desarrollo de software, o la compra de
una licencia de software.
Carga de Trabajo [Workload] Los Recursos requeridos para entregar una parte identificable de un
Servicio de TI. Las Cargas de Trabajo pueden Categorizarse por
Usuarios, grupos de Usuarios, o Funciones dentro de un Servicio de TI.
Es usado para ayudar en el análisis y Gestión de Capacidad, Rendimiento
y Uso de Elementos de Configuración y Servicios de TI. El término Carga
de Trabajo se usa a veces como sinónimo de Flujo.
Cargo diferencial [Differential Técnica usada para ayudar a la Gestión de Demanda, cargando montos
Charging] diferentes por la misma Función de Servicio TI en momentos diferentes.
Cartera de Aplicaciones (Diseño del Servicio) Base de Datos o Documento estructurado que se
[Application Portfolio] usa para gestionar las Aplicaciones en su Ciclo de Vida. El Portafolio de
Aplicaciones contiene Atributos que son claves para todas las
Aplicaciones. Algunas veces se implementa el Portafolio de Aplicaciones
como parte del Portafolio de Servicio, o como parte del Sistema de
Gestión de Configuración.

Cartera de Clientes (Estrategia del Servicio) Una base de datos o Documento estructurado
[Customer Portfolio] usado para registrar todos los Clientes –Customers- de un Proveedor de
Servicio TI. La Cartera de Clientes es la visión del Gestor de Relaciones
de Negocio sobre los Clientes que reciben Servicios de un Proveedor de
Servicios TI. Ver Cartera de contratos, Cartera de Servicios.
Cartera de Contratos (Estrategia del Servicio) Una base de datos o Documento estructurado
[Contract Portfolio] de gestión de Contractos o Acuerdos de Servicios entre un Proveedor de
Servicios TI y sus Clientes. Cada Servicio TI provisto a un Cliente debería
tener un Contrato u otro Acuerdo, el cual esté incluido en la Cartera de
Contratos. Ver Cartera de Servicios, Catálogo de Servicios.
Cartera de Servicios [Service (Estrategia del Servicio) Conjunto de todos los Servicios que son
Portfolio] gestionados por un Proveedor de Servicios. La Cartera de Servicios se
emplea para gestionar el Ciclo de Vida completo de todos los Servicios, e
incluye tres Categorías: Canal de Entrada de Servicios (propuestos o en
Desarrollo); Catálogo de Servicios (Reales o disponibles para su
Despliegue); y Servicios Retirados. Ver Gestión de la Cartera de
Servicios, Cartera de Contratos.
Caso de Negocio [Business (Estrategia del Servicio) Justificación para el gasto de un elemento
Case] relevante. Incluye información de Costos, beneficios, opciones,
situaciones, Riesgos, y posibles problemas. Ver Análisis de Beneficio de
Costo.
Caso de Uso [Use Case] (Diseño del Servicio) Una técnica usada para definir la funcionalidad
requerida, Objetivos y para el Diseño de Pruebas. Los Casos de Uso
definen escenarios realistas que describen las interacciones entre
Usuarios y un Servicio de TI u otro Sistema. Ver Caso de Cambio.
Catálogo de Servicios (Diseño del Servicio) Una base de datos o un Documento estructurado
[Service Catalogue] con información sobre todos los Servicios Live TI, incluyendo aquellos
disponibles para la Implementación. El Catálogo de Servicios es la única
parte publicada de la Carpeta de Servicios publicada a Clientes, y se
utiliza para soportar la venta y entrega de los Servicios de TI. El Catálogo
de Servicios incluye puntos de contacto, solicitud y Procesos de petición.
Ver Carpeta de Contrato.
Categoría [Category] Grupo nominal de cosas que tienen algo en común. Las Categorías se
usan para agrupar distintos contenidos. Por ejemplo los Tipos de Coste se
usan para agrupar clases similares de Costes. Las Categorías de
Incidente son usadas para agrupar tipos similares de Incidentes, Los
Tipos de CIs, se usan para agrupar distintas clases de Elementos de
Configuración.
Causa Raíz [Root Cause] (Operación del Servicio) La causa original o subyacente de un Incidente
o Problema.
Centro de Atención al (Operación del Servicio) Un punto de contacto para Usuarios para
Usuario [Help Desk] registrar Incidentes. Un Centro de Atención al Usuario está normalmente
más técnicamente focalizado que un Centro de Servicio al Usuario y no
proporciona un Punto Único de Contacto. El término Centro de Atención al
Usuario es a menudo usado como sinónimo del Centro de Servicio al
Usuario.
Centro de Beneficio [Profit (Estrategia del Servicio) Unidad de Negocio que cobra por los Servicios
Centre] prestados. Un Centro de beneficio puede ser creado con el objetivo de
obtener una rentabilidad económica, recuperación de Costes, o de
funcionar con pérdidas. Los Proveedores de Servicio de TI pueden
funcionar como Centros de Coste o de Beneficios.
Centro de Costes [Cost (Estrategia del Servicio) Una Unidad de Negocio o Proyecto al cual los
Centre] Costes son asignados. Un Centro de Costes no es un cargo para un
Servicio provisto. Un Proveedor de Servicios TI puede ser considerado
como un Centro de Coste o un Centro de Beneficio.

Centro de Llamadas [Call (Operación del Servicio) Organización o Unidad de Negocio que maneja
Centre] gran cantidad de llamadlas telefónicas entrantes y salientes. Ver Centro
de Servicio al Usuario.
Centro de Servicio al Usuario (Operación del Servicio) Punto Único de Contacto entre el Proveedor de
[Service Desk] Servicio y los Usuarios. Un Centro de Servicio al Usuario típico gestiona
Incidentes, Peticiones de Servicio, y también maneja la comunicación con
los Usuarios.
Cerrado [Closed] (Operación del Servicio) Estado final en el Ciclo de Vida de un Incidente,
Problema, Cambio etc. Cuando el Estado es Cerrado, no se requiere
ninguna acción adicional.
Certificación [Certification] Emisión de un certificado que acredita la Conformidad con un Estándar.
La Certificación incluye una Auditoría formal realizada por un organismo
independiente y Acreditado. El término Certificación también se usa para
denotar la concesión de un certificado que acredita que una persona ha
logrado una cualificación determinada.
Ciclo de Vida [Lifecycle] Las diversas fases en la vida de un Servicio de TI, Elemento de
Configuración, Incidente, Problema, Cambio etc. El Ciclo de Vida define
las Categorías de cada Estado y las transiciones de Estado permitidas.
Por ejemplo:
El Ciclo de Vida de una Aplicación incluye Requisitos, Diseñar, Construir,
Desplegar, Operar, Optimizar.
El Ciclo de Vida Expandido del Incidente incluye Detectar, Responder,
Diagnosticar, Reparar, Recuperar, Restaurar.
El Ciclo de Vida de un Servidor puede incluir: Pedido, Recibido, En
Prueba, Real, Eliminado etc.
Ciclo de Vida de Gestión del Alineación a la Gestión del Servicio de TI que pone énfasis la importancia
Servicio [Service de la coordinación y el Control a través de las diferentes Funciones,
Management Lifecycle] Procesos y Sistemas necesarios para gestionar el Ciclo de Vida total de
los Servicios de TI. La alineación del Ciclo de Vida de la Gestión del
Servicio incluye la Estrategia, Diseño, Transición, Operación y Mejora
Continua de los Servicios de TI.
Ciclo de Vida Expandido del (Gestión de Disponibilidad) Fases detalladas en el Ciclo de Vida de un
Incidente [Expanded Incident Incidente. Las fases son Detección, Diagnóstico, Reparación,
Lifecycle] Recuperación y Restauración. El Ciclo de Vida Expandido del Incidente se
usa para ayudar a la comprensión de las diferentes contribuciones al
Impacto de Incidentes y para Planear como controlarlas y reducirlas.
Ciclo Deming [Deming Cycle] Sinónimo de PDCA (Plan Do Check Act).
Cierre [Closure] (Operación del Servicio) Acción de cambiar el Estado de un Incidente,

Problema, Cambio etc. a Cerrado.
Clasificación [Classification] Acción de asignar una Categoría a algo. La Clasificación se usa con el
objeto de asegurar la calidad de la información y una gestión consistente.
Típicamente se Clasifican CIs, Incidentes, Problemas, Cambios etc.
Cliente [Client] Término genérico que describe al Negocio o Cliente de Negocio. Por
ejemplo Gestor de Clientes podría ser usado como sinónimo de Gerente
de Cuenta. El término cliente también se usa para definir:
Un ordenador usado directamente por un Usuario, como por ejemplo un
PC, un portátil, o una Estación de Trabajo
Parte de una Aplicación Cliente-Servidor que interactúa directamente con
el Usuario. Por ejemplo un cliente de correo electrónico.
Cliente [Customer] Alguien que compra bienes o Servicios. El Cliente de un Proveedor de
Servicios TI es la persona o grupo que define y acuerda el Objetivo de
Nivel de Servicio. El término Cliente –customer- es también informalmente
usado para Usuario, por ejemplo: "Esta es una Organización focalizada en
el Usuario".

Cliente del Negocio (Estrategia del Servicio) El receptor de un producto o Servicio del
[Business Customer] Negocio. Por ejemplo, si el Negocio es un fabricante de coches, entonces
el Cliente del Negocio es quien compra un coche.
Cliente Externo [External Un Cliente que trabaja para un Negocio diferente al del Proveedor del
Customer] Servicio de TI. Ver Proveedor Externo de Servicio, Cliente Interno.
Cliente interno [Internal Cliente que trabaja para el mismo Negocio que el Proveedor del Servicio
Customer] de TI. Ver Proveedor Interno de Servicio, Cliente Externo.
COBIT [COBIT] (Mejora Continua del Servicio) Control Objetivos for Information and
related Technology (COBIT) proporciona las directrices y Mejores
Prácticas para la gestión de los Procesos de TI. La publicación de COBIT
la lleva a cabo el TI Governance Institute. Consultar http://www.isaca.org/
para más información.
Cobro por Noción [Notional (Estrategia del Servicio) Enfoque de la Imputación de Costes para
Charging] Servicios de TI. Se calculan los Cobros a los Clientes y se informa a los
Clientes sobre dichos cobros, pero no se realiza ninguna transferencia de
dinero. El Cobro por Noción se presenta a veces para asegurarse de que
los Clientes son conscientes de los Costes en los que incurren, o como
una fase durante la presentación de la Imputación de Costes verdadera.
Código de Práctica [Code of Directriz publicada por un organismo público o una Organización de
Practice] Normalización, tales como ISO o BSI. Muchos Estándares consisten en
un Código de Práctica y una Especificación. El Código de Práctica
describe las Mejores Prácticas recomendadas.
Comité de Cambios [Change (Transición del Servicio) Personal que asesora al Gerente de Cambios
Advisory Board] (CAB) en la Valoración, priorización y planificación de los Cambios. Este comité
está formado por representantes de todas las áreas del Proveedor de
Servicios de TI, del Negocio, y Proveedores Externos.
Commercial off the Shelf (Diseño del Servicio) Aplicación software o Middleware que puede ser
[Commercial off the Shelf] adquirida por un Proveedor Externo.
(COTS)
Comparativa [Benchmarking] (Mejora Continua del Servicio) Comparar una Referencia con una Línea
de Referencia o con una Buena Práctica. El término Comparativa también
se usa para referirse a la creación de una serie de Referencias en el
tiempo, y comparar los resultados para medir el progreso o la mejora.
Componente [Component] Término genérico usado para definir una parte de algo más complejo. Por
ejemplo, un Sistema de computación puede ser un Componente de un
Servicio de TI, una Aplicación puede ser un Componente de una Unidad
de Entrega. Los Componentes que necesitan ser gestionados son los
Elementos de Configuración.
Componente CI [Component (Transición del Servicio) Elemento de Configuración que forma parte de
CI] una Agrupación. Por ejemplo, un CI de tipo memoria o CPU puede formar
parte de un CI tipo servidor.
Concurrencia [Concurrency] Medida del número de Usuarios dedicados a la misma Operación al
mismo tiempo.
Confiabilidad [Reliability] (Diseño del Servicio) (Mejora del Servicio Continua) Medida de cuánto
tiempo un Elemento de Configuración o Servicio de TI puede ejecutar su
Función acordada ininterrumpidamente. Generalmente medido como
MTBF o MTBSI. El término Confiabilidad también puede ser utilizado para
definir la probabilidad de que un Proceso, Función, etc. responda de la
forma esperada. Ver Disponibilidad.
Confidencialidad (Diseño del Servicio) Principio de seguridad que requiere que los datos
[Confidentiality] deberían únicamente ser accedidos por el personal autorizado a tal
efecto.

Configuración (Transición del Servicio) Término genérico usado para describir un
[Configuration] grupo de Elementos de Configuración que actúan o funcionan juntos para
proveer un Servicio de TI, o un subconjunto representativo de un Servicio
de TI. El término Configuración también se usa para describir los
parámetros y ajustes realizados en uno o más CIs.
Conformidad [Compliance] Aseguramiento de que se sigue un Estándar o conjunto de Directrices, o
de que se emplean unas prácticas de seguimiento adecuadas y
consistentes.
Consejo Asesor de Cambios (Transición del Servicio) Un subconjunto del Consejo Asesor de
de Emergencia [Emergency Cambios que toman decisiones sobre el impacto de Cambios de
Change Advisory Board ] Emergencia. Miembros del ECAB pueden estar decidiendo en el momento
(ECAB)
en que son llamados a reunirse, dependiendo de la naturaleza del Cambio
de Emergencia.
Consejo de Dirección de TI Grupo formal responsable de asegurarse de que el Negocio y las
[TI Steering Group](ISG) Estrategias y Planes del Proveedor de Servicios de TI están
estrechamente alineados. Un Consejo de Dirección de TI incluye
representantes sénior tanto del Negocio como del Proveedor de Servicios
de TI.
Contabilización [Accounting] (Estrategia del Servicio) El Proceso responsable de identificar los
Costos de la entrega de Servicios TI, comparándolos con los costos
presupuestados, y registrando las diferencias con el Presupuesto.
Contabilización de Estado (Transición del Servicio) Actividad responsable de registrar y reportar el
[Estado Accounting] Ciclo de Vida de cada Elemento de Configuración.
Contramedida Puede ser usado para referirse a algún tipo de Control. El término
[Countermeasure] Contramedida es muy usado cuando se refiere a medidas que
incrementan la Resistencia, Tolerancia a fallos o Confiabilidad de un
Servicio TI.
Contratación del Servicio (Estrategia del Servicio) La Estrategia y enfoque para decidir si un
[Service Sourcing] Servicio se provee internamente o si se Externaliza a un Proveedor de
Servicio Externo. Contratación del Servicio significa también la ejecución
de esta Estrategia. La Contratación del Servicio incluye:
Contratación Interna – Servicios Internos o Compartidos empleando
Proveedores de Servicio de Tipo I o de Tipo II.
Contratación Tradicional – Externalización completa del Servicio
empleando un Proveedor de Servicio de Tipo III.
Contratación Multiproveedor – Externalización Preferencial, en Consorcio
o Selectiva, empleando Proveedores de Servicio de Tipo III.
Contrato [Contract] Un Acuerdo legalmente obligatorio entre dos o más partes.
Contrato de Servicio [Service (Estrategia del Servicio) Un Contrato para la entrega de uno o más
Contract] Servicios de TI. El término Contrato de Servicio también se emplea para
significar un Acuerdo para entregar Servicios de TI, tanto si es un
Contrato legal como un SLA. Ver Cartera de Contratos
Contrato de Soporte (Diseño del Servicio) Un Contrato entre un Proveedor de Servicio de TI y
[Underpinning Contract] (UC) un Tercero. El Tercero proporciona bienes o Servicios que soportan la
entrega de un Servicio de TI a Clientes. El Contrato de Soporte define
objetivos y responsabilidades que son requerirlas para alcanzar los
Objetivos de Nivel de Servicio en un SLA.
Control [Control] Un medio de gestión de Riesgo, asegurando que el Objetivo de Negocio
es alcanzado, o asegurando que un Proceso es seguido. Ejemplos de
Controles incluyen Políticas, Procedimientos, Roles, RAID, door-locks etc.
Un control es llamado, algunas veces, Contramedida o medida de
seguridad. Control también es un medio de gestionar el uso o
comportamiento de un Elemento de Configuración, Sistema o Servicio TI.

Control de Configuración (Transición del Servicio) Actividad responsable de asegurar que la
[Configuration Control] adición, modificación o eliminación de un CI se gestiona adecuadamente,
por ejemplo enviando una Petición de Cambio o una Petición de Servicio.
Control de Objetivos para Ver COBIT.

Información y Tecnología
relacionada [Control
Objetivos for Information and
related Technology] (COBIT)
Control de Operaciones Sinónimo de Control de Operaciones de TI.
[Operations Control]
Control de Operaciones de TI (Operación del Servicio) Función responsable de Monitorizar y Controlar

[TI Operations Control] los Servicios de TI y la Infraestructura de TI. Ver Puente de Operaciones.
Control del Proceso [Process Es la Actividad de planificación y regulación de un Proceso, con el

Control] Objetivo de garantizar un desarrollo Eficiente, Efectivo y coherente del
Proceso.
Copia de Seguridad [Backup] (Diseño del Servicio) (Operación del Servicio) Copiar los datos para
proteger los originales de pérdidas de Integridad o Disponibilidad.
Correcciones de dirección Cambios realizados al Plan o Actividad que ya se han iniciado, para
[Course Corrections] asegurarse que el mismo alcance sus Objetivos. Correcciones de
dirección son realizadas como resultado de un progreso en la
Monitorización.
Coste [Cost] El monto de dinero gastado en una Actividad específica, Servicio TI, o
Unidad de Negocio. Los Costes consisten de un coste real (dinero), coste
conceptual, tal como el tiempo de la gente y Amortización.
Coste de Incidencias (Estrategia del Servicio) El Coste de proveer un Servicio de TI que no se

[Indirect Cost] puede asignarse completamente a un Cliente específico. Por ejemplo, el
Coste de proveer Servidores compartidos o licencias de software.
También conocido como Sobrecoste. Ver Coste Directo.
Coste de Oportunidad (Estrategia del Servicio) Se trata de un Coste utilizado a la hora de

[Opportunity Cost] decidir entre alternativas de inversión. Se calcula como el ingreso que se
pudiera haber generado en el caso de que los Recursos disponibles se
hubieran utilizado en una forma diferente. Por ejemplo, el Coste de
Oportunidad en la compra de un nuevo servidor puede considerarse
calculando que la inversión pudiera haberse dedicado a una Mejora del
Servicio. El análisis de Coste de Oportunidad se utiliza como parte del
proceso de toma de decisiones, pero no se emplea como parte del
análisis financiero.
Coste Directo [Direct Cost] (Estrategia del Servicio) Coste de proveer un Servicio TI el cual puede
ser asignado completo a un específico Cliente, Centro de Costes,
Proyecto, etc. Por ejemplo, costes de proveer Servidores no compartidos
o licencias de software. Ver Costes Indirectos.
Coste Fijo [Fixed Cost] (Estrategia del Servicio) Un Coste que no varía con el uso del Servicio
de TI. Por ejemplo el coste de un Servidor. Ver Coste Variable.
Coste Marginal [Marginal (Estrategia del Servicio) Coste de continuar proporcionando el Servicio
Cost] de TI. El Coste Marginal no incluye las inversiones ya realizadas, por
ejemplo el coste de desarrollar nuevo software y dar formación.
Coste Operacional Es el Coste de la ejecución de los Servicios de TI. Frecuentemente se

[Operational Cost] (OPEX) trata de pagos. Por ejemplo, los costes de personal, el mantenimiento de
hardware o el consumo eléctrico. Ver también Costes de Adquisición
(Capex)

Coste Total de Propiedad (Estrategia del Servicio) Una metodología empleada para ayudar a las
[Total Cost of Ownership] decisiones de inversión. TCO establece el Coste total de propiedad de un
(TCO) Elemento de Configuración a lo largo de su Ciclo de Vida, no sólo el Coste
inicial o precio de compra. Ver Coste Total de Utilización.
Coste Total de Uso [Total (Estrategia del Servicio) Una metodología empleada para ayudar a las
Cost of Utilization] (TCU) decisiones de Inversión y Provisión de Servicio. TCU establece el Coste
total para el Cliente del uso de un Servicio de TI a lo largo de todo su
Ciclo de Vida.
Coste Unitario [Unit Cost] (Estrategia del Servicio) El Coste para el Proveedor del Servicio de TI de
proporcionar un único Componente de un Servicio de TI. Por ejemplo el
Coste de un PC, o una única Transacción.
Coste Variable [Variable (Estrategia del Servicio) Un Coste que depende en el uso del Servicio
Cost] de TI, cuantos productos se producen, el número y tipo de Usuarios, o
algún otro parámetro que no puede fijarse por anticipado. Ver Dinámica
de Coste Variable.
Costes de Ejecución Sinónimo de Costes de Operación.

[Running Costs]
CRAMM Metodología y herramienta para analizar y gestionar Riesgos. CRAMM fue
desarrollado por el Gobierno Británico, pero es ahora propiedad privada.
Información adicional disponible en http://www.cramm.com/
Creación [Build] (Transición del Servicio) Actividad en la que se ensambla un número de

Elementos de Configuración para crear una parte de un Servicio TI. El
término también hace referencia a un Entregable que está autorizado para
su Entrega. Por ejemplo, Creación de un Servidor. Ver Línea de
Referencia de la Configuración.
Criterio de Aceptación de (Transición del Servicio) Conjunto de criterios utilizados para asegurar
Servicio [Service Acceptance que un Servicio de TI cumple con su funcionalidad y Requisitos de
Criteria] (SAC) Calidad, y que el Proveedor de Servicio de TI está preparado para Operar
el nuevo Servicio de TI una vez ha sido Implementado. Ver Aceptación.
Cuadro Integral de Mando (Mejora Continua del Servicio) Herramienta de gestión desarrollada por
[Balanced Scorecard] los Doctores Robert Kaplan (Harvard Business School) y David Norton.
Un Cuadro Integral de Mando permite dividir la Estrategia en Indicadores
Clave de Rendimiento (KPI). El Rendimiento frente a los KPIs se usa para
demostrar lo bien que se ha alcanzado la Estrategia. El Cuadro Integral de
Mando tiene 4 áreas, cada una tiene un número pequeño de KPIs. Las
mismas 4 áreas se consideran en diferentes niveles de detalle en la
Organización.
Cualificación [Qualification] (Transición del Servicio) Actividad que garantiza que la Infraestructura
TI es la apropiada y se encuentra configurada correctamente, para
albergar una Aplicación o Servicio de TI. Ver también Validación.
Cultura [Culture] Un conjunto de valores que es compartido por un grupo de personas,

incluyendo expectativas acerca de cómo la gente debería comportarse,
sus creencias, ideas y prácticas. Ver Visión.
Cultura de Servicio [Service Cultura orientada al Cliente. Los Objetivos principales de una Cultura de
Culture] Servicio es la satisfacción del Cliente y la ayuda al Cliente a conseguir sus
Objetivos de Negocio.
Cumplimiento [Fulfilment] Realizar Actividades para cumplir una necesidad o Requerimiento. Por
ejemplo proporcionar un nuevo Servicio de TI, o cumplir una Solicitud de
Servicio.
Cumplimiento de Petición (Operación del Servicio) El Proceso responsable de administrar el Ciclo
[Request Fulfilment] de Vida de todas las Peticiones de Servicio.

Datos-a-Información-a- Una forma de entender las relaciones entre, datos, información,
Conocimiento-a-Sabiduría conocimiento y sabiduría. DIKW muestra cómo cada uno de éstos se
[Data-to-Information-to- construye sobre el otro.
Knowledge-to-
Wisdom](DIKW)
Declaración de Misión La Declaración de Misión de una Organización es una descripción breve
[Mission Statement] pero completa del propósito global y las intenciones de dicha
Organización. Establece lo que ha de conseguirse, pero no cómo debería
hacerse.
Declaración de (Diseño del Servicio) Documento que contiene todos los Requerimientos
requerimientos [Statement of para la compra de un producto o para un Servicio de TI nuevo o
requirements] (SOR) cambiado.
Dependencia [Dependency] La resistencia directa o indirecta de un Proceso o Actividad sobre otro
Depreciación (Amortización) (Estrategia del Servicio) Medida de la reducción de valor de un Activo

[Depreciation] sobre su vida útil. Está basado en el uso, consumo u otra reducción en el
valor económico de utilización.
Derechos [Rights] (Operación del Servicio) Los permisos concedidos a un Usuario o Rol.
Por ejemplo, el Derecho a modificar una información en concreto, o a
autorizar un Cambio.
Desarrollo [Development] [(Diseño del Servicio) Proceso responsable de crear o modificar un
Servicio TI o Aplicación. También usado para referirse al Rol o grupo a
cargo del trabajo de Desarrollo.
Descripción del Puesto de Documento que define los Roles, responsabilidades, aptitudes y
Trabajo [Job Description] conocimiento requeridos por una persona en particular. Una Descripción
del Puesto de Trabajo puede incluir múltiples Roles, por ejemplo los Roles
de Gestor de la Configuración y Gestor del Cambio pueden ser
desempeñados por una sola persona.
Despliegue [Deployment] (Transición del Servicio) La Actividad responsable del movimiento de
hardware, software, documentación, Procesos, etc nuevos o cambiados,
en un Ambiente en Producción. Despliegue es parte del Proceso de
Gestión de Entrega y Desarrollo. Ver Rollout.
Despliegue [Rollout] (Transición del Servicio) Sinónimo de implementación. La mayoría de
las veces se refiere a Implementaciones complejas o divididos en fases, o
a Implementaciones en múltiples ubicaciones.
Detección [Detection] (Operación del Servicio) Etapa en el Ciclo de vida del Incidente. La
detección de resultados en los Incidentes llevan a conocer al Proveedor
de Servicios. La detección puede ser automática, o puede ser resultado
de un Incidente comunicado por un Usuario.
Diagnóstico [Diagnosis] ([Operación del Servicio) Una etapa en Ciclo de vida de Incidentes y
Problemas. El propósito de Diagnóstico es identificar un Alternativa
(solución temporal) para un Incidente o la Causa Raíz de un Problema.
Diagrama de Espina de Pez Sinónimo de Diagrama de Ishikawa.

[Fishbone Diagram]
Diagrama de Ishikawa (Operación del Servicio) (Mejora Continua del Servicio) Una técnica
[Ishikawa Diagram] que ayuda a un equipo a identificar las posibles causas de un Problema.
Originalmente diseñada por Kaoru Ishikawa, el resultado de está técnica
es un diagrama parecido a la espina de un pez.
Dimensionamiento de las (Diseño del Servicio) Actividad responsable de entender los
Aplicaciones [Application Requerimientos de Recursos necesarios para apoyar una nueva
Sizing] Aplicación, o un Cambio mayor de una Aplicación existente. El
dimensionado de las Aplicaciones ayuda a asegurar que los Servicios TI
cumplen con los Objetivos de Nivel de Servicio acordados para la
Capacidad y el Rendimiento.
Dinámica de Coste Variable (Estrategia del Servicio) Una técnica usada para entender como son
[Variable Cost Dynamics] impactados los Costes totales por muchos elementos variables complejos
que contribuyen a la provisión del Servicio de TI.

Dirección de TI [TI (Mejora Continua del Servicio) Gestión Senior dentro de un Proveedor
Directorate] de Servicio, encargado del desarrollo y la provisión de Servicios de TI.
Comúnmente usado en los departamentos del Gobierno de UK.
Diseño [Design] (Diseño del Servicio) Actividad o Proceso que identifica Requerimientos
y entonces define una solución que es capaz de alcanzar dichos
Requerimientos. Ver Diseño del Servicio.
Diseño del Servicio [Service (Diseño del Servicio) Una fase en el Ciclo de Vida de un Servicio de TI.
Design] El Diseño del Servicio incluye varios Procesos y Funciones y es el título
de una de las publicaciones principales de ITIL® Ver Diseño.
Disponibilidad [Availability] (Diseño del Servicio) Habilidad de un Elemento de Configuración o de un

Servicio TI para realizar las Funciones acordadas cuando se requiere. La
Disponibilidad la determinan la Certeza, Mantenibilidad, Servicio,
Rendimiento, y Seguridad. Normalmente la Disponibilidad se calcula en
porcentajes. Éste cálculo se basa normalmente en el Tiempo Acordado
para el Servicio y el Tiempo de Parada. Es una Buena Práctica calcular la
Disponibilidad usando métricas de las salidas del Negocio respecto del
Servicio TI.
Disponibilidad Continua (Diseño del Servicio) un acercamiento o diseño para alcanzar el 100%
[Continuous Availability] de Disponibilidad. Un Servicio TI continuamente disponible no tiene Caída
de Servicio (Downtime) planeado ni No planeado.
Distribución Automática de (Operación del Servicio) El uso de la Tecnología de la Información para
Llamadas [Automatic Call redirigir una llamada telefónica entrante hacia la persona más adecuada
Distribution] (ACD) en el menor tiempo posible. Algunas veces se le llama Distribución
Automatizada de Llamadas.
Documento [Document] Información en forma legible. Un Documento puede ser en papel o

electrónico. Por ejemplo un establecimiento de Política, Acuerdo de Nivel
de Servicio, Registro de Incidentes, plano del diagrama de una sala de
ordenadores. Ver Registro.
Driver [Driver] Algo que influye en la Estrategia, Objetivos o Requerimientos. Por ejemplo
nueva legislación o las acciones de competidores.
Dueño del Proceso [Process Es el Rol responsable de asegurar que un Proceso Coincide con su
Owner] Propósito. Las responsabilidades del Dueño del Proceso cubren el
patrocinio, Diseño, Gestión de Cambios y mejor continua del Proceso y
sus Métricas. Este Rol se asigna comúnmente a la persona que
desempeña también el Rol de Gestor del Proceso, aunque en grandes
Organizaciones, ambos Roles pueden estar separados.
Economías de Alcance (Estrategia del Servicio) La reducción en Coste que es asignada a un
[Economies of scope] Servicio TI usando un Activo existente para un propósito adicional. Por
ejemplo: entregar un Nuevo Servicio TI con una Infraestructura TI
existente. Ver Economías de escala.
Economías de escala (Estrategia del Servicio) La reducción en Coste promedio que es posible
[Economies of scale] incrementando la utilización de un Servicio TI o un Activo. Ver Economías
de Alcance.
Efectividad [Effectiveness] (Mejora Continua del Servicio) Una medida de si los Objetivos de un
Proceso, Servicio o Actividad han sido alcanzados. Un Efectivo Proceso o
Actividad es uno que alcanza sus Objetivos acordados. Ver KPI.
Efectividad de Costes [Cost Una medida de balance entre la Efectividad y el Coste de un Servicio,
Effectiveness] Proceso o actividad, Un Proceso de Coste Efectivo es uno que alcanza su
Objetivo al mínimo Coste. Ver KPI, Retorno sobre la Inversión, Valor por
Dinero.
Eficiencia [Efficiency] (Mejora Continua del Servicio) Una medida de si el correcto monto de
recursos ha sido utilizado para la provisión de un Proceso, Servicio o
Actividad. Un Eficiente Proceso alcanza sus Objetivos con el mínimo de
cantidad de tiempo, dinero, gente u otros recursos. Ver KPI.

Elemento de Capital [Capital (Estrategia del Servicio) Activo que resulta de interés para Gestión
Item] Financiera por estar por encima de un valor financiero acordado.
Elemento de Configuración (Transición del Servicio) Cualquier Componente que necesite ser
[Configuration Item] (CI) gestionado con el objeto de proveer un Servicio de TI. La información
sobre cada CI se almacena en un Registro de Configuración dentro del
Sistema de Gestión de Configuración y es mantenido durante todo su
Ciclo de Vida por Gestión de Configuración. Los CIs están bajo el control
de Gestión de Cambios. Típicamente, los CIs pueden ser Servicios de TI,
hardware, software, edificios, personal, y documentación formal como por
ejemplo documentación sobre Procesos y SLAs.
Elemento de Coste [Cost (Estrategia del Servicio) la categoría de nivel medio por la cual los
Element] Costes son asignados al Presupuesto y la Contabilidad. La categoría de
más alto nivel es el Tipo de Coste. Por ejemplo el Tipo de Coste
“Recursos Humanos” podría tener como elementos del coste a nóminas,
beneficios sociales, viáticos, formación, horas extras, etc. Elementos de
Coste adicionales se descomponen en Unidades de Coste. Por ejemplo el
Elemento de Coste “Gastos generales” podría incluir Costes Unitarios de
Hoteles, Transportes, Comidas, etc.
Empaquetado [Off the Shelf] Sinónimo de Producto Software Empaquetado.
Ensamblaje [Assembly] (Transición del Servicio) Un Elemento de Configuración hecho con otros
CIs. Por ejemplo un Servidor CI puede contener CIs para el CPUs,
Discos, Memoria, etc.; un Servicio TI CI puede contener distinto
Hardware, Software y otros CIs. Ver Componente CI, Creación.
Entorno [Environment] ([ Servicio) un subconjunto de Infraestructura TI que es utilizada para un

propósito particular. Por ejemplo: Entorno de Producción, Entorno de
Prueba, Entorno de Desarrollo. Es posible para múltiples Entornos
compartir Elementos de Configuración, por ejemplo Pruebas y Entornos
de Producción pueden usar diferentes particiones en un único ordenador
mainframe. También utilizado como un término de entorno físico para
definir instalaciones, aire acondicionado, sistema eléctrico, etc. Entorno
también es usado como término genérico para definir condiciones
externas que influyen o afectan algo.
Entorno de Creación [Build (Transición del Servicio) Entorno controlado donde se ensamblan las
Environment] Aplicaciones, los Servicios TI y otras Creaciones antes de enviarse a
Prueba o al Ambiente de Producción.
Entorno de Desarrollo (Diseño del Servicio) Entorno usado para crear o modificar Servicios TI o
[Development Environment] Aplicaciones. Entornos de Desarrollo no son típicamente sujetos al mismo
grado de control como son los Entornos de Pruebas o Entornos de
Producción. Ver Desarrollo.
Entorno de Producción [Live (Transición del Servicio) Entorno controlado que contiene Elementos de
Environment] Configuración Reales empleados para proveer Servicios de TI a los
Clientes.
Entorno de Producción Sinónimo de Entorno Real.
[Production Environment]
Entorno de Prueba [Test (Transición del Servicio) Entorno controlado empleado para probar
Environment] Items de Configuración, Creaciones, Servicios de TI, Procesos etc
Entregable [Deliverable] Algo que debe ser provisto para cumplir un compromiso en un Acuerdo de
Nivel de Servicio o un Contrato. Entregable también es usado en forma
más informal para una salida planeada de cualquier Proceso.
Entregable [Outcome] Es el resultado de la realización de una Actividad, el seguimiento de un

Proceso, la entrega de un Servicio de TI, etc. El término Entregable es
empleado para referirse a los resultados esperados, al igual que a los
resultados reales. Ver también Objetivos.

Error [Errror] (Operación del Servicio) Un defecto o mal funcionamiento que causa
Fallos de uno o más Elementos de Configuración o Servicios TI. Un error
cometido por una persona o un desperfecto en un Proceso que impacta
un CI o un Servicio TI es también un Error.
Error Conocido [Known (Operación del Servicio) Problema que posee una Causa Raíz
Error] documentada y una Solución Temporal. Los Errores Conocidos son
creados y gestionados a través de su Ciclo de Vida por la Gestión de
Problemas. Los Errores Conocidos pueden ser identificados también por
Desarrollo o Suministradores.
Escalabilidad [Scalability] Habilidad de un Servicio de TI, Proceso, Elemento de Configuración, etc.
Para realizar su Función acordada cuando la Carga de Trabajo o el
Alcance cambian.
Escalación Jerárquica (Operación del Servicio) Información a o involucración de niveles de
[Hierarchic Escalation] gestión más elevados para ayudar en un Escalado.
Escalación Funcional (Operación del Servicio) Transferir un Incidente, Problema o Cambio a

[Functional Escalation] un equipo técnico con mayor experiencia para ayudar en un Escalado.
Escalado [Escalation] (Operación del Servicio ) Una Actividad que obtiene Recursos
adicionales cuando son necesarios para alcanzar las metas de Nivel de
Servicio o las expectativas del Cliente. Escalado puede ser necesario
dentro de cualquier Proceso de Gestión de Servicios TI, pero es mucho
más comúnmente asociado con Gestión de Incidentes, Gestión de
Problemas y Gestión de quejas de Clientes. Hay dos tipos de Escalado:
Funcional y Jerárquico.
Escenario del Cambio (Operación del Servicio) Técnica utilizada para predecir el impacto de
[Change Case] los Cambios propuestos. Los Escenarios del Cambio usan escenarios
específicos para clarificar el alcance de los Cambios propuestos y ayudar
en el Análisis Coste-Beneficio. Ver Caso de Uso.
Especificación Definición formal de Requerimientos. Una Especificación puede usarse

[Specification] para definir Requerimientos Técnicos u Operacionales, y puede ser
interna o externa. Muchos Estándares públicos consisten en un Código de
Prácticas y una Especificación. La Especificación define el Estándar frente
al que una Organización puede ser Auditada.
Estado [Estado] Nombre de un campo requerido en muchos tipos de Registros. Muestra la
situación actual de un Elemento de Configuración, Incidente o Problema,
etc en su Ciclo de Vida
Estándar [Standard] Requerimiento obligatorio. Por ejemplo ISO/IEC 20000 (estándar
internacional), una configuración de seguridad interna estándar para Unix,
o un estándar gubernamental acerca de como mantenerlos Registros
financieros. El término estándar también se emplea para definir un Código
de Prácticas o Especificación publicada por una Organización de
Estándares como ISO o BSI. Ver Línea Maestra.
Estimación [Estimation] Uso de la experiencia para proporcionar una valor aproximados para una
Métrica o Coste. La Estimación también se usa en Gestión de la
Capacidad y Disponibilidad como el más económico y menos preciso
método de Modelización.
Estrategia [Strategy] (Estrategia del Servicio) Plan Estratégico diseñado para alcanzar
determinados Objetivos.
Estrategia del Servicio (Estrategia del Servicio) Título de una de los libros Esenciales de ITIL.
[Service Strategy] La Estrategia del Servicio establece una Estrategia conjunta para los
Servicios de TI y para la Gestión de Servicios de TI.
Estratégico [Strategic] (Estrategia del Servicio) El más elevado de los tres niveles de
Planificación y entrega (Estratégico, Táctico y Operacional). Las
Actividades Estratégicas incluyen el establecimiento de Objetivos y la
Planificación a largo plazo para alcanzar la Visión global.

Estructura de Configuración (Transición del Servicio) La jerarquía y demás Relaciones entre todos
[Configuration Structure] los Elementos de Configuración que componen una Configuración.
Etiqueta [Tag] (Estrategia del Servicio) Un código corto empleado para identificar una
Categoría. Por ejemplo etiquetas EC1, EC2, EC3 etc pueden ser usadas
para identificar diferentes respuestas de Clientes cuando se analizan y
comparan Estrategias. El termino Etiquetar se emplea para referir la
actividad de asignar Etiquetas.
Evaluación [Assessment] Inspección y análisis para verificar si un Estándar o un conjunto de Guías
se está siguiendo, que sus Registros son precisos, o que las metas de
Eficiencia y Efectividad se están cumpliendo. Ver Auditoría.
Evaluación [Evaluation] (Transición del Servicio) Proceso responsable de evaluar un Servicio de

TI nuevo o cambiado para asegurar que los Riesgos han sido gestionados
y para ayudar a determinar si proceder con el Cambio. La evaluación es
también usada para comparar el Resultado medio actual con el
pretendido, o comparar una alternativa con otra.
Evento [Event] (Operación del Servicio) Un cambio de estado significativo para la

cuestión de un Elemento de Configuración o un Servicio de TI. El término
Evento también se usa como Alerta o notificación creada por un Servicio
de TI, Elemento de Configuración o herramienta de Monitorización. Los
Eventos requieren normalmente que el personal de Operaciones de TI
tome acciones, y a menudo conllevan el registro de Incidentes.
Facilidad Fija [Fixed Facility] (Diseño del Servicio)Un edificio permanente, disponible para su uso
cuando es necesario para el Plan de Continuidad del Servicio de TI. Ver
Opción de Recuperación, Facilidad Portátil
Factores Críticos de Éxito Algo que debe existir si un Proceso, Proyecto, Plan, o Servicio TI desea
[Critical Success Factor] ser exitoso. KPIs son usados para medir el alcance de cada CSF. Por
(CSF) ejemplo: un CSF de "proteger Servicios TI cuando se hacen Cambios"
podría ser medible por KPIs tales como "porcentaje de reducción de
Cambios no exitosos", o "porcentaje de reducción de Cambios que causen
Incidentes" etc.
Falla [Fault] Sinónimo de Error.
Fallo [Failure] (Operación del Servicio) Pérdida de la habilidad de Operar de acuerdo a
las Especificaciones, o de proporcionar el resultado requerido. El término
Fallo puede usarse cuando nos referimos a Servicios de TI, Procesos,
Actividades, Elementos de Configuración etc. Un Fallo a menudo causa
un Incidente.
Flujo [Throughput] (Diseño del Servicio) Una medida del número de Transacciones, u otras
Operaciones, realizadas en un tiempo fijo. Por ejemplo 5000 correos
electrónicos enviados por horas, o 200 E/S de disco por segundo.
Foro para la Gestión de los El Foro para la Gestión de los Servicios de TI (itSMF) es una
Servicios de TI [TI Service Organización independiente dedicada a promover una alineación
Management Forum ] (itSMF) profesional a la Gestión de los Servicios de TI. itSMF es una Organización
sin ánimo de lucro con representación en gran número de países por todo
el mundo (delegaciones de itSMF). itSMF y sus miembros contribuyen al
desarrollo de ITIL® y de los Estándares de Gestión de Servicio
asociados. Ver http://www.itsmf.com/ para más información.
Foto Fija [Snapshot] (Transición del Servicio) Estado actual de una Configuración recogido
por una herramienta. Empleado también como sinónimo de Comparativa.
Ver Línea de Referencia.
Fuente [Source] Ver Provisión de Servicio.

Función [Function] Un equipo o grupo de personas y las herramientas que usan para llevar a
cabo uno o más Procesos o Actividades. Por ejemplo el Centro de
Servicio al Usuario. El término Función también tiene otros dos
significados
El propósito de un Elemento de Configuración, Persona, Equipo, Proceso
o Servicio de TI. Por ejemplo una Función del Servicio de Correo
Electrónico puede ser almacenar y reenviar correos, una Función de un
Proceso de Negocio puede ser enviar bienes a Clientes.
Realizar su propósito correctamente. “El ordenador funciona”.
Función Vital de Negocio (Diseño del Servicio) Una Función de un Proceso de Negocio que es
[Vital Business Function] critica para el éxito del Negocio. Las Funciones Vitales del Negocio son
(VBF) consideraciones importantes para la Gestión de Continuidad del Negocio,
Gestión de Continuidad del Servicio de TI y Gestión de Disponibilidad.
Ganancia Rápida [Quick Win] (Mejora Continua del Servicio) Actividad de mejora de la que se espera
que proporcione un Retorno de la Inversión en un periodo corto de tiempo
con relativamente poco Coste y esfuerzo. Ver Principio de Pareto.
Garantía [Warranty] (Estrategia del Servicio) Una promesa o garantía que un producto o
Servicio cumplirá los Requerimientos acordados. Ver Validación y Prueba
de Servicio, Garantía de Servicio.
Garantía de Servicio [Service (Estrategia del Servicio) Seguridad de que un Servicio de TI cumplirá los
Warranty] Requerimientos acordados. Puede ser un Acuerdo formal como un SLA o
Contrato, o un mensaje de marketing o imagen de marca. El valor de
Negocio para un Servicio de TI se crea mediante la combinación de la
Utilidad del Servicio (lo que hace el Servicio) y la Garantía del Servicio (lo
bien que lo hace). Ver Garantía.
Gasto de Capital [Capital (Estrategia del Servicio) Coste asociado a la compra de algo que se
Expenditure] (CAPEX) convertirá en un Activo financiero, por ejemplo equipos informáticos o
edificios. El valor de un Activo se Deprecia durante varios periodos
contables.
Gasto Operacional Sinónimo de Coste Operacional
Gestión de Activos [Asset (Transición del Servicio) Proceso responsable de dar seguimiento e
Management] informar el valor la propiedad de los Activos financieros, en todo el Ciclo
de Vida. La Gestión de Activos es parte de Servicios de Activos y de la
Gestión de Configuración. Ver Registro de Activos.
Gestión de Almacenamiento (Operación del Servicio) Proceso responsable de gestionar y mantener
[Storage Management] el almacenamiento de datos a lo largo de su Ciclo de Vida.
Gestión de Aplicaciones (Diseño del Servicio) (Operación del Servicio) Función responsable de
[Application Management] gestionar las Aplicaciones en su Ciclo de Vida.
Gestión de Capacidad (Diseño del Servicio) Proceso responsable de asegurar que la

[Capacity Management] Capacidad de los Servicios de TI y la Infraestructura de TI es capaz de
proveer los Objetivos de Nivel de Servicio en los tiempos y Rentabilidad
acordados. La Gestión de Capacidad tiene en cuenta todos los Recursos
requeridos para proveer el Servicio de TI, y la planificación de los
Requisitos de Negocio a corto, medio y largo plazo.
Gestión de Continuidad de (Diseño del Servicio) Proceso responsable de gestionar los Riesgos que
los Servicios de TI [TI podrían impactar seriamente a los Servicios de TI. ITSCM asegura que el
Service Continuity Proveedor de Servicios de TI puede proporcionar siempre los Niveles de
Management] (ITSCM) Servicio mínimos acordados, reduciendo el Riesgo a un nivel aceptable y
Planificando la Recuperación de los Servicios de TI. ITSCM debería
diseñarse de tal manera que soporte la Gestión de Continuidad del
Negocio.
Gestión de Costes [Cost (Estrategia del Servicio) término general que es usado para referirse al
Management] Presupuesto y la Contabilidad, algunas veces usado como sinónimo de
Gestión Financiera

Gestión de Crisis [Crisis El Proceso responsable para gestionar las implicaciones más amplias de
Management] Continuidad de Negocio. Un equipo de Gestión de Crisis es responsable
de temas Estratégicos tales como gestión de medios y confianza de
accionistas, y decide cuándo invocar los Planes de Continuidad de
Negocio.
Gestión de Demanda Actividades que entienden e influencian la demanda de Servicios de
[Demand Management] Usuarios y la provisión de Capacidad para cumplir con esas demandas.
Una Gestión de Demanda de nivel Estratégico puede incluir un análisis de
Modelos de Actividad de Negocio y Perfiles de Usuarios. Un nivel Táctico
puede incluir el uso de Cargos Diferenciales para alentar a los Usuarios a
utilizar los Servicios TI en horas de baja actividad. Ver Gestión de
Capacidad.
Gestión de Eventos [Event (Operación del Servicio) Proceso responsable de la gestión de Eventos
Management] a lo largo de su Ciclo de Vida. La gestión de Eventos es una de las
principales Actividades de Operaciones de TI.
Gestión de Facilidades (Operación del Servicio) La Función responsable de gestionar el Entorno
[Facilities Management] Físico donde se localiza la Infraestructura de TI. La gestión de Facilidades
incluye todos los aspectos de la gestión del Entorno físico, por ejemplo
electricidad y acondicionamiento, Gestión de Acceso a edificios y
Monitorización medioambiental.
Gestión de Implementación y (Transición del Servicio) Proceso responsable de ambos, Gestión del
Versión [Release and Versión e Implementación.
Deployment Management]
Gestión de Incidencias (Operación del Servicio) Proceso responsable de la gestión del Ciclo de
[Incident Management] vida de todos los Incidentes. El objetivo primario de la Gestión de
Incidencias es recuperar el Servicio de TI para los Usuarios lo antes
posible.
Gestión de la Capacidad de (Diseño del Servicio) (Mejora Continua del Servicio) Proceso
los Componentes responsable de la comprensión de la Capacidad, Utilización, y
[Component Capacity Rendimiento de los Elementos de Configuración. Se recopilan datos, se
Management]
archivan y se analizan para su uso en el Plan de Capacidad. Ver Gestión
de la Capacidad del Servicio.
Gestión de la Capacidad de (Diseño del Servicio) (Mejora Continua del Servicio) La Actividad
Servicio [Service Capacity responsable de comprender el Rendimiento y la Capacidad de los
Management] (SCM) Servicios de TI. Los Recursos usado por cada Servicio de TI y el patrón
de uso con el paso del tiempo son recogidos, registrados y analizados
para ser utilizados en el Plan de Capacidad. Ver Gestión de la Capacidad
de Negocio, Gestión de la Capacidad de Componentes.
Gestión de la Capacidad del (Diseño del Servicio) En el contexto de ITSM, la Gestión de la
Negocio [Business Capacity Capacidad del Negocio es la Actividad responsable de conocer los
Management] (BCM) Requisitos de Negocio futuros para usarlos en el Plan de Capacidad. Ver
Gestión de la Capacidad del Servicio.
Gestión de la Cartera de (Estrategia del Servicio) Proceso responsable de gestionar la Cartera de

Servicios [Service Portfolio Servicios. La Gestión de la Cartera de Servicios considera los Servicios
Management (SPM) en términos del valor de Negocio que proporcionan.
Gestión de Configuración (Transición del Servicio) Proceso responsable de mantener información

[Configuration Management] sobre los Elementos de Configuración requeridos para la provisión de un
Servicio de TI, incluyendo las Relaciones entre ellos. Esta información se
gestiona durante todo el Ciclo de Vida del CI. La Gestión de Configuración
forma parte de un Activo del Servicio global y del Proceso de Gestión de
Configuración.
Gestión de Continuidad de Servicio Sinónimo de TI Service Continuity Management.
[Service Continuity Management]

Gestión de Continuidad del (Diseño del Servicio) Es el Proceso de Negocio responsable de
Negocio [Business gestionar el Riesgo que puede tener un alto impacto en el Negocio. BCM
Continuity Management] protege los intereses de los principales interesados, la reputación, la
(BCM)
marca y las actividades que aportan valor al Negocio. Los Procesos de
BCM incluyen reducir el Riesgo a un nivel aceptable y planificar el
restablecimiento de los Procesos de Negocio ante una situación. BCM
establece los Objetivos, el Ámbito y los Requerimientos para una Gestión
de Continuidad del Servicio.
Gestión de Disponibilidad (Diseño del Servicio) Proceso responsable de definir, analizar, Planificar,
[Availability Management] medir y mejorar todos los aspectos relativos a la Disponibilidad de los
Servicios TI. La Gestión de Disponibilidad tiene la responsabilidad de que
toda la Infraestructura TI, Procesos, Herramientas, Roles etc. estén de
acuerdo con las Metas de Nivel de Servicio para la Disponibilidad.
Gestión de la Relación con el (Estrategia del Servicio) El Proceso o Función responsable por el
Negocio [Business mantenimiento de la Relación con el Negocio. Normalmente incluye:
Relationship Management] Gestionar las Relaciones personales con los directivos del Negocio
Proveer información a la Gestión del Portafolio de Servicios
Asegurarse de que el Proveedor de Servicios TI está satisfaciendo las
necesidades de los Clientes en el Negocio.
Este Proceso está fuertemente relacionado con la Gestión de Niveles de
Servicio.
Gestión de Seguridad de (Diseño del Servicio) Proceso que asegura la Confidencialidad,
Información [Information
Integridad y Disponibilidad de los Activos de una Organización,
Security Management] (ISM)
información, datos y Servicios de TI. La Gestión de Seguridad de la
información forma parte normalmente de la Gestión de Seguridad de la
Organización, la cual tiene un ámbito más amplio que las del Proveedor
de Servicio de TI e incluye accesos a edificios, llamadas de teléfonos, etc
para toda la Organización.
Gestión de los Servicios de (Estrategia del Servicio) (Diseño del Servicio) Alineación a la Gestión
Negocio [Business Service de Servicios de TI que tiene en cuenta los Procesos de Negocio
Management] (BSM) soportados y el valor de Negocio proporcionado. Este término también
hace referencia a la Gestión de Servicios de Negocio proporcionados a
Clientes de Negocio.
Gestión de los Servicios de Implantación y Gestión de Servicios de TI de Calidad que cumplan con las
TI [TI Service Management] necesidades del Negocio. La Gestión de los Servicios de TI es llevada a
(ITSM) cabo por los Proveedores de Servicios de TI a través de la combinación
apropiada de personas, Procesos y Tecnologías de la Información. Ver
Gestión de Servicio.
Gestión de Operaciones Sinónimo de Gestión de Operaciones de TI.
[Operations Management]
Gestión de Operaciones de (Operación del Servicio) Función dentro de un Proveedor de Servicio

TI [TI Operations que se encarga de ejecutar las Actividades diarias necesarias para
Management] gestionar los Servicios de TI y la Infraestructura de TI que los soporta.
Gestión de Operaciones de TI incluye el Control de Operaciones de TI y la
Gestión de las Instalaciones.
Gestión de Problemas (Operación del Servicio) Es el Proceso responsable del la gestión del
[Problem Management] Ciclo de Vida de todos los Problemas. El principal Objetivo de la Gestión
de Problemas es la prevención de Incidentes, al igual que la reducción del
Impacto de aquellos Incidentes que no haya sido posible prevenir.
Gestión de Riesgo [Risk El Proceso responsable por la identificación, determinación y control de

Management] Riesgos. Ver Determinación de Riesgos.

Gestión de Riesgos La metodología OGC para la gestión de Riesgos. MoR incluye todas las
[Management of Risk] (MoR) Actividades necesarias para identificar y Controlar toda exposición al
Riesgo que pueda tener un impacto en la consecución de los Objetivos de
Negocio de la Organización. Ver http://www.m-o-r.org/ para más detalles.
Gestión de Seguridad Sinónimo de Gestión de Seguridad Informática.

[Security Management]
Gestión de Sistemas [System La parte de la Gestión del Servicio de TI que se centra en la gestión de la
Management] Infraestructura de TI en lugar de en los Procesos
Gestión de Versión [Release (Transición del Servicio) Proceso responsable de la Planificación,

Management] Agendado y Control de movimiento de Versiones a Probar y de Entornos
Vivos. El Objetivo primario de la Gestión de Versión es asegurarse de que
la integridad del Entorno de producción esté protegido y que los
Componentes correctos son implementados. La Gestión de Versión es
parte del Proceso de Gestión de Implementación y Versión.
Gestión del Acceso [Access (Operación del Servicio) Proceso responsable de permitir a los Usuarios
Management] hacer uso de los Servicios de TI, datos, u otros Activos. La Gestión de
Acceso ayuda a proteger la Confidencialidad, la Integridad y la
Disponibilidad de los Activos, asegurando que sólo Usuarios autorizados
pueden acceder o modificar los Activos. Algunas veces también es posible
referirse a la Gestión del Acceso como Gestión de Derechos o como
Gestión de la Identidad.
Gestión del (Diseño del Servicio) Proceso responsable de asegurar que todos los
aprovisionamiento [Supplier Contratos y Proveedores soportan las necesidades del Negocio, y que
Management] todos los Proveedores cumplen sus compromisos contractuales.
Gestión de Cambios [Change (Transición del Servicio) Proceso responsable del control del Ciclo de
Management] Vida de los Cambios. El objetivo primario de Gestión de Cambios es
permitir la ejecución de los Cambios a realizar, con la mínima afectación a
los Servicios de TI.
Gestión del Conocimiento (Transición del Servicio) Proceso responsable de recoger, analizar,
[Knowledge Management] almacenar y compartir conocimiento e información dentro de una
Organización. El propósito principal de la Gestión del Conocimiento es
mejorar la Eficiencia reduciendo la necesidad de redescubrir el
conocimiento. Ver Datos para la Información, el Conocimiento y el Saber,
Sistema de Gestión del Conocimiento del Servicio.
Gestión del Nivel de Servicio (Diseño del Servicio) (Mejora Continua del Servicio) Proceso
[Service Level Management] responsable de negociar y asegurar el cumplimiento de los SLAs. SLM es
(SLM) responsable de asegurar que todos los Procesos de Gestión del Servicio
de TI, Acuerdos de Nivel Operacional y Contratos de Soporte son
adecuados a los Objetivos de Nivel de Servicio. SLM monitoriza y reporta
los Niveles de Servicio y mantiene revisiones periódicas con el Cliente.
Gestión del Rendimiento (Mejora Continua del Servicio) Es el Proceso responsable de las
[Performance Management] Actividades del día a día dentro de la Gestión de la Capacidad. Incluye la
Monitorización, detección de Umbrales, análisis de Rendimiento y
Optimización, así como la implementación de Cambios relacionados con
el Rendimiento o la Capacidad.
Gestión del Servicio [Service La Gestión del Servicio es un conjunto de capacidades organizativas
Management] especializadas empleadas para proporcionar valor a los Clientes en forma
de Servicios.
Gestión Financiera [Financial (Estrategia del Servicio) La Función y Procesos responsable de
Management] gestionar los requerimientos de Presupuesto, Contabilidad y Cargos de un
Proveedor de Servicio de TI

Gestión Proactiva de (Operación del Servicio) Parte del Proceso de Gestión de Problemas. El
Problemas [Proactive Objetivo de la Gestión Proactiva de Problemas es la predicción de
Problem Management] Problemas. La Gestión Proactiva de Problemas analiza los Registros de
Incidencias, así como los datos recibidos por otros Procesos de Gestión
de Servicios TI con el propósito de identificar posibles Problemas o
tendencias que puedan causarlos.
Gestión Técnica [Technical (Operación del Servicio) La Función responsable de proporcionar
Management] capacidades técnicas en el soporte de los Servicios de TI y en la gestión
de la infraestructura de TI. La gestión Técnica define los roles de los
Grupos de Soporte, así como las herramientas, Procesos y
Procedimientos requeridos.
Gestión Total de Calidad (Mejora Continua del Servicio) Una metodología para gestionar la
[Total Quality Management] mejora continua mediante el uso del Sistema de Gestión de Calidad. TQM
(TQM) estable una Cultura, involucrando a todo el personal en la Organización
en un Proceso de continua monitorización y mejora.
Gestor de Cuenta [Account (Estrategia del Servicio) Rol muy parecido a Gestor de la Relación con
Manager] el Negocio pero incluye más aspectos comerciales. Se utiliza más cuando
se trabaja con Clientes Externos.
Gestor de la Relación con el (Estrategia del Servicio) El Rol responsable de mantener la Relación con
Negocio [Business uno o más Clientes. Este Rol es a menudo combinado con el de Gestor
Relationship Manager] (BRM) de Nivel de Servicio.
Gestor de Servicio [Service Gestor que es responsable de administrar el Ciclo de Vida de uno o más
Manager] Servicios de TI de principio a fin. El término Gestor de Servicio también se
emplea para referirse a un gestor dentro del Proveedor de Servicios de TI.
Comúnmente empleado para referirse al Gestor de la Relación con el
Negocio, Gestor de Procesos o Gestor de Cuenta o un gestor con
responsabilidad en el conjunto de Servicios de TI.
Gestor del Proceso [Process Es el Rol responsable de la gestión Operativa de un Proceso. Las
Manager] responsabilidades del Gestor del Proceso cubren la Planificación y
coordinación de todas las Actividades necesarias para el desarrollo,
seguimiento y registro de actividad de un Proceso. Pueden existir más de
un Gestor del Proceso para un Proceso determinado, como pueden ser
Gestores de Cambio por regiones geográficas, o Gestores de Continuidad
del Servicio para cada Centro de Proceso de Datos. El Rol de Gestor del
Proceso se asigna comúnmente a la persona que desempeña también el
Rol de Dueño del Proceso aunque en grandes Organizaciones, ambos
Roles pueden estar separados.
Gobierno [Governance] Asegurar que las Políticas y Estrategias se implementan, y que los
Procesos requeridos se siguen correctamente. El Gobierno incluye definir
los Roles y Responsabilidades, medir y reportar, y tomar acciones para
resolver cualquier asunto identificado.
Gráfico SLAM [SLAM Chart] (Mejora Continua del Servicio) Un gráfico de Monitorización del los SLA
empleado para reportar y monitorizar los resultados obtenidos frente a los
Objetivos de Nivel de Servicios. Un gráfico SLAM contiene normalmente
un código de colores para mostrar la medida en que cada uno de los
Objetivos de Nivel de Servicio ha sido alcanzado en cada uno de los 12
meses precedentes.
Gravamen de Riesgo [Risk Los pasos iniciales de la Gestión de Riesgos. Al analizar el valor de los
Assessment] Activos del negocio, identificando Amenazas a esos Activos, y evaluando
cuan Vulnerable cada Activo es a esas Amenazas. El Gravamen de
Riesgo puede ser cuantitativo (basado en información numérica) o
cualitativa.
Grupo de Soporte [Support (Operación del Servicio) Un grupo de personas con capacidades
Group] técnicas. Los grupos de soporte proporcionan el Soporte Técnico
necesitado por todo el Proceso de Gestión del Servicio de TI. Ver Gestión
Técnica.

Guía de Diagnóstico (Operación del Servicio) Un estructurado conjunto de preguntas usada
[Diagnostic Script] por el personal del Centro de Servicios a Usuarios para asegurar que ellos
realizan las preguntas correctas y les ayuda a Clasificar, Resolver y
asignar Incidentes. La Guía de Diagnóstico también puede estar
disponible para los Usuarios para ayudarles a diagnosticar y resolver sus
propios Incidentes.
Habilidad [Capability] (Estrategia del Servicio) Capacidad de una Organización, persona,
Proceso, Aplicación, Elemento de Configuración o Servicio de TI para el
desarrollo de una Actividad. Las Habilidades son Activos intangibles de
una Organización. Ver Recurso.
Hacer Nada [Do Nothing] (Diseño del Servicio) Una Opción de Recuperación. El Proveedor de
Servicios formalmente acuerda con el Cliente que la Recuperación de
este Servicio TI no será realizado.
Historia del Cambio [Change (Transición del Servicio) Información de todos los cambios realizados
History] sobre un Elemento de Configuración durante su ciclo de vida. La Historia
del Cambio consiste en todos aquellos Registros de Cambio que aplican
al CI.
Horas de Servicio [Service (Diseño del Servicio) (Mejora Continúa del Servicio) Periodo de tiempo
Hours] acordado durante el que un determinado Servicio de TI debe estar
Disponible. Por ejemplo, Lunes-Viernes 08:00 a 17:00 exceptuando
festivos. Las Horas de Servicio deben definirse en un Acuerdo de Nivel de
Servicio (SLA).
Horas de Soporte [Support (Diseño del Servicio) (Operación del Servicio) Tiempos u horas cuando
Hours] el soporte está disponible para los Usuarios. Típicamente estas son las
horas en las que el Centro de Servicio al Usuario está disponible. Las
horas de soporte deben ser definidas en el Acuerdo de Nivel de Servicio,
y pueden ser distintas de las Horas de Servicio. Por ejemplo, las Horas de
Servicio pueden ser 24 horas al día, pero las Horas de Soporte pueden
ser de 07:00 a 19:00.
Identidad [Identity] (Operación del Servicio) Un nombre único empleado para identificar a
un Usuario, persona o Rol. La identidad se usa para garantizar Derechos
a ese Usuario, persona o Rol. Ejemplos pueden ser Nombre de Usuario
SmiithJ o el Rol de “Gestor de Cambios”.
Identificación de (Transición del Servicio) Actividad responsable de recopilar información

Configuración [Configuration sobre Elementos de Configuración y sus Relaciones, e introducir esta
Identification] información en la CMDB. La Identificación de Configuración también es
responsable del etiquetado de los CIs, con el objeto de que los
correspondientes Registros de Configuración puedan ser accesibles.
Identificación de Versión (Transición del Servicio) Convención de nomenclatura utilizada para

[Release Identification] identificar una Versión de forma única. La Identificación de la Versión
habitualmente incluye una referencia al Elemento de Configuración y al
número de versión. Por ejemplo, Microsoft Office 2003 SR2.
Impacto [Impact] (Operación del Servicio) (Transición del Servicio) Una medida del
efecto de un Incidente, Problema o Cambio en los Procesos de Negocio.
El Impacto está a menudo basado en como serán afectados los Niveles
de Servicio. El Impacto y la Urgencia se emplean para asignar la
Prioridad.
Imputación de Costes (Estrategia del Servicio) Requerir pago por la provisión de Servicios de
[Charging] TI. La Imputación de Costes para Servicios de TI es opcional, y muchas
Organizaciones optan por tratar a su Proveedor de Servicios de TI como
un Centro de Coste.
Incidente [Incident] (Operación del Servicio) Interrupción no planificada de un Servicio de TI
o reducción en la Calidad de un Servicio de TI. También lo es el Fallo de
un Elemento de Configuración que no ha impactado todavía en el
Servicio. Por ejemplo el Fallo de uno de los discos de un “mirror”.

Incidente Grave [Major (Operación del Servicio) Es la Categoría más alta de Impacto para un
Incident] Incidente. Un Incidente Grave tiene como consecuencia una interrupción
importante en el Negocio.
Indicador Clave de (Mejora Continua del Servicio) Métrica empleada para ayudar a
Rendimiento [Key gestionar un Proceso, Servicio de TI o Actividad. Muchas Métricas pueden
Performance Indicator ] (KPI) medirse, pero sólo las más importantes se definen como KPIs y son
empleadas para gestionar de forma activa e informar sobre los Procesos,
los Servicios de TI o las Actividades. Los KPIs deberían ser seleccionados
de tal forma que aseguren el control de la Eficiencia, la Efectividad, y la
Rentabilidad. Ver Factores Críticos de Éxito.
Información de Gestión Información empleada para soportar la toma de decisiones por los
[Management Information] gerentes. La Información de Gestión a menudo es generada
automáticamente por las herramientas que soportan los diversos
Procesos de Gestión de Servicios de TI. La Información de Gestión suele
incluir los valores de los KPIs como por ejemplo "Porcentaje de Cambios
precedidos por Incidentes", o "tasa de resolución en el primer nivel".
Informe de Excepción Documento que contiene detalles de uno o más KPIs u otros objetivos que
[Exception Report] han sobrepasado sus Umbrales definidos. Por ejemplo objetivos de los
SLAs fallidos a punto de ello, y Métricas de Rendimiento indicando un
problema potencial de Capacidad.
Infraestructura de TI [TI Todo el hardware, software, redes, instalaciones etc. requeridas para
Infrastructure] Desarrollar, Probar, proveer, Monitorizar, Controlar o soportar los
Servicios de TI. El término Infraestructura de TI incluye todas las
Tecnologías de la Información pero no las personas, Procesos y
documentación asociados.
Insourcing [Insourcing] Sinónimo de Aprovisionamiento Interno.
Instalaciones Portátiles (Diseño del Servicio) Edificios prefabricados o vehículos de grandes

[Portable Facility] dimensiones, proporcionados por Terceras Partes y trasladados de sitio
cuando es necesario, como parte de un Plan de Continuidad del Servicio
de TI. Ver también Opciones de Recuperación, Instalaciones Fijas.
Instrucción de Trabajo [Work Un Documento conteniendo instrucciones detalladas que especifican

Instruction] exactamente qué pasos seguir para acometer una Actividad. Una
Instrucción de Trabajo contiene mucho más detalle que un Procedimiento
y sólo se crea cuando se necesitan instrucciones muy detalladas.
Integración de Telefonía e (Operación del Servicio) Término genérico que cubre cualquier tipo de
Informática [Computer integración entre computadoras y Sistemas de Telefonía. Se usa
Telephony Integration] (CTI) típicamente para hacer referencia a Sistemas donde una Aplicación
muestra detalles relacionados con llamadas telefónicas entrantes o
salientes. Ver Distribución Automática de Llamada, Respuesta Interactiva
de Voz.
Integridad [Integrity] (Diseño del Servicio) Un principio de seguridad que certifica que los
datos y Elementos de Configuración sólo son modificados por personal y
Actividades autorizados. La Integridad considera todas las posibles
causas de modificación, incluyendo Fallos software y hardware, Eventos
medioambientales e intervención humana.
Interfaz del Proveedor de (Estrategia del Servicio) Interfaz entre el Proveedor de Servicios TI y un
Servicios [Proveedor de Usuario, Cliente, Proceso de Negocio o Proveedor. El análisis de los
Servicios Interface] (SPI) Interfaces del Proveedor de Servicios ayuda en la coordinación la gestión
extremo a extremo de los Servicios de TI.
Interrupción Prevista del (Transición del Servicio) Documento que identifica el efecto sobre los
Servicio [Projected Service Niveles de Servicio de los Cambios planificados, Actividades de
Outage] (PSO) mantenimiento o los Planes de Pruebas.
Invocación [Invocation] (Diseño del Servicio) Inicio de los pasos definidos en un plan. Por
ejemplo, iniciar el Plan de Continuidad del Servicio de TI para uno o más
Servicios de TI.

ISO 9000 Término genérico que se refiere a un conjunto de Estándares y Directrices
para los Sistemas de Gestión de Calidad. Ver http://www.iso.org/ . Ver
ISO.
ISO 9001 Estándar internacional para los Sistemas de Gestión de Calidad. Ver ISO
9000, Estándar.
ISO/IEC 17799 (Mejora Continua del Servicio) Código de Práctica ISO para la Gestión
de Seguridad de la Información. Ver Estándar.
ISO/IEC 20000 Especificación ISO y Código de Práctica para la Gestión de los Servicios
de TI. ISO/IEC 20000 está alineado con las Mejores Prácticas ITIL.
ISO/IEC 27002 (Diseño del Servicio) (Mejora Continua del Servicio) Especificación
ISO para la Gestión de Seguridad de la Información. El Código de
Práctica correspondiente es ISO/IEC 17799. Ver Estándar.
ITIL ®[ITIL] Conjunto de Mejores Prácticas para la Gestión de Servicios de TI. ITIL®
es propiedad de la OGC y consiste en una serie de publicaciones que
aconsejan sobre la provisión de Servicios de TI de Calidad, y sobre los
Procesos y las instalaciones necesarias para soportarlos. Ver
http://www.itil.co.uk/ para más información.
Límea de Referencia (Mejora Continua del Servicio) Una Referencia que se usa como punto
[Baseline] de marca. Por ejemplo:
Una Límea de Referencia de ITSM se puede usar como punto de partida
para medir el resultado de un Plan de Mejora del Servicio
Una Límea de Referencia de Rendimiento se puede usar para medir
cambios en el Rendimiento de un Servicio TI en un periodo de tiempo.
Una Límea de Referencia de la Gestión de Configuración puede servir
para restablecer la Infraestructura TI en una Configuración conocida en
caso de un fallo de un Cambio o de un Entregable
Línea de Referencia de (Transición del Servicio) Una Línea de Referencia de una Configuración
Configuración [Configuration que ha sido formalmente acordada y se gestiona a través del proceso de
Baseline] Gestión de Cambios. Una Línea de Referencia de Configuración se usa
como base para futuras Construcciones, Entregas y Cambios.
Línea de Servicio [Line of (Estrategia del Servicio) Servicio Esencial o Servicio de Soporte que
Service] (LOS) posee múltiples Paquetes del Nivel de Servicio. Una Línea de Servicio es
gestionada por un Gestor de Producto y cada Paquete del Nivel de
Servicio se designa para soportar un segmento de mercado en particular.
Línea Maestra [Guideline] Un Documento describiendo las Mejores Prácticas, que recomienda qué
debe hacerse. El seguimiento de una Linea Maestra no es normalmente
obligado. Ver Estándar.
Llamada [Call] (Operación del Servicio) Llamada telefónica de un Usuario al Centro de

Servicio al Usuario. Una Llamada puede derivar en el registro de un
Incidente o una Petición de Servicio.
Lluvia de ideas (Diseño del Servicio) Técnica que ayuda a un equipo a generar ideas.
[Brainstorming] Durante una sesión de Lluvia de ideas, las ideas no se revisan, pero sí en
una etapa posterior. La Gestión de Problemas usa con frecuencia la Lluvia
de Ideas para identificar posibles causas.
Madurez [Maturity] (Mejora Continua del Servicio) Medida de la Fiabilidad, Eficiencia y
Efectividad de un Proceso, Función, Organización etc. Los Procesos y
Funciones más maduros están íntimamente alineados a los Objetivos de
Negocio y a la Estrategia, y están soportados por un marco de trabajo
para la mejora continua.

Mantenibilidad (Diseño del Servicio) Medida de cómo de rápida y Efectivamente se
[Maintainability] puede restaurar un Elemento de Configuración o Servicio de TI a su
funcionamiento normal después de un Fallo. La Mantenibilidad se mide y
reporta frecuentemente como MTRS. El término Mantenibilidad se emplea
también en el contexto de Desarrollo de Software o Desarrollo de
Servicios de TI refiriéndose a la capacidad de ser Cambiado o Reparado
fácilmente.
Matriz de Autoridad Sinónimo de RACI.
[Authority Matrix]
Mejora Continua del Servicio (Mejora Continua del Servicio) Una etapa en el Ciclo de vida de un
[Continual Service Servicio TI y el título de una de las publicaciones Medulares ITIL. La
Improvement] (CSI) Mejora Continua del Servicio es responsable para la gestión de mejoras al
Servicio TI y la Gestión de Procesos. El Desempeño de los Proveedores
de Servicios TI es medido continuamente y las mejoras son realizadas en
los Procesos, Servicios TI e Infraestructura TI para incrementar su
Eficiencia y Efectividad, y Efectividad en Costes. Ver Plan-Do-Check-Act.
Mercado [Market Space] (Estrategia del Servicio) Todas las oportunidades que un Proveedor de
Servicios de TI puede explotar para satisfacer las necesidades de negocio
de los Clientes. El Mercado identifica los posibles Servicios de TI de los
que un Proveedor de Servicios de TI podría desear considerar su
prestación.
Métrica [Metric] (Mejora Continua del Servicio) Algo que se mide y reporta para ayudar a
gestionar un Proceso, Servicio de TI o Actividad. Ver KPI.
Métrica Externa [External Métrica usada para medir la entrega de un Servicio de TI a un Cliente. Las
Metric] Métricas Externas son normalmente definidas en los SLAs y reportadas a
los Clientes. Ver Métrica Interna.
Métrica interna [Internal Métrica que es empleada dentro del Proveedor de Servicio de TI para
Metric] monitorizar la Eficacia, Efectividad o Efectividad en Coste de los Procesos
internos de un Proveedor de Servicio de TI. Las Métricas internas no son
normalmente trasladadas al Cliente del Servicio de TI. Ver Métrica
Externa.
Métricas de Tensión [Tension (Mejora Continua del Servicio) Conjunto de Métricas relacionadas, en
Metrics] las cuales mejoras a una métrica tienen un efecto negativo en otra. Las
Métricas de Tensión se diseñan para asegurar que se obtiene el equilibrio
apropiado.
Middleware [Middleware] (Diseño del Servicio) Software que conecta uno o más Componentes o
Aplicaciones software. El Middleware generalmente se adquiere de un
Suministrador, en lugar de desarrollarlo dentro del Proveedor de Servicios
de TI. Ver Empaquetado.
Modelado [Modelling] Técnica que se emplea para predecir el comportamiento futuro de un
Sistema, Proceso, Servicio de TI, Elemento de Configuración etc. El
Modelado suele emplearse en Gestión Financiera, Gestión de Capacidad
y Gestión de Disponibilidad.
Modelado analítico (Estrategia del Servicio) (Diseño del Servicio) (Mejora Continua del
[Analytical Modelling] Servicio) Técnica que utiliza Modelos matemáticos para predecir el
comportamiento de un Elemento de Configuración o Servicio TI. Los
Modelos Analíticos se usan con mayor frecuencia en la Gestión de la
Capacidad y en la Gestión de Disponibilidad. Ver Modelado.
Modelo [Model] Representación de un Sistema, Proceso, Servicio de TI, Elemento de

Configuración etc. empleado para ayudar a entender o predecir
comportamientos futuros.

Modelo de Cambio [Change (Transición del Servicio) Modo repetible de gestionar una Categoría
Model] particular de Cambio. Un Modelo de Cambio enumera los pasos
específicos predefinidos que deberán ser seguidos para un Cambio
perteneciente a esa Categoría. Los Modelos de Cambio deben ser muy
simples, y que no requieran de aprobación (ej. Cambio de contraseña) o
pueden ser muy complejos y que incluyan muchos pasos que requieran
de aprobación (ej. Despliegue de una nueva versión de software). Ver
Cambio Estándar, Comité de Cambios.
Modelo de Capacitación para (Estrategia del Servicio) un marco de referencia para ayudar a
clientes [eSourcing Organizaciones en sus análisis y decisiones sobre Service Sourcing
Capability Model for Client Models and Strategies. eSCM-CL fue desarrollado por Carnegie Mellon
Organizations] (eSCM-CL)
University. Ver eSCM-SP.
Modelo de Capacitación para (Estrategia del Servicio) Un marco de trabajo para ayudar a los
Proveedores [eSourcing Proveedores de Servicios de TI a desarrollar sus Capacidades de Gestión
Capability Model for de Servicios de TI desde una perspectiva de Aprovisionamiento del
Proveedor de Servicioss]
Servicio. ESCM-CL fue desarrollado por Carnegie Mellon University. Ver
(eSCM-SP)
eSCM-CL.
Middleware [Middleware] (Diseño del Servicio) Software que conecta uno o más Componentes o
Aplicaciones software. El Middleware generalmente se adquiere de un
Suministrador, en lugar de desarrollarlo dentro del Proveedor de Servicios
de TI. Ver Empaquetado.
Modelado [Modelling] Técnica que se emplea para predecir el comportamiento futuro de un

Sistema, Proceso, Servicio de TI, Elemento de Configuración etc. El
Modelado suele emplearse en Gestión Financiera, Gestión de Capacidad
y Gestión de Disponibilidad.
Modelado analítico (Estrategia del Servicio) (Diseño del Servicio) (Mejora Continua del
[Analytical Modelling] Servicio) Técnica que utiliza Modelos matemáticos para predecir el
comportamiento de un Elemento de Configuración o Servicio TI. Los
Modelos Analíticos se usan con mayor frecuencia en la Gestión de la
Capacidad y en la Gestión de Disponibilidad. Ver Modelado.
Modelo [Model] Representación de un Sistema, Proceso, Servicio de TI, Elemento de

Configuración etc. empleado para ayudar a entender o predecir
comportamientos futuros.
Modelo de Cambio [Change (Transición del Servicio) Modo repetible de gestionar una Categoría
Model] particular de Cambio. Un Modelo de Cambio enumera los pasos
específicos predefinidos que deberán ser seguidos para un Cambio
perteneciente a esa Categoría. Los Modelos de Cambio deben ser muy
simples, y que no requieran de aprobación (ej. Cambio de contraseña) o
pueden ser muy complejos y que incluyan muchos pasos que requieran
de aprobación (ej. Despliegue de una nueva versión de software). Ver
Cambio Estándar, Comité de Cambios.
Modelo de Capacitación para (Estrategia del Servicio) un marco de referencia para ayudar a
clientes [eSourcing Organizaciones en sus análisis y decisiones sobre Service Sourcing
Capability Model for Client Models and Strategies. eSCM-CL fue desarrollado por Carnegie Mellon
Organizations] (eSCM-CL) University. Ver eSCM-SP.
Modelo de Capacitación para (Estrategia del Servicio) Un marco de trabajo para ayudar a los
Proveedores [eSourcing Proveedores de Servicios de TI a desarrollar sus Capacidades de Gestión
Capability Model for de Servicios de TI desde una perspectiva de Aprovisionamiento del
Proveedor de Servicioss] Servicio. ESCM-CL fue desarrollado por Carnegie Mellon University. Ver
(eSCM-SP)
eSCM-CL.
Monitorización Activa [Active (Operación del Servicio) Monitorización de un Elemento de
Monitoring] Configuración o de un Servicio TI que utiliza de forma regular revisiones
automatizadas para descubrir el estado actual. Ver Monitorización Pasiva.

Monitorización Pasiva (Operación del Servicio) Monitorización de un Elemento de
[Passive Monitoring] Configuración, un Servicio TI o un Proceso que depende de una Alerta o
notificación para la identificación de su estado. Ver también Monitorización
Activa.
Monitorización Proactiva (Operación del Servicio) Se trata de la Monitorización que trata de
[Proactive Monitoring] encontrar patrones, a partir de Eventos, para predecir posibles Fallos
futuros. Ver también Monitorización Reactiva.
Monitorización Reactiva (Operación del Servicio) Monitorización de esa acción en respuesta a un

[Reactive Monitoring] Evento. Por ejemplo, enviando un proceso por lotes cuando un proceso
anterior se completa, o enviando un Incidente cuando ocurra un Error. Ver
Monitorización Proactiva.
Negocio [Business] (Estrategia del Servicio) El total de una entidad u Organización
compuesta por un número de Unidades de Negocio. En el contexto de
ITSM, en el Negocio se incluye tanto el sector público, como el privado y
organizaciones sin fines de lucro. Un Proveedor de Servicios TI provee de
Servicios TI a un Cliente que es parte del Negocio. El Proveedor de
Servicio TI puede ser parte del mismo Negocio que el Cliente (Proveedor
de Servicio Interno) o parte de otro Negocio (Proveedor de Servicio
Externo).
Nivel de Madurez [Maturity Nivel identificado en un modelo de Madurez como el Modelo de
Level] Integración de Madurez de la Capacidad de Carnegie Mellon.
Nivel de Servicio [Service Resultados medidos y reportados frente a uno o más Objetivos de Nivel
Level] de Servicio. El término Nivel de Servicio es a veces empleado para
refererise a un Objetivo de Nivel de Servicio.
Objetivo [Objetivo] El propósito o la intención definidos de un Proceso, una Actividad o una
Organización en su totalidad. Los Objetivos se expresan generalmente
como metas medibles. El término Objetivo se usa también de manera
informal para querer decir Requisito. Ver Salida.
Objetivo de Mantenimiento (Operación del Servicio) Tiempo esperado en el que un Elemento de

del Servicio [Service Configuración no estará disponible debido a una Actividad de
Maintenance Objetivo] mantenimiento programada.
Objetivo de Nivel de Servicio (Diseño del Servicio) (Mejora Continua del Servicio) Compromiso que
[Service Level Target] está documentado en un SLA. Los Objetivos de Nivel de Servicio se
basan en los Requerimientos de Nivel de Servicio y son necesarios para
asegurar que el Diseño del Servicio de TI es Ajustado al Propósito del
mismo. Los Objetivos de Nivel de Servicio deben ser SMART y
normalmente se basan en KPIs.
Objetivo de Punto de (Operación del Servicio) La cantidad máxima de información que puede
Recuperación [Recovery ser perdida cuando el Servicio es restaurado tras una interrupción. El
Point Objetivo] (RPO) Objetivo de Punto de Recuperación se expresa como una longitud de
tiempo antes del Fallo. Por ejemplo, un Objetivo de Punto de
Recuperación de un día debe ser soportado por Copias de Seguridad
diarias, y hasta 24 horas de información pueden ser perdidas. Los
Objetivos de Punto de Recuperación para cada Servicio de TI debería ser
negociado, acordado y documentado, y utilizado como Requisitos para el
Diseño del Servicio y los Planes de Continuidad de TI.
Objetivo de Tiempo de (Operación del Servicio) El tiempo máximo permitido para la
Recuperación [Recovery recuperación de un Servicio de TI tras una interrupción. El Nivel de
Time Objetivo] (RTO) Servicio a ser provisto debe ser inferior a los Objetivos de Nivel de
Servicio. Los Objetivos de Tiempo de Recuperación para cada Servicio de
TI deberían ser negociados, acordados y documentados. Ver Análisis de
Impacto de Negocio.
Objetivos del Negocio (Estrategia del Servicio) El Objetivo de un Proceso de Negocio, o del
[Business Objetivo] Negocio como un todo. Los Objetivos del Negocio apoyan la Visión de
Negocio, proveen de guías para la Estrategia de TI, y frecuentemente
reciben apoyo de los Servicios TI.

Observación Técnica (Mejora Continua del Servicio) Una técnica usada en la Mejora del
[Technical Observation](TO) Servicio, investigación de Problemas y Gestión de Disponibilidad. El
personal de Soporte Técnico se reúne para monitorizar el comportamiento
y Rendimiento de un Servicio de TI y realizar recomendaciones de mejora.
Off-shore [Off-shore] (Estrategia del Servicio) Provisión de Servicios desde una localización
externa al país del Cliente y, frecuentemente, en diferente continente.
Puede tratarse de un Servicio de TI, o de funciones de soporte, como
podría ser el Centro de Servicio al Usuario. Ver también On-shore, Near-
shore.
Oficina de Comercio del OGC consiguió la marca ITIL® (derechos de autor y marca registrada).
Gobierno [Office of OGC es un departamento del Gobierno de UK que da soporte a la
Government Commerce] realización de la agenda de compras del gobierno gracias a su trabajo en
(OGC) alianzas de contratación y de sus elevados niveles de aptitudes y
habilidades de compra con distintos departamentos. También proporciona
soporte a proyectos complejos para el sector público.
Oficina para la Información OPSI licencia el material sujeto a derechos utilizado en las publicaciones
del Sector Público [Office of relacionadas con ITIL. Existe un departamento del gobierno británico que
Public Sector Information] proporciona acceso online a la legislación británica, licencia la utilización
(OPSI)
del material sujeto a derechos, gestiona su utilización comercial, mantiene
el registro de información gubernamental y proporciona asistencia en
relación con las publicaciones oficiales y sus derechos de reproducción.
On-shore [On-shore] (Estrategia del Servicio) Provisión de Servicios desde el propio país del
Cliente. Ver también Off-shore, Near-shore.
Opción de Recuperación (Diseño del Servicio) Una Estrategia para responder a una interrupción
[Recovery Option] del Servicio. Las Estrategias comunes son No Hacer Nada, Alternativa
Manual, Arreglo Recíproco, Recuperación Gradual, Recuperación Rápida,
Recuperación Inmediata. Las Opciones de Recuperación pueden utilizar
instalaciones dedicadas, o instalaciones de Terceros compartidas por
múltiples Negocios.
Operación [Operation] (Operación del Servicio) Gestión del día a día de un Servicio de TI, un
Sistema, u otro Elemento de Configuración. El término Operación se usa
también para referirse a una Actividad o Transacción predefinidas. Por
ejemplo, la carga de una cinta magnética, la recogida de importes en un
punto de venta, o la lectura de datos por una unidad de disco.
Operación Continua (Diseño del Servicio) Un acercamiento o diseño para eliminar Downtime
[Continuous Operation] planeado de un Servicio TI. Advierta que un Elemento de Configuración
puede estar caído mientras el Servicio TI está Disponible.
Operación del Servicio (Operación del Servicio) Una fase en el Ciclo de Vida de un Servicio de
[Service Operation] TI. La Operación del Servicio Influye varios Procesos y Funciones y es
uno de los títulos principales en las publicaciones de ITIL.
Operacional [Operational] El nivel inferior de los 3 niveles de la Planificación y Entrega(Estratégico,

Táctico, Operacional). Las Actividades Operacionales incluyen la
Planificación o entrega del día a día de un Proceso de Negocio o un
Proceso de Gestión de un Servicio de TI. El término Operacional puede
usarse como sinónimo del término Real.
Operaciones de TI [TI (Operación del Servicio) Actividades desempeñadas por Control de
Operations] Operaciones de TI, incluyendo Gestión de Consolas, Planificación de
Tareas, Backup y Restauración, y Gestión de Salida e Impresión.
Operaciones de TI se utiliza también como sinónimo de Operación del
Servicio.

Operar [Operate] Obtener un rendimiento esperado. Se dice que un Proceso o un Elemento
de Configuración Opera, cuando esta proporcionando el resultado
requerido. Operar también puede referirse a la realización de una o más
Operaciones. Por ejemplo, Operar un ordenador consiste en la realización
de las Operaciones diarias que necesita para su rendimiento correcto.
Operativa del Negocio (Estrategia del Servicio) La ejecución del día a día, la monitorización y la
[Business Operations] gestión de los Procesos de Negocio.
Optimización de la Provisión (Estrategia del Servicio) Análisis de los recursos y restricciones que se
del Servicio [Service tienen para un Servicio de TI para decidir si existen formas alternativas de
Provisioning Optimization] prestar el Servicio que puedan reducir Costes o mejorar la Calidad.
(SPO)
Optimizar [Optimise] Revisar, Planificar y solicitar Cambios orientados a la obtención de la
máxima Eficacia y Eficiencia para un Proceso, Elemento de
Configuración, Aplicación, etc.
Organización [Organisation] Empresa, entidad legal o cualquier otra institución. Algunos ejemplos de
Organizaciones que no son Empresas pueden ser la Organización
Internacional de Estándares (ISO) o itSMF. El término Organización se
utiliza también para referirse a cualquier entidad que disponga de
Personal, Recursos y Presupuesto, como puede ser un Proyecto o una
Unidad de Negocio.
Organización Internacional Ver Organización Internacional de Estandarización (ISO).
de Estándares [International
Standards Organisation]
Organización Internacional La Organización Internacional de Estandarización (ISO) es el mayor

de Estandarización desarrollador de Estándares del mundo. ISO es una organización no
[International Organization gubernamental que constituye una red de los Institutos de Estandarización
for Standardization] (ISO)
nacionales de 156 países. Existe mayor información sobre ISO disponible
en http://www.iso.org/
Outsourcing [Outsourcing] (Estrategia del Servicio) Utilización de un Proveedor de Servicios
Externo para la Gestión de Servicios de TI. Ver también Service Sourcing,
Proveedor de Servicio de Tipo III.
Paquete de Diseño del (Diseño del Servicio) Documento o Documentos que definen todos los
Servicio [Service Design aspectos de un Servicio de TI y sus Requerimientos a en cada una de las
Package] fases de su Ciclo de Vida. Se realiza un Paquete de Diseño del Servicio
por cada Servicio de TI nuevo, Cambio relevante o retirada de Servicio de
TI.
Paquete de Nivel de Servicio (Estrategia del Servicio) Nivel definido de Utilidad y Garantía para un
[Service Level Package] determinado Paquete de Servicio. Cada SLP se diseña para cumplir con
(SLP) las necesidades de un determinado Patrón de Actividad de Negocio. Ver
Línea de Servicio.
Paquete de Servicio [Service (Estrategia del Servicio) Descripción detallada de un Servicio de TI
Package] preparado para ser suministrado a los Clientes. Un Paquete del Servicio
incluye un Paquete del Nivel de Servicio y uno o más Servicios Esenciales
y Servicios Añadidos.
Paquete Principal de Servicio (Estrategia del Servicio) Una descripción detallada de un Servicio
[Core Service Package] Principal que puede ser compartido por uno o más Paquetes de Niveles
(CSP) de Servicio. Ver Paquete de Servicio.
Parada Planificada [Planned (Diseño del Servicio) Periodo de tiempo acordado previamente durante
Downtime] el cual un Servicio TI no se encontrará disponible. Las Paradas
Planificadas se utilizan para la realización de tareas de mantenimiento,
actualizaciones o pruebas. Ver también Ventana de Cambios,
Indisponibilidad.

Patrones de Actividad de (Estrategia del Servicio) Es un perfil de Carga de Trabajo de una o más
Negocio [Pattern of Business Actividades de Negocio. Los Patrones de Actividad de Negocio se utilizan
Actividad] (PBA) para ayudar al Proveedor de Servicios de TI a entender y planificar en
función de los diferentes niveles de Actividad del Negocio. Ver también
Perfil de Usuario.
Perfil de Usuario User Profile (Estrategia del Servicio) Un patrón de solicitud de Usuarios para
] [(UP) Servicios de TI. Cada Perfil de Usuario incluye uno o más Patrones de
Actividad de Negocio.
Perspectiva de Control (Estrategia del Servicio) un acercamiento a la Gestión de Servicios TI,
[Control perspective] Procesos, Funciones, Activos, etc. Puede haber varias Perspectivas de
Control diferentes para un mismo Servicio TI, Procesos, etc., permitiendo
a diferentes individuos o equipos enfocarse en lo que es importante y
relevante para su Rol específico. Ejemplo de Perspectiva de Control
incluye gestión Reactiva y Proactiva dentro de Operaciones TI, o una
visión de Ciclo de vida para un equipo de Proyecto de Aplicaciones.
Perspectiva del Negocio (Mejora Continua del Negocio) El entendimiento del punto de vista del
[Business Perspective] Negocio por parte del Proveedor de Servicio y de los Servicios de TI, y un
entendimiento del Negocio desde el punto de vista del Proveedor de
Servicio.
Petición de Cambio [Request (Transición del Servicio) Propuesta formal para que se realice un
for Change] (RFC) Cambio. Una RFC incluye 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í.
Petición de Servicio [Service (Operación del Servicio) Petición que hace un Usuario solicitando
Request] información, asesoramiento, un Cambio Estándar o Acceso a un Servicio
de TI. Por ejemplo, la inicialización de una clave, o provisionar a un nuevo
Usuario con Servicios de TI estándares. Las Peticiones de Servicio son
normalmente gestionadas por un Centro de Servicio al Usuario, y no
requieren que se realice una RFC. Ver Gestión de la Petición.
Piloto [Pilot] (Transición del Servicio) Despliegue limitado de un Servicio TI, una
Versión o un Proceso en el Entorno Real. Los Pilotos se utilizan para
reducir el Riesgo así como para obtener respuesta y Aceptación por parte
del Usuario. Ver también Prueba, Evaluación.
Plan [Plan] Propuesta detallada que describe las Actividades y Recursos necesarios
para la consecución de un Objetivo. Por ejemplo, el Plan para
implementar un nuevo Proceso o Servicio de TI. ISO/IEC 20000 requiere
un Plan como parte de la gestión de cada Proceso de Servicio de TI.
Plan de Capacidad [Capacity (Diseño del Servicio) El Plan de Capacidad se usa para gestionar los
Plan] Recursos requeridos para proveer Servicios de TI. El Plan contiene
escenarios para distintas predicciones de demanda de Negocio, y las
opciones valoradas para proveer los Objetivos de Nivel de Servicio
acordados.
Plan de Continuidad de los (Diseño del Servicio) Plan que define los pasos necesarios para
Servicios de TI [TI Service Recuperar uno o más Servicios de TI. El Plan además identificará los
Continuity Plan] disparadores de la Invocación del plan, las personas que han de ser
involucradas, las comunicaciones necesarias etc. El Plan de Continuidad
de los Servicios de TI debería ser parte de un Plan de Continuidad del
Negocio.
Plan de la Continuidad del (Diseño del Servicio) Plan que define los pasos que se requieren para el
Negocio [Business Restablecimiento de los Procesos de Negocio después de una
Continuity Plan] (BCP) interrupción. El Plan también identifica los disparadores para la
Invocación, las personas involucradas, las comunicaciones, etc. El Plan
de la Continuidad del Servicio TI es una parte importante de los Planes de
Continuidad del Negocio.
Plan de la Disponibilidad (Diseño del Servicio) Plan para asegurar que se puede proveer los
[Availability Plan] Requerimientos de Disponibilidad actuales y futuros de los Servicios TI a
Costo Efectivo.

Plan de Mejora de Servicio (Mejora Continua del Servicio) Un Plan formal para implementar
[Service Improvement Plan] mejoras a un Proceso o Servicio de TI.
(SIP)
Planificación Es la Actividad responsable de la creación de los Planes. Por ejemplo, la

Planificación de Capacidad.
Planificación de la Capacidad (Diseño del Servicio) Actividad del proceso de Gestión de Capacidad
[Capacity Planning] responsable de la creación de un Plan de Capacidad.
Planificación de Tareas [Job (Operación del Servicio) Planificación y gestión de la ejecución de las
Scheduling] tareas software requeridas como parte de un Servicio de TI. La
Planificación de Tareas es realizada por la Gestión de Operaciones de TI,
y frecuentemente se encuentra automatizada mediante herramientas
software que ejecutan tareas por lotes o en línea en momentos
específicos del día, de la semana, del mes o del año.
Planificación de Transición y (Transición del Service) El Proceso responsable de la planificación de
Soporte [Transition Planning todos los Procesos de Transición del Servicio y de la coordinación de los
and Support] recursos que requiere. Estos Procesos de Transición del Servicio son
Gestión de Cambios, Gestión de Activos de Servicio y Gestión de
Configuración, Gestión de Despliegue y Versiones, Validación de Servicio
y Prueba, Evaluación y Gestión del Conocimiento.
Planificar, Realizar, (Mejora Continua del Servicio) Ciclo de gestión de Procesos en cuatro
Comprobar, Actuar [Plan-Do- etapas, atribuido a Edward Deming. Plan-Do-Check-Act es también
Check-Act] conocido como el Ciclo de Deming. PLAN: Diseñar o revisar Procesos que
soportan Servicios de TI. DO: Implementación del Plan y gestión de los
Procesos. CHECK: Medición de los Procesos y de los Servicios de TI,
comparación con los Objetivos marcados y generación de informes.. ACT:
Planificación e implementación de Cambios para la mejora de los
Procesos.
PMBOK Estándar de Gestión de Proyectos mantenido y publicado por el Project
Management Institute. PMBOK son las siglas de Project Management
Body of Knowledge (Cuerpo de Conocimiento de Gestión de Proyectos).
Para más información, consultar http://www.pmi.org/. Ver también
PRINCE2.
Política [Policy] Documento formal que contiene las intenciones y expectativas de gestión.
Las Políticas se utilizan para dirigir las decisiones, y asegurar un
desarrollo e implementación coherente y apropiado de los Procesos,
Estándares, Roles, Actividades, Infraestructura de TI, etc.
Política de Información de (Diseño del Servicio) Política que gobierna la visión de la Organización a
Seguridad [Information la Gestión de la Información de Seguridad.
Security Policy]
Política de Seguridad Sinónimo de Política de Seguridad Informática

[Security Policy]
Porcentaje de Uso (Diseño del Servicio) Cantidad de tiempo que un Componente se
[Percentage utilisation] encuentra ocupado durante un periodo de tiempo predeterminado. Por
ejemplo, si una CPU está ocupada durante 1.800 segundos a lo largo de
una hora, su utilización será del 50%.
Potencial de Servicio (Estrategia del Servicio) Valor total posible de la suma de todas las
[Service Potential] Capacidades y Recursos de un Proveedor de Servicios de TI.
Práctica [Practice] Se trata de un método de trabajo, o en el que el trabajo debería realizarse.
Las Prácticas pueden incluir Actividades, Procesos, Funciones,
Estándares y Guías. Ver también Mejores Practicas.
Precio [Pricing] (Estrategia del Servicio) Actividad que establece la cantidad que debe
ser Cobrada a los Clientes.
Prerequisitos para el Éxito Es una Actividad que necesita ser completada, o una condición que
[Prerequisite for Success] necesita ser conseguida, para permitir una exitosa implementación del
(PFS) Plan o del Proceso. La PFS es, frecuentemente, un entregable de un
Proceso que es requerido como entrada por otro Proceso.
Presentación de Informes del (Mejora Continua del Servicio) Proceso responsable de la generación y
Servicio [Service Reporting] entrega de los informes de cumplimiento y tendencias de Niveles de
Servicio. La Presentación de Informes del Servicio debe acordar con los
Clientes el formato, contenido y frecuencia de los informes.
Presupuestar [Budgeting] La Actividad para predecir y controlar el gasto de dinero. Es un ciclo de

negociaciones periódicas para establecer el Presupuesto futuro
(normalmente en periodos anuales) y la monitorización y ajustes diarios
del Presupuesto actual.
Presupuesto [Budget] Lista de todo el dinero que una Organización o una Unidad de Negocio ha
planificado recibir y pagar en un tiempo específico. Ver Presupuesto,
Planificación.
PRINCE2 [PRINCE2] Metodología de Gestión de Proyectos estándar del gobierno del Reino
Unido. Para más información, consultar http://www.ogc.gov.uk/prince2/
Ver también PMBOK.
Principio de Pareto [Pareto (Operación del Servicio) Técnica utilizada para la asignación de
Principle] prioridades a diferentes Actividades. El Principio de Pareto dice que el
80% del valor de una Actividad es generado por el 20% del esfuerzo. El
Principio de Pareto se usa también en la Gestión de Problemas para
priorizar la investigación de posibles causas del Problema.
Prioridad [Priority] (Transición del Servicio) (Operación del Servicio) Categoría empleada
para identificar la importancia relativa de un Incidente, Problema o
Cambio. La Prioridad se basa en el Impacto y la Urgencia, y es utilizada
para identificar los plazos requeridos para la realización de las diferentes
acciones. Por ejemplo, el SLA podría indicar que los Incidentes de
Prioridad 2 deben ser resueltos en menos de 12 horas.
Problema [Problem] (Operación del Servicio) Causa de uno o más Incidentes. En el
momento en el que se crea el Registro del Problema, no es frecuente
conocer su causa, por lo que es necesario realizar su investigación
mediante el Proceso de Gestión de Problemas.
Procedimiento [Procedure] Documento que contiene los pasos que se deben seguir para la
realización de una determinada Actividad. Los Procedimientos se definen
como partes de Procesos. Ver también Instrucción de Trabajo.
Procedimientos de (Operación del Servicio) Procedimientos empleados por la Gestión de

Operación Estándar Operaciones de TI.
[Standard Operating
Procedures] (SOP)
Proceso [Process] Conjunto estructurado de Actividades diseñado para la consecución de un
Objetivo determinado. Los Procesos requieren de una o más Entradas y/o
inversiones y producen una serie de salidas, ambas previamente
definidas. Un Proceso suele incorporar la definición de los Roles que
intervienen, las responsabilidades, herramientas y Controles de gestión
necesarios para obtener las salidas de forma eficiente. El Proceso podrá
definir las Políticas, Estándares, Guías de Actuación, Actividades, y las
Instrucciones de Trabajo que fueran necesarias.
Proceso de Negocio Un Proceso que le pertenece y que lo conduce el Negocio. Un Proceso de
[Business Process] Negocio contribuye a la entrega de un producto o Servicio para un Cliente
del Negocio. Por ejemplo, un revendedor podría tener un Proceso de
compra que ayuda a entregar Servicios a sus Clientes del Negocio.
Muchos de los Procesos de Negocio están basados en Servicios TI.
Proceso de Versión [Release El nombre usado por ISO/IEC 20000 para el grupo de Proceso que
Process] incluye la Gestión de Versión. Este grupo no incluye ningún otro proceso.
El Proceso de Versión también se usa como sinónimo del Proceso de
Gestión de Versión.
Procesos de Control [Control Grupo de Procesos ISO/IEC 20000 que incluye Gestión de Cambios y
Processes] Gestión de Configuración.
Procesos de Relación El grupo de Procesos ISO/IEC 20000 que incluye la Gestión de
[Relationship Processes] Relaciones de Negocios y la Gestión de Proveedores

Procesos de Resolución El grupo de Proceso ISO/IEC 20000 que incluye la Gestión de Incidentes
[Resolution Processes] y la Gestión de Problemas.
pro-forma [pro-forma] Plantilla o ejemplo de Documento que contiene datos de ejemplo para ser
sustituidos por los valores reales una vez que estos estén disponibles.
Programa [Programme] Conjunto de Proyectos y Actividades planificadas y gestionadas como

como una unidad para la obtención de unos Objetivos y Entregables
comunes.
Propietario de Servicio (Mejora Continua del Servicio) Rol responsable de la entrega de un
[Service Owner] determinado Servicio de TI.
Proveedor [Supplier] (Estrategia del Servicio) (Diseño del Servicio)Tercero responsable de

suministrar bienes o Servicios que son necesarios para proporcionar
Servicios de TI. Ejemplos de proveedores incluyen los vendedores de
hardware y software, proveedores de redes y telecomunicaciones y
Organizaciones de Outsourcing. Ver Contrato de Soporte, Cadena de
Suministro.
Proveedor de Servicio de (Estrategia del Servicio) Un Proveedor de Servicio Interno que está
Tipo I [Type I Proveedor de integrado dentro de una Unidad de Negocio. Puede haber varios
Servicios] Proveedores de Servicio de Tipo I dentro de una Organización.
Proveedor de Servicio de (Estrategia del Servicio) Un Proveedor de Servicio Interno que

Tipo II [Type II Proveedor de proporciona Servicios de TI compartidos a más de una Unidad de
Servicios] Negocio.
Proveedor de Servicio de (Estrategia del Servicio) Un proveedor de Servicio que proporciona
Tipo III [Type III Proveedor de Servicios de TI a Clientes Externos.
Servicios]
Proveedor de Servicios (Estrategia del Servicio) Organización que presta Servicios a uno o más
[Proveedor de Servicios] Clientes Internos o Clientes Externos. El término de Proveedor de
Servicios se usa a menudo como forma abreviada de Proveedor de
Servicios de TI. Ver Proveedor de Servicios Tipo I, Proveedor de Servicios
Tipo II, Proveedor de Servicios Tipo III.
Proveedor de Servicios de (Diseño del Servicio) Es un Proveedor Externo de Servicios que provee
Aplicaciones [Application Servicios TI usando Aplicaciones que se ejecutan con recursos del
Proveedor de Servicios] Proveedor de Servicios. Los Usuarios acceden a las Aplicaciones del
(ASP)
Proveedor de Servicios por medio de conexiones de red.
Proveedor de Servicios de TI (Estrategia del Servicio) Proveedor de Servicio que proporciona

[TI Proveedor de Servicios] Servicios de TI a Clientes Internos o Externos.
Proveedor Externo de (Estrategia del Servicio) Un Proveedor de Servicio de TI que es parte de

Servicio [External Proveedor una Organización diferente a la de su Cliente. Un Proveedor de Servicio
de Servicios] de TI puede tener tanto Clientes Internos como Externos. Ver Proveedor
de Servicio de Tipo III
Proveedor Interno de (Estrategia del Servicio) Proveedor de Servicio de TI que es parte de la
Servicio [Internal Proveedor misma Organización que su Cliente. Un Proveedor de Servicio de TI
de Servicios] puede tener tanto Clientes Internos como Externos. Ver Proveedor de
Servicio de tipo I, Proveedor de Servicio de tipo II, Insource.
Proveedor Interno de Un Proveedor Externo de Servicio que proporciona acceso a Internet. La

Servicio [Internet Proveedor mayoría de los ISP proporcionan también otros Servicios de TI, tales
de Servicios] (ISP) como hosting de páginas web.
Proyecto [Project] Se trata de una Organización temporal , compuesta por personal y los
Activos requeridos para la obtención de los Objetivos y Entregables
necesarios. Cada Proyecto tiene un Ciclo de Vida que típicamente incluye
Inicio, Planificación, Ejecución, Cierre etc. Los Proyectos son
habitualmente gestionados mediante metodologías formales, como puede
ser PRINCE2.

Proyectos en Entornos Ver PRINCE2
Controlados [PRojects IN
Controlled Environments
(PRINCE2)
Prueba [Test] (Transición del Servicio) Una Actividad que verifica que un Elemento de
Configuración, Servicio TI, Proceso, etc. cumple con sus Especificaciones
o Requerimientos acordados. Ver Validación y Prueba del Servicio.
Aceptación.
Puente de Operaciones (Operación del Servicio) Localización física para la cual los Servicios e
[Operations Bridge] Infraestructura de TI son monitorizados y gestionados.
Punto Único de Contacto (Operación del Servicio) Proporcionar un único y consistente modo de
[Single Point of Contact] comunicarse con una Organización o Unidad de Negocio. Por ejemplo, Un
(SPOC) SPOC para un Proveedor de Servicios de TI se denomina normalmente
Centro de Servicio al Usuario.
Punto único de fallo [Single (Diseño del Servicio) Cualquier Elemento de Configuración que puede
Point of Failure] (SPOF) causar un Incidente cuando falla y para el que no se ha implementado una
Contramedida. Un SPOF puede ser tanto una persona, un paso en un
Proceso o Actividad como un Componente de la Infraestructura de TI. Ver
Fallo.
RACI [RACI] (Diseño del Servicio) (Mejora Continua del Servicio) Un Modelo usado
como ayuda para definir roles y responsabilidades. RACI significa
Responsable, Confiable, Consultado e Informado. Ver Stakeholder.
Real [Live] (Transición del Servicio) Se refiere a aquellos Servicios de TI o

Elementos de Configuración empleados para proveer Servicio a un
Cliente.
Recuperación [Recovery] (Diseño del Servicio) (Operación del Servicio) Recuperar un Elemento
de configuración o un Servicio de TI al estado de funcionamiento.
Recuperar un Servicio de TI frecuentemente, incluye la recuperación de
datos para llegar un estado consistente. Después de la recuperación otros
pasos pueden ser necesarios antes de que los Servicios de TI puedan
estar disponibles para los Usuarios (Restauración).
Recuperación Gradual (Diseño del Servicio) Una Opción de Recuperación que también es
[Gradual Recovery] conocida como Reserva fría. Recuperación del Servicio de TI en un
período de tiempo superior a 72 horas. La recuperación Gradual
normalmente emplea Facilidades Portátiles o Fijas que tienen soporte
medioambiental y cableado de Red, pero no Sistemas Informáticos. El
hardware y software se instalan dentro del Plan de Continuidad del
Servicio de TI.
Recuperación inmediata (Diseño del Servicio) Una Opción de Recuperación que también es
[Immediate Recovery] conocida como Reserva Caliente. Recuperación del Servicio de TI sin
pérdida de Servicio. La Recuperación Inmediata normalmente usa
tecnologías de espejados, balanceado de carga y distribución de
ubicaciones.
Recuperación Inmediata (Diseño del Servicio) Opción de Recuperación también conocida como
[Intermediate Recovery] Reserva Medio. Recuperación del Servicio de TI en un periodo de tiempo
entre 24 y 72 horas. La recuperación Intermedia emplea normalmente
Facilidades Fijas o Portátiles compartidas que contienen Sistemas
informáticos y Componentes de Red. El hardware y software necesita ser
configurado y los datos deben ser restaurados como parte integrante del
Plan de Continuidad del Servicio de TI.
Recuperación Rápida [Fast (Diseño del Servicio) Una Opción de Recuperación que es también
Recovery] conocida como Reserva Caliente. Recuperación del Servicio de TI en un
corto período de tiempo, típicamente menos de 24 horas. La
Recuperación Rápida normalmente usa una Facilidad Fija dedicada con
Sistemas y Software configurado y dispuesto a correr los Servicios de TI.
La Recuperación Inmediata puede llevar hasta 24 horas si hay necesidad
de Recuperar datos de Copias de Respaldo.

Recurso [Resource] (Estrategia del Servicio) Término genérico que incluye Infraestructura de
TI, personal, dinero o cualquier otra cosa que pueda ayudar a entregar un
Servicio de TI. Se considera a los Recursos como el Activo de una
Organización. Ver Capacidad, Activos de Servicio.
Red de Valor [Value Network] (Estrategia del Servicio) Un complejo conjunto de Relaciones entro 2 o
más grupos u organizaciones. El valor es generado a través del
intercambio de conocimiento, información, bienes o Servicios. Ver Cadena
de Valor, Sociedad.
Redundancia [Redundancy] Sinónimo de Tolerancia a Fallos. El término Redundante también tiene un
significado de obsoleto, o de que ya no es necesario.
Referencia [Benchmark] (Mejora Continua del Servicio) Grabar el estado de algo en un punto
específico en el tiempo. Una Referencia se puede crear para una
Configuración, un Proceso, o cualquier otro conjunto de datos. Por
ejemplo, se puede usar una Referencia en:
Mejora Continua del Servicio, para establecer el estado actual para
gestionar las mejoras.
Gestión de la Capacidad, para documentar características de Rendimiento
durante la operativa normal.
Ver Comparativas, Límea de Referencia.
Registro [Record] Un Documento que contiene el resultado u otro tipo de salida desde un
Proceso o Actividad. Los registros son la evidencia de que una Actividad
tuvo lugar, y podría ser en papel o formato electrónico. Por ejemplo, un
informe de Auditoría, un Registro de Incidente, o los minutos de una
reunión.
Registro de Activos [Asset (Transición del Servicio) Una lista de Activos que incluye dueño y valor.
Register] El Registro de Activos lo mantiene la Gestión de Activos.
Registro de Cambio [Change (Transición del Servicio) Registro que contiene los detalles de un
Record] Cambio. En cada uno de los Registros de Cambio está documentado el
Ciclo de Vida de un Cambio individual. Para cada una de las Peticiones
de Cambio se crea y se recibe un Registro de Cambio, incluso aquellos
que son rechazados posteriormente. Los Registros de Cambio deberían
hacer referencia a los Elementos de Configuración afectados por el
Cambio. Los Registros de Cambio se almacenan en el Sistema de
Gestión de Configuración.
Registro de Configuración (Transición del Servicio) Registro que contiene los detalles de un
[Configuration Record] Elemento de Configuración. Cada Registro de Configuración documenta
el Ciclo de Vida de un CI individual . Los Registros de Configuración se
almacenan en una Base de Datos de Gestión de Configuración.
Registro de Error Conocido (Operación del Servicio) Registro que contiene los detalles de un Error
[Known Error Record] Conocido. Cada Registro de Error Conocido documenta el Ciclo de Vida
de un Error Conocido, incluyendo el Estado, la Causa Raíz y la Solución
Temporal. En algunas implantaciones, un Error Conocido se documenta
empleando campos adicionales de un Registro de Problemas.
Registro de incidencias (Operación del Servicio) Registro que contiene los detalles de un
[Incident Record] Incidente. Cada registro de Incidencia documenta el Ciclo de Vida de un
solo Incidente.
Registro de Problemas (Operación del Servicio) Se trata de un Registro que contiene los
[Problem Record] detalles de cada Problema ocurrido. Cada Registro de Problemas
documenta el Ciclo de Vida de cada Problema individual.
Registro de Versión [Release (Transición del Servicio) Registro en la CMDB que define el contenido
Record] de una Versión. Un Registro de Versión tiene Relación con todos los
Elementos de Configuración que se ven afectados por la Versión.

Relación [Relationship] Conexión o interacción entre dos personas o cosas. En la Gestión de
Relaciones de Negocios es la interacción entre el Proveedor de Servicios
de TI y el Negocio. En la Gestión de Configuración es el enlace entre dos
Elementos de Configuración que identifican una dependencia o conexión
entre ellos. Por ejemplo, las Aplicaciones pueden ser enlazadas a los
Servidores sobre los que corren, los Servicios de TI pueden tener muchos
enlaces a todos los CIs que les contribuyen.
Remedio [Remediation] (Transición del Servicio) Recuperación de un estado conocido tras una
Implementación o Cambio fallido.
Rendimiento [Performance] Medida de la respuesta obtenida por un Sistema, persona, equipo,
Proceso, o Servicio TI.
Reparación [Repair] (Operación del Servicio) El repuesto o corrección de un Elemento de
Configuración fallido.
Requerimiento de Nivel de (Diseño del Servicio) (Mejora Continua del Servicio) Requerimiento del
Servicio [Service Level Cliente para un aspecto de un Servicio de TI. Los SLRs se basan en
Requirement](SLR) Objetivos de Negocio y se usan para negociar los Objetivos de Nivel de
Servicio acordados.
Requisito [Requirement] (Diseño del Servicio) Una declaración formal de lo que se necesita. Por
ejemplo: un Requisito de Nivel de Servicio, un Requisito de Proyecto, o
los Entregables requeridos para un Proceso. Ver Declaración de
Requisitos.
Reserva [Standby] (Diseño del Servicio) Empleado para referirse a Recursos que no son
necesarios para entregar los Servicios de TI en vivo, pero que están
disponibles para soportar los Planes de Continuidad de Servicio de TI. Por
ejemplo un Centro de datos de Reserva puede mantenerse para soportar
Sobreavisos Calientes, Medios o Fríos.
Reserva Caliente [Hot Sinónimo de Recuperación Rápida o Recuperación Inmediata.
Standby]
Reserva Fría [Cold Standby] Sinónimo de Recuperación Gradual.
Reserva Medio [Warm Síntoma para Intermediate Recovery.

Standby]
Resistencia [Resilience] (Diseño del Servicio) La habilidad de un Elemento de Configuración o
Servicio de TI a resistir Fallos o de Recuperarse rápidamente tras un
Fallo. Por ejemplo, un cable reforzado resistirá fallos cuando esté bajo
estrés. Ver Tolerancia a Fallos.
Resolución [Resolution] (Operación del Servicio) Acción tomada para reparar la Causa Raíz de
un Incidente o Problema o para implementar una Alternativa. En ISO/IEC
20000, el Proceso de Resolución es el grupo de Procesos que incluye la
Gestión de Problemas e Incidentes.
Respuesta Interactiva por (Operación del Servicio) Una forma de Distribución Automática de
Voz [Interactive Voice Llamadas que acepta Entradas y/o inversiones del Usuario, tales como
Response] (IVR) presionar una tecla o instrucciones vocales, para identificar el destinatario
correcto de Llamadas entrantes.
Restauración [Restore] (Operación del Servicio) Toma de acción para restaurar un Servicio de
TI a los Usuarios tras Reparar y Recuperarse de un Incidente. Este es el
Objetivo Primario de la Gestión de Incidentes
Restauración de Servicio Ver Restauración.
[Restoration of Service]
Retiro [Retire] (Transición del Servicio) Eliminación permanente de un Servicio de TI, u

otro Elemento de Configuración, del Entorno de producción. El Retiro es
una fase en el Ciclo de Vida de muchos Elementos de Configuración.
Retorno de la Inversión (Estrategia del Servicio) (Mejora de Servicio Continua) Medida del
[Return on Investment] (ROI) beneficio esperado en una inversión. En su significado más sencillo es el
provecho neto de una inversión dividida por el valor de los Activos
invertidos. Ver Valor Presente Neto, Valor de la Inversión.

Revisión [Review] La evaluación de un Cambio, Problema, Proceso, Proyecto, etc. Las
Revisiones habitualmente se llevan a cabo en puntos predefinidos en el
ciclo de vida, y especialmente tras la Clausura. El propósito de una
Revisión es asegurarse de que todos los Entregables han sido provistos,
e identificar oportunidades de mejora. Ver Revisión Post Implementación.
Revision Post Se trata de la Revisión que se realiza tras la implementación de un
Implementacion [Post Cambio o de un Proyecto. La PIR determina si el Cambio o Proyecto se
Implementation Review] (PIR) completó con éxito, e identifica nuevos oportunidades de mejora.
Riesgo [Risk] Un posible Evento que podría causar daño o pérdidas, o afectar la
habilidad de alcanzar Objetivos. Un Riesgo es medido por la probabilidad
de una Amenaza, la Vulnerabilidad del Activo a esa Amenaza, y por el
Impacto que tendría en caso que ocurriera.
Ritmo de Retorno interno (Estrategia del Servicio) Técnica empleada para ayudar a las decisiones
[Internal Rate of Return] de Gasto de Capital. IRR calcula un número que permite comparar dos o
(IRR) más inversiones alternativas. Un mayor IRR indica una mejor inversión.
Ver Valor Neto Presente, Retorno de Inversión.
Rol [Role] Conjunto de responsabilidades, Actividades y autorizaciones concedidas a
una persona o equipo. Un Rol se define en un Proceso. Una persona o
equipo puede tener múltiples Roles, por ejemplo, los Roles de
Administrador de Configuración y Administrador del Cambio pueden ser
llevados a cabo por una misma persona y de manera individual.
Seguridad [Security] Ver Gestión de Seguridad Informática.
Sensibilidad Medida del tiempo tomado para responder a algo. Podría ser un Tiempo
[Responsiveness] de Respuesta o una Transacción, o la velocidad en la que un Proveedor
de Servicio de TI responde a un Incidente o a una Petición de Cambio,
etc.
Separación de (Estrategia del Servicio) Alineación al Diseño de una solución o Servicio
Preocupaciones [Separation de TI que divide el problema en partes que pueden ser resueltas de forma
of Concerns] (SoC) independiente. Esta alineación separa “lo que” se tiene que hacer de
“como“ se tiene que hacer.
Serviciabilidad (Diseño del Servicio) (Mejora Continua del Servicio) Habilidad de un
[Serviceability] Proveedor de Terceros de cumplir los términos de su Contrato. Este
Contrato incluye los niveles acordados de Disponibilidad Mantenibilidad y
Confiabilidad de un Elemento de Configuración.
Servicio [Service] Un medio de entregar valor a los Clientes facilitando Resultados que los
Clientes quieren lograr sin la propiedad de Costes y Riesgos específicos.
Servicio de Directorio (Operación del Servicio) Aplicación que gestiona información de la

[Directory Service] Infraestructura TI disponible en un red, y relacionando Usuarios y
Derechos de acceso.
Servicio de Infraestructura Un Servicio de TI que no es usado directamente por el Negocio, pero que
[Infrastructure Service] es requerido por el Proveedor de Servicio de TI de modo que pueda
proporcionar otros Servicios de TI. Por ejemplo Servicios de Directorio,
servicios de nombrado o servicios de comunicación.
Servicio de Negocio Servicio de TI que sustenta directamente un Proceso de Negocio, en

[Business Service] contraposición a un Servicio de Infraestructura que es usado internamente
por el Proveedor de Servicios de TI y normalmente no tiene visibilidad
hacía el Negocio. El término Servicio de Negocio también se usa para
definir un Servicio que se provee a Clientes de Negocio a través de
Unidades de Negocio. Por ejemplo la provisión de servicios financieros a
Clientes de un banco, o la provisión de bienes a Clientes en una tienda de
venta al por menor. La provisión exitosa de Servicios de Negocio a
menudo depende de uno o más Servicios de TI.
Servicio de Soporte (Estrategia del Servicio) Un Servicio que posibilita o mejora un Servicio
[Supporting Service] Principal. Por ejemplo, un Servicio de Directorio o un Servicio de
Respaldo. Ver Paquete de Servicios.

Servicio de TI [TI Service] Servicio proporcionado a uno o más Clientes por un Proveedor de
Servicios de TI. Un Servicio de TI se basa en el uso de las Tecnologías de
la Información y soporta los Procesos de Negocio del Cliente. Un Servicio
de TI se compone de una combinación de personas, Procesos y
tecnología y debería estar definido en un Acuerdo de Nivel de Servicio.
Servicio Principal [Core (Estrategia del Servicio) Un Servicio TI que provee Salidas básicas
Service] solicitadas por uno o más Clientes. Ver Soporte de Servicio, Paquete
Principal de Servicio (Core Service Package).
Servicio Técnico [Technical Sinónimo de Servicio de Infraestructura.
Service]
Servicios Gestionados (Estrategia del Servicio) Perspectiva sobre los Servicios de TI que
[Managed Services] enfatiza el hecho de que son gestionados. El término Servicios
Gestionados se emplea también como sinónimo de Servicios de TI
Externalizados.
Servidor [Server] (Operación del Servicio) Ordenador que está conectado a la red y que
provee Funciones de software que son usadas por otros ordenadores.
Siguiendo al Sol [Follow the (Operación del Servicio) Una metodología para el uso del Centro de
Sun] Servio al Usuario y los Grupos de Soporte alrededor del Mundo para
proporcionar Servicio 24*7. Llamadas, Incidentes, Problemas y Solicitudes
de Servicio son pasadas entre grupos en diferentes husos horarios.
Sistema [System] Número de cosas relacionadas que trabajan juntas para conseguir el
Objetivo común. Por ejemplo:
Un Sistema Informático completo, incluyendo hardware, Software y
Aplicaciones.
Un sistema de Gestión, incluyendo múltiples Procesos que son planeados
y gestionados juntos. Por ejemplo un Sistema de Gestión de la Calidad.
Un Sistema de Gestión de Bases de Datos o un Sistema Operativo que
incluye muchos capítulos de software que son diseñados para realizar un
conjunto de Funciones relacionadas.
Sistema de Gestión Marco de trabajo de Políticas, Procesos y Funciones que asegura que una
[Management System] Organización puede alcanzar sus Objetivos.
Sistema de Gestión de la (Mejora Continua del Servicio) Conjunto de Procesos reponsables de

Calidad [Quality Management asegurar que el trabajo será realizado por una Organización con la Calidad
System] (QMS) necesaria para satisfacer las necesidades de los Objetivos de Negocio o
Niveles de Servicio. Ver ISO 9000.
Sistema de Gestión de (Transición del Servicio) Conjunto de herramientas y bases de datos

Configuración [Configuration usadas para gestionar los datos de Configuración de un Proveedor de
Management System] (CMS) Servicios de TI. El CMS también incluye información sobre Incidentes,
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. El CMS es mantenido por
Gestión de Configuración y es usado por todos los Procesos de Gestión de
Servicios de TI. Ver Base de Datos de Gestión de Configuración, Sistema
de Gestión del Conocimiento del Servicio
Sistema de Gestión de (Diseño del Servicio) Marco de Políticas, Procesos, Estándares, Líneas
Seguridad de Información Maestras y herramientas que aseguran que una Organización puede
[Information Security alcanzar sus objetivos en la Gestión de Seguridad de la Información.
Management System ] (ISMS)
Sistema de Gestión del (Transición del Servicio) Conjunto de herramientas y bases de datos que
Servicio de Conocimiento se emplean para gestionar el conocimiento y la información. El SKMS
[Service Knowledge incluye tanto el Sistema de Gestión de Configuración como otras
Management System herramientas y bases de datos. El SKMS almacena, gestiona, actualiza y
](SKMS)
presenta toda la información que un Proveedor de Servicio de TI necesita
para gestionar todo el Ciclo de Vida de los Servicios de TI.

Sistema de Información de (Diseño del Servicio) Repositorio virtual de todos los datos del proceso de
Gestión de la Capacidad Gestión de Capacidad, típicamente almacenados en múltiples
[Capacity Management localizaciones físicas. Ver Sistema de Gestión del Conocimiento del
Information System] (CMIS)
Servicio.
Sistema de Información de (Diseño del Servicio) Repositorio virtual que contiene todos los datos de
Gestión de Disponibilidad la Gestión de Disponibilidad, comúnmente se almacena en múltiples
[Availability Management ubicaciones físicas. Ver Service Knowledge Management System.
Information System] (AMIS)
SMART [SMART] (Diseño del Servicio) (Mejora Continua del Servicio) Acrónimo para
ayudar a recordar que los objetivos en los Niveles de Acuerdo de Servicios
y Planes de Proyecto deben ser Específicos (Specific), Medibles
(Measurable), Alcanzables (Achievable), Relevantes (Relevant) y viables
en Tiempo (Timely).
Sobrecoste [Overhead] Sinónimo de Coste Indirecto
Sociedad [Partnership] Es una relación entre dos Organizaciones que supone una estrecha
colaboración entre ambas, orientada a la consecución de objetivos
comunes para beneficio mutuo. Un Proveedor de Servicios TI debería
tener una relación de Sociedad con el Negocio, así como con aquellas
Terceras Partes que sean críticas para proveer los Servicios de TI. Ver
también Red de Valor.
Solución Temporal Manual Solución Temporal que requiere intervención manual. El término Solución
[Manual Workaround] Temporal Manual se emplea también como el nombre de una Opción de
Recuperación en la que el Proceso de Negocio Opera sin el uso de los
Servicios de TI. Ésta es una medida temporal y normalmente se combina
con otra Opción de Recuperación.
Soporte de Primera línea (Operación del Servicio) El primer nivel en una jerarquía de Grupos de
[First-line Support] Soporte involucrados en la resolución de Incidentes. Cada nivel contiene
capacidades más especializadas, o tiene más tiempo u otros Recursos.
Ver Escalado.
Soporte de Segunda Línea (Operación del Servicio) El Segundo nivel en la jerarquía de Grupos de
[Second-line Support] Soporte envueltos en la resolución de Incidentes e investigación de
Problemas. Cada nivel contiene más habilidades especializadas, o tiene
más tiempo u otros Recursos.
Soporte de Tercer Nivel (Operación del Servicio) El tercer nivel en una jerarquía de Grupos de
[Third-line Support] Soporte involucrada en la resolución de Incidentes e investigación de
Problemas. Cada nivel contiene capacidades más especializadas, tiene
más tiempo u otros Recursos.
Soporte Técnico [Technical Sinónimo de Gestión Técnica.
Support]
Soporte temprano [Early Life (Transición del Servicio) Soporte provisto para un Servicio TI Nuevo o
Support] Cambiado para un periodo de tiempo, posterior a su Entrega. Durante el
Soporte Temprano el Proveedor de Servicio TI puede revisar los KPIs,
Niveles de Servicio y Monitorizar Umbrales, y proveer Recursos
Adicionales para Incidentes y Gestión de Problemas.
Stakeholder [Stakeholder] Conjunto de personas que tienen interés en una Organización, Proyecto,
Servicio de TI, etc. Los Interesados pueden interesarse en las Actividades,
Objetivos, Recursos o Entregables. Los Interesados pueden incluir
Clientes, Asociaciones, empleados, shareholders, propietarios, etc. Ver
RACI.
Super Usuario [Super User] (Operación del Servicio) Usuario que ayuda a otros Usuarios y asiste en
la comunicación en el Centro de Servicio al Usuario o con otras partes del
Proveedor de Servicios de TI. Super Usuarios normalmente proporcionan
entrenamiento y soporte para Incidentes menores

Tablero de resultados (Operación del Servicio) Representación gráfica de Resultados generales
[Dashboard] de Servicios TI y Disponibilidad. Imágenes de resultados pueden ser
actualizadas en tiempo real y pueden también ser incluidas en gestión de
reportes y páginas web. Esta herramienta puede ser utilizada para ayudar
en la Gestión de Niveles de Servicio, Gestión de Eventos o Diagnóstico de
Incidentes.
Táctico [Tactical] El intermedio de los tres niveles de Planificación y entrega (Estratégico,
Táctico y Operacional). Las Actividades Tácticas incluyen los Planes a
medio plazo requeridos para alcanzar Objetivos específicos, típicamente a
lo largo de un periodo de semanas o meses.
Tecnología de la Información Uso de la tecnología para el almacenamiento, comunicación o procesado

[Information Technology] (TI) de información. La tecnología incluye típicamente ordenadores,
telecomunicaciones, Aplicaciones y otro software. La información puede
incluir datos de Negocio, voz, imágenes, video, etc. La Tecnología de la
Información (TI) es a menudo usada para soportar Los Procesos de
Negocio a través de Servicios de TI.
Tercero(s) [Third Party] Una persona, grupo, o Negocio que no es parte del Acuerdo de Nivel de
Servicio para un Servicio de TI, pero que es requerida para asegurar el
éxito en la entrega de ese Servicio de TI. Por ejemplo, un Proveedor de
software, una empresa de mantenimiento de hardware, o el departamento
de .... Los requerimientos para los terceros están normalmente
especificados en Contratos de Soporte o Acuerdos de Nivel Operacional.
Términos de Referencia] (Diseño del Servicio) Documento que especifica los Requerimientos,
(TOR) Alcance, Entregables, Recursos y planificación para un Proyecto o
Actividad.
Tiempo Acordado para el (Diseño del Servicio) Sinónimo de Horas de Servicio, se usa
Servicio [Agreed Service frecuentemente en el cálculo de la Disponibilidad. Ver Tiempo Promedio de
Time] Reparación.
Tiempo de Respuesta Una medida del tiempo para completar una Operación o Transacción.
[Response Time] Usado en la Gestión de Capacidad como medida del Rendimiento, y en la
Gestión de Incidentes como una medida del tiempo tomado para contestar
una llamada, o iniciar el Diagnóstico.
Tiempo medio de caída (Diseño del Servicio) (Operación del Servicio) El tiempo en que un
[Downtime] Elemento de Configuración o un Servicio TI no está Disponible durante un
Tiempo Acordado de Servicio. La Disponibilidad de un Servicio TI es
frecuentemente calculado desde el Tiempo Acordado de Servicio y el
Downtime.
Tiempo Medio de Reparación Tiempo medio dedicado a reparar un Elemento de Configuración o Servicio
[Mean Time To Repair] de TI tras un Fallo. MTTR se mide desde que el CI o Servicio de TI falla
(MTTR) hasta que es Reparado. MTTR no incluye el tiempo necesario para
Recuperar o Restaurar. MTTR se emplea algunas veces de forma
incorrecta para querer decir Tiempo Medio de Restauración del Servicio.
Tiempo Medio de Tiempo medio dedicado a Restaurar un Elemento de Configuración o

Restauración del Servicio Servicio de TI tras un Fallo. MTTR se mide desde que el CI o Servicio de
[Mean Time to Restore TI falla hasta que está completamente Restaurado y dando su
Service] (MTRS)
funcionalidad normal. Ver Mantenibilidad, Tiempo Medio de Reparación.
Tiempo Medio entre Fallos (Diseño del Servicio) Métrica para medir y reportar la Fiabilidad. MTBF es
[Mean Time Between el tiempo medio que un Elemento de Configuración o Servicio de TI puede
Failures] (MTBF) realizar su Función concertada sin interrupción. Se mide desde que el CI o
Servicio de TI empieza a funcionar, hasta que falla la siguiente vez.
Tiempo Medio entre (Diseño del Servicio) Métrica para medir y reportar la Fiabilidad. MTBSI
Incidentes de Servicio [Mean es el tiempo medio desde que un Sistema o Servicio de TI falla, hasta que
Time Between Service falla la siguiente vez. MTBSI es igual a MTBF + MTRS.
Incidents] (MTBSI)

Tipo de Coste [Cost Type] (Estrategia del Servicio) la categoría de más alto nivel al cual los Costes
son asignados en el Presupuesto y la Contabilidad. Por ejemplo hardware,
software, recursos humanos, instalaciones, costes externos y de
Transferencia. Ver Elementos de Costes, Tipo de Coste.
Tipo de Elemento de (Transición del Servicio) Categoría que se usa para Clasificar CIs. El
Configuración [CI Type] Tipo de Elemento de Configuración identifica los Atributos y Relaciones
requeridas para un Registro de Configuración. Tipos de Elementos de
Configuración comunes son: hardware, Documento, Usuario etc.
Tipo de Llamada [Call Type] (Operación del Servicio) Categoría usada para la distinción entre
peticiones realizadas a un Centro de Servicio al Usuario. Tipos de Llamada
habituales son Incidente, Petición de Servicio y Reclamación.
Tolerancia a Fallos [Fault (Diseño del Servicio) Habilidad de un Servicio de TI ó Elemento de

Tolerance] Configuración para continuar su Operación correcta tras el Fallo de un
Componente. Ver Resistencia, Contramedida.
Trabajo en Curso [Work in Un Estado que significa que las Actividades han comenzado pero no están
Progress] (WIP) completadas. Es usado comúnmente como Estado para Incidentes,
Problemas, Cambios etc.
Transacción [Transaction] Una Función discreta realizada por un Servicio de TI. Por ejemplo,
transferir dinero de una cuenta bancaria a otra. Un transacción simple
puede involucrar numerosas adiciones, borrados y modificaciones de
datos. Bien todas se completan con éxito o ninguna es realizada.
Transición [Transition] (Transición del Servicio) Un cambio de estado, correspondiente al

movimiento de un Servicio de TI u otro Elemento de Configuración de un
estado en su Ciclo de Vida a otro.
Transición del Servicio (Transición del Servicio) Uno de los estados del Ciclo de Vida de un
[Service Transition] Servicio de TI. La Transición del Servicio incluye varios Procesos y
Funciones y es el título de uno de los libros Esenciales de ITIL. Ver
Transición.
Turno [Shift] (Operación del Servicio) Grupo o equipo de personas que realizan un Rol
específico durante un periodo de tiempo fijo. Por ejemplo puede haber
cuatro turnos de personal de Control de Operaciones de TI para soportar
un Servicio de TI necesario las 24 horas del día.
Umbral [Threshold] El valor de una Métrica que debe causar la generación de una Alerta, o
que se tome una acción de gestión. Por ejemplo, “un incidente de prioridad
1 no resuelto en 4 horas”, “más de 5 errores leves de disco en una hora”, o
“más de 10 cambios fallidos en un mes”.
Unidad de Coste [Cost Unit] (Estrategia del Servicio) la categoría de nivel más bajo al cual los Costes
son asignados, Unidad de Costes son usualmente cosas que pueden ser
contadas fácilmente (por ej. Cantidad de personas, licencias de software) o
cosas fácilmente medibles (por ej. uso de CPU, consumo de electricidad).
Unidad de Coste son incluidas dentro de los Elementos de Costes, por
ejemplo como un Elemento de Coste de “Gastos generales” puede
incluirse la Unidad de Coste de Hoteles, Transporte, Comidas etc. Ver Tipo
de Coste.
Unidad de Implementación (Transición del Servicio) Componentes de un Servicio de TI que
[Release Unit] normalmente son Implementados juntos. Una Unidad de Implementación
habitualmente incluye suficientes Componentes para realizar una Función
útil. Por ejemplo, una Unidad de Implementación podría ser un PC de
Sobremesa, incluyendo Hardware, Software, Licencias, Documentación,
etc. Una Unidad de Implementación distinta podría ser la Aplicación de
Nóminas, incluyendo los Procedimientos de Operaciones de TI y la
formación del Usuario.

Unidad de Negocio (Estrategia del Servicio) Segmento del Negocio que tiene sus propios
[Business Unit] Planes, Métricas, ingresos y Costes. Cada Unidad de Negocio posee
Activos y los usa para crear valor para sus Clientes en forma de bienes y
Servicios.
Urgencia [Urgency] (Transición del Servicio) (Diseño del Servicio) Una medida de del
tiempo en que un Incidente, Problema o Cambio tendrá un Impacto
significativo para el Negocio. Por ejemplo, un Incidente de alto Impacto
puede tener una Urgencia baja, si el Impacto no afectará al Negocio hasta
el final del año financiero. Impacto y Urgencia se emplean para asignar la
Prioridad.
Usabilidad [Usability] (Diseño del Servicio) La facilidad mediante la cual una Aplicación,
producto o Servicio de TI puede usarse. Los Requerimientos de uso se
incluyen a menudo en una Declaración de Requerimientos.
Usuario [User] Una persona que usa el Servicio de TI diariamente. Los usuarios son
distintos a los Clientes, dado que algunos Clientes no usan el Servicio de
TI directamente.
Utilidad [Utility] (Estrategia del Servicio) Funcionalidad ofrecida por un Producto o
Servicio para satisfacer una necesidad específica. La utilidad es a menudo
resumida en “lo que hace”. Ver Utilidad de Servicio.
Utilidad del Servicio [Service (Estrategia del Servicio) Funcionalidad de un Servicio de TI desde la
Utility] perspectiva del Cliente. El valor de Negocio de un Servicio de TI se crea
por la combinación de la Utilidad del Servicio (lo que el Servicio hace) y la
Garantía del Servicio (como de bien lo hace). Ver Utilidad.
Validación [Validation] (Transición del Servicio) Una Actividad que asegura que un Servicio de
TI, Proceso, Plan u otro Entregable nuevo o cambiado satisface las
necesidades del Negocio. La Validación asegura que los Requerimientos
de Negocio son satisfechos incluso aunque estos sean cambiados desde
su diseño original. Ver Verificación, Aceptación, Cualificación, Validación y
Prueba del Servicio.
Validación y Pruebas del (Transición del Servicio) Proceso responsable de la Validación y Pruebas
Servicio [Service Validation de un Servicio de TI nuevo o con Cambios. La Validación y Pruebas del
and Testing] Servicio se asegura de que un Servicio de TI cumple sus Especificaciones
de Diseño y satisface las necesidades del Negocio.
Valor Actual Neto [Net (Estrategia del Servicio) Técnica empleada para ayudar a tomar
Present Value] (NPV) decisiones sobre el Gasto de Capital. El VAN compara la entrada de
efectivo con la salida de efectivo. Un VAN positivo indica que una inversión
merece la pena. Ver Ratio Interno de Retorno, Retorno de la Inversión.
Valor en Inversión [Value on (Mejora Continua del Servicio) Una medida del beneficio esperado de
Investment] (VOI) una inversión. VOI considera tanto los beneficios financieros como
intangibles. Ver Retorno de la Inversión.
Valor por Dinero [Value for Una medida informar de la Efectividad de Costes. Valor por Dinero está a
Money] menudo basado en la comparación con el Coste de las alternativas. Ver
Análisis Coste Beneficio.
Valoración del Servicio (Estrategia del Servicio) Medición del Coste total que supone la
[Service Valuation] prestación de un Servicio de TI, y el valor total que tiene ese Servicio de TI
para el Negocio. La Valoración del Servicio se usa para facilitar el acuerdo
acerca del valor del Servicio de TI entre el Negocio y el Proveedor de
Servicios de TI.
Varianza [Variance] La diferencia entre un valor previsto y el valor real medido. Usada
comúnmente en Gestión Financiera, Gestión de la Capacidad y Gestión de
Nivel de Servicios, pero puede aplicarse en cualquier área donde se
empleen planes.
Ventana de Versión [Release Sinónimo de Ventana de Cambio.
Window]

Ventana para el Cambio (Transición del Servicio) Tiempo acordado para el cual los Cambios o
[Change Window] Entregas pueden ser implementados con un impacto mínimo sobre los
Servicios. Las Ventanas para el Cambio normalmente están documentadas
en los SLAs.
Verificación [Verification] (Transición del Servicio) Una Actividad que asegura que un Servicio de
TI, Proceso, Plan u otro Entregable nuevo o cambiado, es completo,
preciso, Confiable y está de acuerdo con su Especificación de Diseño. Ver
Validación, Aceptación, Validación y Prueba del Servicio.
Verificación y Auditoría (Transición del Servicio) Las Actividades responsables de asegurar que
[Verification and Audit] la información en la CMDB es precisa y que todos los Elementos de
Configuración está identificados y registrados en la CMDB. La Verificación
incluye comprobaciones rutinarias que son parte de otros Procesos. Por
ejemplo, verificar el número de serie de un PC cuando un Usuario registra
un Incidente. La Auditoría es una comprobación periódica y formal.
Versión [Release] (Transición del Servicio) Colección de hardware, software,

documentación, Procesos, u otros Componentes requeridos para
implementar uno o más Cambios aprobados a los Servicios de TI. Los
contenidos de cada Versión son Administrados, Probados, e
Implementados como una única entidad.
Versión [Version] (Transición del Servicio) Una Versión se usa para identificar una Límea
de Referencia específica o un Elemento de Configuración. Normalmente
emplean una convención de nombrado que posibilita identificar la
secuencia o fecha de cada Límea de Referencia. Por ejemplo Aplicación
de Nóminas Versión 3 contiene funcionalidades actualizadas de la Versión
2.
Visión [Vision] Una descripción de lo que la Organización intenta ser en el futuro. Una
Visión es creada por el Equipo Directivo y se usa para influir en la Cultura
y la Planificación Estratégica.
Vuelta a la Normalidad (Diseño del Servicio) La fase de un Plan de Continuidad de Servicio de
[Return to Normal] TI durante el cual se resumen operaciones normales completas. Por
ejemplo, si un centro de información suplente ha estado en uso, entonces
esta fase recuperará la información primaria, y restaurará la habilidad de
invocar Planes de Continuidad de Servicios de TI una vez más.
Vulnerabilidad [Vulnerability] Una debilidad que puede ser aprovechada por una Amenaza. Por ejemplo
un puerto abierto en el cortafuegos, una clave de acceso que no se
cambia, o una alfombra inflamable. También se considera una
Vulnerabilidad un Control perdido

Términos Principales según tipo en .11
Traducción castellano YA
Tipo en Termino en inglés ACORDADA Comentario
función Service Desk (SD) Centro de Servicio al Usuario (SD)
Acuerdo itSMF Junta
proceso Incident Management Gestión de Incidencias Gobierno 26-07-07
Acuerdo itSMF Junta
proceso Problem Management Gestión de Problemas Gobierno 26-07-07
proceso Configuration Management Gestión de la Configuración
Acuerdo itSMF Junta
proceso Change Management Gestión de Cambios Gobierno 26-07-07
Gestión de la Entrega (V2), pero en
proceso Release Management (V2) no existe cambia
Pendiente de
Release and Deployment comunicar a la junta
proceso Management ( ) Gestión de versiones y despliegues de gobierno
proceso Service Level Management Gestión del Nivel de Servicio
proceso Capacity Management Gestión de la Capacidad
proceso Availability Management Gestión de la Disponibilidad
TI service Continuity Gestion de la Continuidad del Servicio
proceso Management de TI
Gestión Financiera (v2) en deja de
ser proceso como tal, pero existe el
proceso TI Financial Management término
Information Security Gestión de la Seguridad de la
proceso Management Información
Supplyer Management (en ISO
proceso 20000) Gestión de Suministradores
proceso Service Reporting (ISO 20000) Informes del servicio
concepto Return on inverstment (ROI) Retorno de Inversión
actividad TI operation Operación de TI
actividad Network Management Gestión de Redes
función Technical Management Gestión Técnica
función Application Management Gestión de Aplicaciones
Métodos y
técnicas Assesment Evaluación


TERMINOS PRINCIPALES ITIL® v3 2007

Traducción castellano
Tipo en Termino en inglés propuesta Comentarios
Libro Service Strategy Estrategia del Servicio

concepto Demand Management Gestión de la Demanda
concepto Service lifecycle Ciclo de vida del Servicio
concepto Value creation Creación de Valor
concepto Service assets Activos del Servicio
concepto Proveedor de Servicios types Tipos de proveedores del Servicio
concepto Service Structures Estructuras del Servicio
concepto Service Portfolio Management Gestión de la cartera de Servicios
concepto Organizational development Desarrollo Organizativo
Uso alternativo en
textos:
Organizational "Organización en
concepto departamentalization Organización departamental departamentos"
concepto Organizational design Diseño Organizativo
concepto Organizational culture Cultura Organizativa
Estrategia de aprovisionamiento del
concepto Sourcing strategy servicio
concepto Service automation Automatización del Servicio
Libro Service Design Diseño del Servicio

proceso Service Cataloge Management Gestión del Catálogo de Servicios
actividad Requirements ingeneering Ingenieria de requisitos
Data and information
actividad management Gestión de la Información y los datos
concepto Invitation to Tender (ITT) Convocatoria de licitación (ITT)
Libro Service Transition Transición del Servicio

Transition planning and Planificación y soporte de la
proceso support Transición
Service Asset and Gestión de la Configuración y Activos
proceso Configuration Management del Servicio
Pendiente de
Release and deployment comunicar a la junta
proceso management Gestión de versiones y despliegues de gobierno
proceso Service Validation and Testing Validación y Pruebas del Servicio
proceso Evaluation Evaluación
proceso Knowledge management Gestión del Conocimiento
actividad Stakeholder management Gestión de los interesados
Libro Service Operation Operación del Servicio

process Event Management Gestión de eventos
process Request Fulfilment Gestión de peticiones
process Access Management Gestión de accesos
Operational activities of Actividades operativas de procesos
processes covered in other cubiertas por otras fases del ciclo de
process lifecycle phases vida
actividad Monitoring and control Monitorización y Control
actividad Mainframe Management Gestión del Mainframe

Traducción castellano
Tipo en Termino en inglés propuesta Comentarios
actividad Storage and archive Almacenamiento y archivo
actividad Database adminstration Administración de bases de datos
Directory services
actividad Management Gestión de Servicios de directorio
actividad Desktop Support Soporte al Puesto de Trabajo
actividad Middleware Management Gestión del Middleware
actividad Internet / web Management Gestión de Internet / Web
Facilities and Datacenter
actividad Management Gestión de instalaciones y CPD
Improvement of operational
actividad activities Mejora de las actividades operativas
función TI operation Management Gestión de la operación de TI
Continual Service
Libro Improvement Mejora Continua del Servicio
The 7-Step improvement
Proceso process El Proceso de mejora en 7 pasos
Proceso Service Measurement Medición del Servicio
Proceso Return on Invesment for CSI Retorno de la inversión para CSI
Proceso Business Questions for CSI Preguntas al negocio para CSI
Proceso Service Level Management Gestión del Nivel de Servicio
Métodos y Uso alternativo:
técnicas Benchmarking Benchmarking "Comparativa"
Métodos y Measuring and reporting Técnicas de medición ygeneración de
técnicas Frameworks informes
Métodos y
técnicas Deming cycle Ciclo de Deming
Roles Authority Matrix Matriz de Responsabilidades

ITIL® V3 Acronyms v1.0, 30 May 2007 .11

Acronym Term
ACD Automatic Call Distribution
AM Availability Management
AMIS Availability Management Information System
ASP Application Service Provider
BCM Business Capacity Management
BCM Business Continuity Management
BCP Business Continuity Plan
BIA Business Impact Analysis
BRM Business Relationship Manager
BSI British Standards Institution
BSM Business Service Management
CAB Change Advisory Board
ECAB Change Advisory Board / Emergency Committee
CAPEX Capital Expenditure
CCM Component Capacity Management
CFIA Component Failure Impact Analysis
CI Configuration Item
CMDB Configuration Management Database
CMIS Capacity Management Information System
CMM Capability Maturity Model
CMMI Capability Maturity Model Integration
CMS Configuration Management System
COTS Commercial off the Shelf
CSF Critical Success Factor
CSI Continual Service Improvement
CSIP Continual Service Improvement Programme
CSP Core Service Package
CTI Computer Telephony Integration
DIKW Data-to-Information-to-Knowledge-to-Wisdom
eSCM-CL eSourcing Capability Model for Client Organizations
eSCM-SP eSourcing Capability Model for Service Providers
FMEA Failure Modes and Effects Analysis
FTA Fault Tree Analysis
IRR Internal Rate of Return
ISG IT Steering Group
ISM Information Security Management
ISMS Information Security Management System

ISO International Organization for Standardization

ISP Internet Service Provider
IT Information Technology
ITSCM IT Service Continuity Management
ITSM IT Service Management
itSMF IT Service Management Forum
IVR Interactive Voice Response
KEDB Known Error Database
KPI Key Performance Indicator
LOS Line of Service
MoR Management of Risk
MTBF Mean Time Between Failures
MTBSI Mean Time Between Service Incidents
MTRS Mean Time to Restore Service
MTTR Mean Time to Repair
NPV Net Present Value
OGC Office of Government Commerce
OLA Operational Level Agreement
OPEX Operational Expenditure
OPSI Office of Public Sector Information
PBA Pattern of Business Activity
PFS Prerequisite for Success
PIR Post Implementation Review
PSA Projected Service Availability
QA Quality Assurance
QMS Quality Management System
RCA Root Cause Analysis
RFC Request for Change
ROI Return on Investment
RPO Recovery Point Objective
RTO Recovery Time Objective
SAC Service Acceptance Criteria
SACM Service Asset and Configuration Management
SCD Supplier and Contract Database
SCM Service Capacity Management
SFA Service Failure Analysis
SIP Service Improvement Plan
SKMS Service Knowledge Management System
SLA Service Level Agreement
SLM Service Level Management
SLP Service Level Package
SLR Service Level Requirement
SMO Service Maintenance Objective
SoC Separation of Concerns
SOP Standard Operating Procedures
SOR Statement of requirements
SPI Service Provider Interface
SPM Service Portfolio Management
SPO Service Provisioning Optimization

SPOF Single Point of Failure
TCO Total Cost of Ownership
TCU Total Cost of Utilization
TO Technical Observation
TOR Terms of Reference
TQM Total Quality Management
UC Underpinning Contract
UP User Profile
VBF Vital Business Function
VOI Value on Investment
WIP Work in Progress


Referencias
2000-Soporte del Servicio (OGC) Londres TSO
2000-Sterman, John D. 2000. Business Dynamics. Systems Thinking and Modeling for a
Complex World. McGraw-Hill.
2000-Tapscott, Don et al. 2000. Digital Capital: Harnessing the Power of Business Webs.
Harvard Business School Press.
2000-Argote 2000. Knowledge Transfer: A Basis for Competitive Advantage in Firms.
Organizational Behaviour and Human Decision Processes. Vol. 82, No. 1, May, 150–169.
2001- Provisión del Servicio (OGC) Londres TSO
2001-Camazine, S. et al. 2001. Self-Organization in Biological Systems. Princeton University
Press.
2001-Lev, B. 2001. Intangibles: Management, Measurement, and Reporting. The Brookings
Institution.
2001-Repenning, Nelson P. and Sterman, John D. 2001a. Nobody Ever Gets Credit for Fixing
Problems that Never Happened: Creating and Sustaining Process Improvement. California
Management Review. Vol. 43, No. 4, Summer 2001.
2001-Repenning, Nelson P. et al. 2001b. Past the Tipping Point: The Persistence of
Firefighting in Product Development. California Management Review. Vol. 43, No. 4,
Summer 2001.
2002-Edmondson and Frei 2002. Transformation at the IRS. Harvard Business School.
2002-Magretta, Joan 2002. What Management Is: How TI works and why TI’s everyone’s
business. The Free Press.
2002-Moorecroft, John et al. 2002. Systems Perspective on Resources, Capabilities, and
Management Processes. Elsevier Science.
2002-Goold, Michael and Campbell, Andrew 2002. Designing Effective Organizations: How
to create structured networks. Jossey-Bass.
2002-Nagle, T.N. and Holden, R.K. 2002. Strategy and tactics of pricing: A guide to profitable
decision-making. 3rd Edition. Prentice-Hall.
2003-NAE (National Academy of Engineering) 2003. The Impact of Academic Research on
Industrial Performance. The National Academies Press.
2003-Malone, T.W. et al. (eds) 2003. Organizing Business Knowledge: The MIT Process
Handbook.
2003-12 Lidwell, W., Holden, K. and Butler, J. 2003. Universal Principles of Design. Rockport
Publishers.
2003-Allee, Verna 2003. The Future of Knowledge: Increasing Prosperity through value
networks. Butterworth-Heinemann.

2004-Froehle, C. and Roth, A.V. 2004. New measurement scales for evaluating perceptions
of the technology-mediated customer service experience. Journal of Operations
Management, 22 (1)
2004-Rayport, J.F. and Jaworski, B.J. 2004. Best Face Forward. Harvard Business Review.
December 2004.
2004-Bryson, J.R., Daniels, P.W. and Warf, B. 2004. Service Worlds: People, Organisations,
Technologies. Routledge.
2004-Lovelock, Christopher and Gummesson, Evert 2004. Whither Services Marketing? In
Search of A New Paradigm and Fresh Perspectives. Journal of Service Research, 7 (August)
2005-ITGI 2005. COBIT 4.0: Control Objectives, Management Guidelines, and Maturity
Models. TI Governance Institute.
2005-Seely Brown, John and John, Hagel III 2005. Innovation Blowback: Disruptive
Management Practices from Asia. The McKinsey Quarterly, No. 1.
2005-McNeillis, Paul 2005. ITNOW 2005 47(6): 14–15; British Computer Society.
doi:10.1093/itnow/bwi114
2005-Breene, T., Mulani, N.P., Nunes, P.F. 2005. Marks of distinction. Outlook Journal
2005-Gratton, Lynda and Ghoshal, Sumantra 2005. Beyond Best Practice. MIT Sloan
Management Review. Spring 2005. Vol. 46, No. 3.
2005-Ulwick, Anthony 2005. What Customers Want: Using Outcome-Driven Innovation to
Create Breakthrough Products and Services. McGraw-Hill.
2005-Kim, W. Chan and Mauborgne, Renée 2005. Blue Ocean Strategy: How to Create
Uncontested Market Space and Make Competition Irrelevant. Harvard Business School
Press.
2007-43 OGC (Office of Government Commerce) 2007. Management of Risk: Guidance for
Practitioners. The Stationery Office.
2007-Mejora Continua del Servicio (OGC) Londres TSO
2007-Diseño del servicio (OGC) Londres TSO
2007-Transición del servicio (OGC) Londres TSO
2007-Estrategia del Servicio (OGC) Londres TSO
2007- Operción del Servicio (OGC) Londres TSO
2008 – Fundamentos de la Gestión de Servicios de TI basada en ITIL® por Tieneke
Verheijen, Annelies van der Veen, Ruby Tjassing, Mike Pieper, Axel Kolthof, Arjen de Jong,
Jan van Bon (Van Haren Publishing)
2010 – Guía de Fundamentos ITSM basada en ITIL® por Ernesto Vilches (Editorial Luarna)

Lecturas recomendadas
Burner, Mike 2004. Service Orientation and Its Role in Your Connected Systems
Strategy. Microsoft Corporation. July 2004. MSDN. URL: http://msdn2.microsoft.com/en-
us/library/ms954826.aspx
Carr, Nicholas 2005. The End of Corporate Computing. MIT Sloan Management
Review. Spring 2005, Vol. 46, No. 3, 67–73.
Cherbakov et al. 2005. Impact of service orientation at the business level. IBM
Systems Journal, Vol. 44, No. 4.
Grant, Robert M. 1991. The Resource-Based Theory of Competitive Advantage:

Implications for Strategy Formulation. California Management Review, Vol. 33, No. 3.
Grönroos, Christian 2001. Service management and Marketing: A Customer

Relationship Management Approach. John Wiley and Sons.
Iravani, S.M. et al. 2005. Structural Flexibility: A New Perspective on the Design of
Manufacturing and Service Operations. Management Science, Vol. 51, No. 2, February 2005,
151–166.
ITSqc, 2004. ITSqc Global Strategic Service Management Symposium. [ITSqc Working
Paper CMU-ITSQC-WP-04-001a]. Carnegie Mellon University, Pittsburgh, PA, USA.
Jones, Gareth R. 2007. Organizational Theory, Design and Change. Pearson Prentiss
Hall.
Luftman, Jerry and Brier, Tom 1999. Achieving and Sustaining Business–TI Alignment.
California Management Review. Vol. 42, No. 1. Fall 1999.

Guia - Fundamentos - ITIL 2011 - Andres PDF

Cargado por

Información del documento

Título original

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

Guia - Fundamentos - ITIL 2011 - Andres PDF

Cargado por

Copyright:

Formatos disponibles

Guía de Fundamentos ITSM basada en ITIL®

Fundamentos de ITSM basados en

Ernesto Vilches ITIL® is a trade mark registered of Cabinet Office 1

Ernesto Vilches ITIL® is a trade mark registered of Cabinet Office 2

1. Advertencia Legal .................................................................................. 17

3.5.2. Ciclo de creación de valor ........................................................................................... 60

3.9.3. Valor ............................................................................................................................ 92

4.4. El Diseño de Soluciones del Servicio................................................................ 122

4.18.8. Actividades Iterativas ................................................................................................ 172

4.21.4. Valor .......................................................................................................................... 202

5.1.8. Salidas....................................................................................................................... 228

5.5.14.2. Salidas: ....................................................................................................................... 257

5.9.1. Ámbito ....................................................................................................................... 285

6.3.8. Entradas .................................................................................................................... 309

6.6.13.3. Transición del Servicio .................................................................................................. 331

6.12.3. Actividades ................................................................................................................ 351

7.1.21. Cuadro Integral de Mando (Balanced Scorecard) .................................................... 380

Ernesto Vilches ITIL® is a trade mark registered of Cabinet Office 15

Ernesto Vilches ITIL® is a trade mark registered of Cabinet Office 16

El autor prohíbe cualquier tipo de fijación, transformación, reproducción, reproducción en

El almacenamiento o archivo de esta obra en un ordenador diferente al inicial en este acto

La protección de esta obra se extiende al universo de acuerdo a las Leyes y Convenios

©Ernesto Vilches Egea

Ernesto Vilches ITIL® is a trade mark registered of Cabinet Office 17

Ernesto Vilches ITIL® is a trade mark registered of Cabinet Office 18

Gestión de Servicios y su Ciclo de Vida .2

ITIL v3 > 2011

Cada uno de los dos volúmenes de ITIL® V2 describen los 10 procesos en

Service Delivery – Tactical

 Gestión de Nivel de Servicio

Service Support – Operational

 Gestión del Incidente

Ernesto Vilches ITIL® is a trade mark registered of Cabinet Office 19

Ernesto Vilches ITIL® is a trade mark registered of Cabinet Office 20

2.2. ITIL ® y los Modelos de Gestión de TI

De otra manera, la “Gestión de Servicios TI (ITSM) es la alineación sistemática a la planificación,

Ernesto Vilches ITIL® is a trade mark registered of Cabinet Office 21

ASL (Application Service Library)

MSP (Managerial Step-by-Step Plan)

2.2.1. Otros Fabricantes

Ernesto Vilches ITIL® is a trade mark registered of Cabinet Office 23

2.2.2. Otros Sistemas de Gestión

Ernesto Vilches ITIL® is a trade mark registered of Cabinet Office 24

2.2.3. Gestión de Servicios TI

2.2.3.1. Los retos de la organización

Esto y la dependencia creciente llevan a necesidades crecientes para servicios de TI de calidad,

2.2.3.2. ¿Cuáles son las Necesidades de los clientes?

Quieren Conformidad a la especificación:

Ernesto Vilches ITIL® is a trade mark registered of Cabinet Office 25

Quieren Valor por su dinero:

2.2.3.4. Necesitamos el Compromiso de la Dirección

2.2.3.5. ¿Por qué falla la implementación?

Ernesto Vilches ITIL® is a trade mark registered of Cabinet Office 26

También influye en los fallos:

Carencia de compromiso y entendimiento de la plantilla

En muchas organizaciones de TI no existe un mecanismo de Soporte al Cliente estructurado. Puede

Ernesto Vilches ITIL® is a trade mark registered of Cabinet Office 27

En el de tema de Personal, también tenemos que hablar.

En primer lugar, sobre dependemos de empleados clave porque no documentamos los

2.2.3.7. Qué espera el Cliente

2.2.3.8. ¿Por qué implementar Gestión de Servicios?

2.2.3.9. Gestión de Servicio

Ernesto Vilches ITIL® is a trade mark registered of Cabinet Office 28