Servicio ITIL - 2022

7/3/2021 Operación del servicio ITIL versión 3
Página 1
ITIL versión 3
Operación de servicio
https://translate.googleusercontent.com/translate_f 1/381
ITIL V3 - Operación de servicio - Página: 1 de 396
Página 2
El ITIL Core consta de cinco publicaciones. Cada uno proporciona

la orientación necesaria para un enfoque integrado, como
requerido por la especificación estándar ISO / IEC 20000 :
• Estrategia de servicio
• Diseño de servicio
• Transición de servicio
• Operación de servicio
• Mejora continua del servicio .
Página 3
ÍNDICE
Prefacio................................................. .................................................. .......... 12
Prólogo de OGC ................................................ .................................................. .......... 12
Prólogo del arquitecto jefe ............................................... .............................................. 13
Prefacio ................................................. .................................................. ............ 14
Información del contacto................................................ .................................................. ..... 14
Agradecimientos................................................. ............................................15
Arquitecto jefe y autores .............................................. ............................................ 15
Equipo de creación de ITIL ............................................... .................................................. ...... 15
Mentores ................................................. .................................................. ...................... 15
Contribuciones adicionales ................................................ .................................................. ... 15
El Grupo Asesor de ITIL .............................................. .................................................. .. dieciséis
Revisores ................................................. .................................................. ...................... dieciséis
1. Introducción ................................................ .................................................. .... 17
1.1 Resumen ................................................ .................................................. ............... 18
1.2 Contexto ................................................ .................................................. .................. 19
1.2.1 Gestión de servicios ............................................. .................................................. 19
1.2.2 Buenas prácticas en el dominio público ......................................... ................................ 19
1.2.3 ITIL y buenas prácticas en la gestión de servicios ........................................ .............. 21
1.2.3.1 Estrategia de servicio ............................................. .................................................. ............... 22
1.2.3.2 Diseño del servicio ............................................. .................................................. ................. 23
1.2.3.3 Transición del servicio ............................................. .................................................. ............ 23
1.2.3.4 Operación del servicio ............................................. .................................................. ............ 24
1.2.3.5 Mejora continua del servicio ............................................ .......................................... 24
1.3 Propósito ................................................ .................................................. ................. 26
1.4 Uso ................................................ .................................................. .................... 26
1.5 Resumen del capítulo ............................................... .................................................. ... 27
2 Gestión de servicios como práctica ............................................ ...................... 28
2.1 ¿Qué es la gestión de servicios? .................................................. ............................ 28
2.2 ¿Qué son los servicios? .................................................. ............................................... 30
2.2.1 La propuesta de valor ............................................ .................................................. 30
2.3 Funciones y procesos a lo largo del ciclo de vida ........................................... ............. 31
2.3.1 Funciones .............................................. .................................................. ................. 31
2.3.2 Procesos .............................................. .................................................. ................ 31
2.3.3 Especialización y coordinación a lo largo del ciclo de vida ......................................... ...... 32
2.4 Fundamentos de la operación del servicio .............................................. .............................. 33
2.4.1 Propósito / meta / objetivo .......................................... .................................................. 33
2.4.2 Alcance .............................................. .................................................. ....................... 33
2.4.3 Valor para el negocio ............................................ .................................................. ...... 34
2.4.4 Optimización del rendimiento de la operación del servicio ........................................... ................. 35
2.4.5 Procesos dentro de la operación del servicio ........................................... ............................. 35
2.4.5.1 Gestión de eventos ............................................. .................................................. .......... 35
2.4.5.2 Gestión de incidentes y problemas ........................................... ..................................... 35
2.4.5.3 Cumplimiento de la solicitud ............................................. .................................................. ........... 36
2.4.5.4 Gestión de acceso ............................................. .................................................. ....... 36
2.4.6 Funciones dentro de la operación del servicio ........................................... .............................. 36
2.4.6.1 Mesa de servicio ............................................. .................................................. .................... 36
2.4.6.2 Gestión técnica ............................................. .................................................. .... 36
2.4.6.3 Gestión de operaciones de TI ............................................ ................................................ 37
2.4.6.4 Gestión de aplicaciones ............................................. .................................................. ..37
2.4.6.5 Interfaces con otras etapas del ciclo de vida de la gestión de servicios ........................................ ...... 37
Página 4
3 Principios de funcionamiento del servicio .............................................. .............................. 39

3.1 Funciones, grupos, equipos, departamentos y divisiones ........................................ ... 40
3.2 Lograr el equilibrio en la operación del servicio ............................................ .................... 42
3.2.1 Vista de TI interna versus vista de negocio externa ........................................ ............... 42
3.2.2 Estabilidad versus capacidad de respuesta ............................................ .................................. 45
3.2.3 Calidad de servicio versus costo de servicio ........................................ ......................... 48
3.2.4 Reactivo versus proactivo ............................................ ........................................... 51
3.3 Prestación de servicio ............................................... .................................................. ... 56
3.4 Participación del personal de operaciones en el diseño del servicio y la transición del servicio ... 57
3.5 Salud operativa ............................................... .................................................. .58
3.6 Comunicación ................................................ .................................................. ..... 60
3.6.1 Reuniones .............................................. .................................................. .................. 61
3.6.1.1 La reunión de operaciones ............................................ .................................................. .... 62
3.6.1.2 Reuniones de departamento, grupo o equipo ......................................... .................................... 63
3.6.1.3 Reuniones de clientes ............................................. .................................................. .......... 63
3.7 Documentación ................................................ .................................................. ...... 64
4 Procesos de operación del servicio .............................................. .............................sesenta y cinco
4.1 Gestión de eventos ............................................... .................................................. 67
4.1.2 Alcance .............................................. .................................................. ....................... 67
4.1.4 Políticas / principios / conceptos básicos ......................................... .................................. 69
4.1.5 Actividades, métodos y técnicas del proceso ......................................... .................. 70
4.1.5.1 El evento ocurre ............................................. .................................................. .................... 71
4.1.5.2 Notificación de eventos ............................................. .................................................. .............. 71
4.1.5.3 Detección de eventos ............................................. .................................................. ................ 72
4.1.5.4 Filtrado de eventos ............................................. .................................................. ................... 72
4.1.5.5 Importancia de los eventos ............................................ .................................................. ....... 72
4.1.5.6 Correlación de eventos ............................................. .................................................. .............. 74
4.1.5.7 Disparador .............................................. .................................................. ............................. 74
4.1.5.8 Selección de respuesta ............................................. .................................................. .......... 75
4.1.5.9 Acciones de revisión ............................................. .................................................. ................. 78
4.1.5.10 Cerrar evento ............................................. .................................................. .................... 78
4.1.6 Disparadores, interfaces de entrada y salida / entre procesos ..................................... ............ 79
4.1.7 Gestión de la información ............................................. ............................................ 80
4.1.8 Métricas .............................................. .................................................. ..................... 80
4.1.9 Desafíos, factores críticos de éxito y riesgos ........................................ .............. 81
4.1.9.1 Desafíos .............................................. .................................................. ...................... 81
4.1.9.2 Factores críticos de éxito ............................................ .................................................. .... 81
4.1.9.3 Riesgos .............................................. .................................................. ............................... 82
4.1.10 Diseño para la gestión de eventos ........................................... .............................. 82
4.1.10.1 Instrumentación .............................................. .................................................. ............. 83
4.1.10.2 Mensajes de error ............................................. .................................................. ............. 83
4.1.10.3 Mecanismos de alerta y detección de eventos .......................................... .............................. 84
4.1.10.4 Identificación de umbrales ............................................ ................................................ 84
4.2 Gestión de incidentes ............................................... .............................................. 86
4.2.2 Alcance .............................................. .................................................. ....................... 86
4.2.4 Políticas / principios / conceptos básicos ......................................... .................................. 87
4.2.4.1 Escalas de tiempo .............................................. .................................................. ...................... 87
4.2.4.2 Modelos de incidentes ............................................. .................................................. ................ 87
4.2.4.3 Incidentes mayores ............................................. .................................................. ................. 88
4.2.5 Actividades, métodos y técnicas del proceso ......................................... .................. 89
4.2.5.1 Identificación de incidentes ............................................. .................................................. ....... 90
4.2.5.2 Registro de incidentes ............................................. .................................................. ................ 91
4.2.5.3 Categorización de incidentes ............................................. .................................................. ..... 92
Página 5
4.2.5.4 Priorización de incidentes ............................................. .................................................. ........ 94

4.2.5.5 Diagnóstico inicial ............................................. .................................................. ................ 96
4.2.5.6 Escalamiento de incidentes ............................................. .................................................. ........... 96
Nota sobre la asignación de incidentes .............................................. .................................................. ............ 97
4.2.5.7 Investigación y diagnóstico ............................................ ................................................ 97

4.2.5.8 Resolución y recuperación ............................................ .................................................. ..98
4.2.5.9 Cierre de incidentes ............................................. .................................................. ............... 99
Reglas para reapertura de incidentes ............................................ ............................................ 100
4.2.6 Disparadores, interfaces de entrada y salida / entre procesos ..................................... .......... 100
4.2.7 Gestión de la información ............................................. .......................................... 101
4.2.8 Métricas .............................................. .................................................. ................... 102
4.2.9 Desafíos, factores críticos de éxito y riesgos ........................................ ............ 103
4.2.9.1 Desafíos .............................................. .................................................. .................... 103
4.2.9.2 Factores críticos de éxito ............................................ .................................................. ..103
4.2.9.3 Riesgos .............................................. .................................................. ............................. 103
4.3 Cumplimiento de la solicitud ............................................... ................................................. 105
4.3.1 Propósito / meta / objetivo .......................................... ................................................ 105
4.3.2 Alcance .............................................. .................................................. ..................... 105
4.3.3 Valor para el negocio ............................................ .................................................. .... 106
4.3.4 Políticas / principios / conceptos básicos ......................................... ................................ 106
4.3.4.1 Solicitar modelos ............................................. .................................................. ............. 106
4.3.5 Actividades, métodos y técnicas del proceso ......................................... ................ 106
4.3.5.1 Selección de menú ............................................. .................................................. ............... 106
4.3.5.2 Aprobación financiera ............................................. .................................................. .......... 107
4.3.5.3 Otra aprobación ............................................. .................................................. ............... 107
4.3.5.4 Cumplimiento .............................................. .................................................. ...................... 107
4.3.5.5 Cierre .............................................. .................................................. .......................... 108
4.3.8 Métricas .............................................. .................................................. ................... 109
4.3.9.1 Desafíos .............................................. .................................................. .................... 109
4.3.9.2 Factores críticos de éxito ............................................ .................................................. ..109
4.3.9.3 Riesgos .............................................. .................................................. ............................. 110
4.4 Gestión de problemas ............................................... ........................................... 111
4.4.2 Alcance .............................................. .................................................. ..................... 111
4.4.4.1 Modelos de problemas ............................................. .................................................. ............. 112
4.4.5.1 Detección de problemas ............................................. .................................................. .......... 113
4.4.5.2 Registro de problemas ............................................. .................................................. ............. 114
4.4.5.3 Categorización de problemas ............................................. .................................................. ..115
4.4.5.4 Priorización de problemas ............................................. .................................................. ..... 115
4.4.5.5 Investigación y diagnóstico de problemas ........................................... ................................. 115
4.4.5.6 Soluciones provisionales .............................................. .................................................. ................. 119
4.4.5.7 Generación de un registro de errores conocidos .......................................... ............................................ 119
4.4.5.8 Resolución de problemas ............................................. .................................................. ......... 119
4.4.5.9 Cierre del problema ............................................. .................................................. ............ 120
4.4.5.10 Revisión de problemas importantes ............................................ .................................................. ..120
4.4.5.11 Errores detectados en el entorno de desarrollo ......................................... ............... 120
4.4.7.1 CMS .............................................. .................................................. .............................. 122
4.4.7.2 Base de datos de errores conocidos ............................................ .................................................. .... 123
4.4.8 Métricas .............................................. .................................................. ................... 124
4.5 Gestión de acceso ............................................... ............................................. 126
Página 6

4.5.2 Alcance .............................................. .................................................. ..................... 126
4.5.5.1 Solicitar acceso ............................................. .................................................. ......... 127
4.5.5.2 Verificación .............................................. .................................................. .................... 127
4.5.5.3 Proporcionar derechos ............................................. .................................................. .............. 128
4.5.5.4 Supervisión del estado de la identidad ............................................ .................................................. 129
4.5.5.5 Acceso a registro y seguimiento ........................................... .............................................. 130
4.5.5.6 Eliminación o restricción de derechos ........................................... ............................................ 130
4.5.7.1 Identidad .............................................. .................................................. .......................... 132
4.5.7.2 Usuarios, grupos, roles y grupos de servicios ....................................... ................................ 133
4.5.8 Métricas .............................................. .................................................. ................... 134
4.6 Actividades operativas de los procesos cubiertos en otras fases del ciclo de vida ......... 136
4.6.1 Gestión de cambios ............................................. ............................................... 136
4.6.2 Gestión de la configuración ............................................. ...................................... 136
4.6.3 Gestión de versiones y despliegues ........................................... ..................... 137
4.6.4 Gestión de capacidad ............................................. .............................................. 137
4.6.4.1 Monitoreo de la capacidad y el desempeño ........................................... ............................... 137
4.6.4.2 Manejo de incidentes relacionados con la capacidad o el desempeño ....................................... ............. 139
4.6.4.3 Tendencias de capacidad y rendimiento ........................................... ...................................... 139
4.6.4.4 Almacenamiento de datos de gestión de capacidad .......................................... ............................... 140
4.6.4.5 Gestión de la demanda ............................................. .................................................. ... 140
4.6.4.6 Gestión de la carga de trabajo ............................................. .................................................. ..140
4.6.4.7 Modelado y dimensionamiento de aplicaciones ........................................... ....................................... 141
4.6.4.8 Planificación de la capacidad ............................................. .................................................. .......... 141
4.6.5 Gestión de disponibilidad ............................................. ........................................... 142
4.6.6 Gestión del conocimiento ............................................. .......................................... 144
4.6.7 Gestión financiera para servicios de TI .......................................... ........................ 144
4.6.8 Gestión de la continuidad del servicio de TI ........................................... ............................ 144
5 Actividades de operación de servicio común ............................................. ............... 146
5.1 Seguimiento y control .............................................. ............................................ 149
5.1.1 Definiciones .............................................. .................................................. .............. 149
5.1.2 Monitorear lazos de control ............................................ ............................................... 150
5.1.2.1 Lazo de control de monitor complejo ........................................... .......................................... 152
5.1.2.2 Lazo de control del monitor ITSM .......................................... .......................................... 154
5.1.2.3 Definición de lo que se debe monitorear ......................................... ................................... 156
5.1.2.4 Monitoreo y control interno y externo ......................................... ....................... 157
5.1.2.5 Definición de objetivos de seguimiento y control ......................................... ..................... 157
5.1.2.6 Tipos de seguimiento ............................................ .................................................. ........ 159
5.1.2.7 Monitoreo en entornos de prueba ........................................... ........................................ 161
5.1.2.8 Notificación y acción ............................................ .................................................. ....... 162
5.1.2.9 Auditorías de operación del servicio ............................................ .................................................. .162
5.1.2.10 Medición, métricas y KPI .......................................... ....................................... 163
Medida ................................................. .................................................. ....................................... 163
Métricas ................................................. .................................................. ................................................. 164
Indicadores clave de rendimiento ............................................... .................................................. .................. 164
5.1.2.11 Interfaces con otras prácticas del ciclo de vida del servicio ......................................... ................... 164
Monitoreo operativo y mejora continua del servicio ......................................... 164
5.2 Operaciones de TI ............................................... .................................................. ....... 166
5.2.1 Gestión de consola / Puente de operaciones .......................................... ................... 166
5.2.2 Programación de trabajos ............................................. .................................................. ....... 167
5.2.3 Copia de seguridad y restauración ............................................ .................................................. 168
5.2.3.1 Copia de seguridad .............................................. .................................................. .......................... 169
Página 7
5.2.3.2 Restaurar .............................................. .................................................. ......................... 170

5.2.4 Impresión y salida ............................................ .................................................. ...... 171
5.3 Gestión de mainframe ............................................... ........................................ 172
5.4 Gestión y soporte del servidor ............................................. ........................... 173
5.5 Gestión de red ............................................... ............................................ 175
5.6 Almacenamiento y archivo .............................................. ............................................... 177
5.7 Administración de la base de datos ............................................... ....................................... 179
5.8 Gestión de servicios de directorio .............................................. ............................ 180
5.9 Soporte de escritorio ............................................... .................................................. .. 181
5.10 Gestión de middleware ............................................... .................................... 182
5.11 Administración de Internet / Web ............................................. .................................... 184
5.12 Gestión de instalaciones y centros de datos ............................................ ................ 185
5.12.1 Estrategias del centro de datos ............................................ ............................................. 186
5.13 Gestión de la seguridad de la información y funcionamiento del servicio ... 188
5.13.1 Vigilancia y denuncia ............................................ .............................................. 188
5.13.2 Asistencia técnica ............................................. .............................................. 188
5.13.3 Control de seguridad operacional ............................................ ..................................... 189
5.13.4 Detección e investigación de antecedentes ............................................ .............................................. 189
5.13.5 Formación y sensibilización ............................................ .......................................... 189
5.13.6 Políticas y procedimientos documentados ........................................... ...................... 190
5.14 Mejora de las actividades operativas ............................................. .................... 191
5.14.1 Automatización de tareas manuales ........................................... ..................................... 191
5.14.2 Revisión de actividades o procedimientos improvisados .......................................... ........... 191
5.14.3 Auditorías operativas ............................................. .................................................. 191
5.14.4 Uso de la gestión de incidentes y problemas .......................................... ................ 191
5.14.5 Comunicación .............................................. .................................................. .... 191
5.14.6 Educación y formación ............................................ ............................................. 192
6 Organización para la operación del servicio ............................................. ...................... 193
6.1 Funciones ................................................ .................................................. ............ 193
6.1.1 Funciones y actividades ............................................ ............................................. 195
6.2 Mesa de servicio ............................................... .................................................. ........ 198
6.2.1 Justificación y rol del Service Desk ........................................ ..................... 198
6.2.2 Objetivos de la mesa de servicio ............................................ ............................................ 199
6.2.3 Estructura organizativa de la mesa de servicio ........................................... ........................ 200
6.2.3.1 Mesa de servicio local ............................................ .................................................. ......... 200
6.2.3.2 Mesa de servicio centralizada ............................................ .................................................. 201
6.2.3.3 Mesa de servicio virtual ............................................ .................................................. ........ 202
6.2.3.4 Siga el sol ............................................ .................................................. ................ 203
6.2.3.5 Grupos de Service Desk especializados ........................................... ....................................... 203
6.2.3.6 Medio ambiente .............................................. .................................................. .................. 204
6.2.3.7 Nota sobre la creación de un único punto de contacto ....................................... ............................... 204
6.2.4 Dotación de personal de la mesa de servicio ............................................ ................................................. 205
6.2.4.1 Niveles de personal ............................................. .................................................. ................. 205
6.2.4.2 Niveles de habilidad ............................................. .................................................. ...................... 207
6.2.4.3 Entrenamiento .............................................. .................................................. ......................... 209
6.2.4.4 Retención del personal ............................................. .................................................. ................. 210
6.2.4.5 Superusuarios ............................................. .................................................. ................... 210
6.2.5 Métricas de la mesa de servicio ............................................ ................................................. 211
6.2.5.1 Encuestas de satisfacción de clientes / usuarios .......................................... .................................... 213
6.2.6 Subcontratación del Service Desk ........................................... .................................... 215
6.2.6.1 Herramientas y procesos comunes ........................................... ............................................ 216
6.2.6.2 Objetivos de SLA ............................................. .................................................. .................... 217
6.2.6.3 Buenas comunicaciones ............................................. .................................................. ... 217
6.2.6.4 Propiedad de los datos ............................................ .................................................. ........... 218
6.3 Gestión técnica ............................................... ......................................... 219
6.3.1 Rol de Gerencia Técnica ............................................ ...................................... 219
Página 8
6.3.2 Objetivos de la gestión técnica ............................................ ............................ 220
6.3.3
6.3.4 Actividades
Organizacióngenéricas
de gestióndetécnica
gestión............................................
técnica ........................................... ..................
........................ 222 220
6.3.5 Diseño técnico y mantenimiento y soporte técnico ................................. 223
6.3.6 Métricas de gestión técnica ............................................ ................................ 224
6.3.7 Documentación de gestión técnica ............................................ .................... 225
6.3.7.1 Documentación técnica ............................................. ................................................. 225
6.3.7.2 Programas de mantenimiento ............................................. .................................................. .226
6.3.7.3 Inventario de habilidades ............................................. .................................................. ............... 226
6.4 Gestión de operaciones de TI .............................................. .................................... 227
6.4.1 Función de gestión de operaciones de TI ........................................... ................................. 227
6.4.2 Objetivos de la gestión de operaciones de TI ........................................... ....................... 229
6.4.3 Organización de gestión de operaciones de TI ........................................... ................... 229
6.4.4 Métricas de gestión de operaciones de TI ........................................... ........................... 230
6.4.5 Documentación de gestión de operaciones de TI ........................................... ............... 231
6.4.5.1 Procedimientos operativos estándar ............................................ ....................................... 231
6.4.5.2 Registros de operaciones ............................................. .................................................. ............. 231
6.4.5.3 Informes y horarios de turnos ........................................... .............................................. 232
6.4.5.4 Programa de operaciones ............................................. .................................................. ..... 232
6.5 Gestión de aplicaciones ............................................... ....................................... 233
6.5.1 Función de gestión de aplicaciones ............................................ .................................... 233
6.5.2 Objetivos de la gestión de aplicaciones ............................................ .......................... 234
6.5.3 Principios de gestión de aplicaciones ............................................ ........................... 234
6.5.3.1 ¿Construir o comprar? .................................................. .................................................. ............. 234
6.5.3.2 Modelos operativos ............................................. .................................................. ........ 235
6.5.4 Ciclo de vida de la gestión de aplicaciones ............................................ ............................ 235
6.5.4.1 Requisitos .............................................. .................................................. ................ 238
6.5.4.2 Diseño .............................................. .................................................. ........................... 239
6.5.4.3 Construir .............................................. .................................................. .............................. 239
6.5.4.4 Implementar .............................................. .................................................. ........................... 240
6.5.4.5 Operar .............................................. .................................................. ......................... 240
6.5.4.6 Optimizar .............................................. .................................................. ........................ 241
6.5.5 Actividades genéricas de gestión de aplicaciones ........................................... ................ 241
6.5.6 Organización de gestión de aplicaciones ............................................ ...................... 244
6.5.6.1 Roles organizacionales ............................................. .................................................. ....... 246
6.5.7 Funciones y responsabilidades de la gestión de aplicaciones .......................................... .... 248
6.5.7.1 Responsables de aplicaciones / jefes de equipo ......................................... .................................. 248
6.5.7.2 Analista / Arquitecto de Aplicaciones ........................................... ............................................ 249
6.5.8 Métricas de gestión de aplicaciones ............................................ .............................. 250
6.5.9 Documentación de gestión de aplicaciones ............................................ .................. 251
6.5.9.1 Portafolio de aplicaciones ............................................. .................................................. ....... 251
6.5.9.2 Requisitos de la aplicación ............................................. ................................................ 252
6.5.9.3 Casos de uso y cambio ........................................... .................................................. ... 253
6.5.9.4 Documentación de diseño ............................................. .................................................. ... 254
6.5.9.5 Manuales .............................................. .................................................. ........................ 254
6.6 Funciones y responsabilidades de la operación del servicio ............................................ ............ 256
6.6.1 Roles del Service Desk ............................................ .................................................. ... 256
6.6.1.1 Administrador de la mesa de servicio ............................................ .................................................. .... 256
6.6.1.2 Supervisor de la mesa de servicio ............................................ .................................................. .256
6.6.1.3 Analistas de Service Desk ............................................ .................................................. .... 257
6.6.1.4 Superusuarios ............................................. .................................................. ................... 257
6.6.2 Roles de gestión técnica ............................................ .................................... 257
6.6.2.1 Responsables técnicos / jefes de equipo ......................................... ...................................... 257
6.6.2.2 Analistas técnicos / arquitectos ........................................... ............................................ 258
6.6.2.3 Operador técnico ............................................. .................................................. ........ 258
6.6.3 Roles de gestión de operaciones de TI ........................................... ............................... 259
6.6.3.1 Gerente de Operaciones de TI ............................................ .................................................. ... 259
6.6.3.2 Líderes de turno ............................................. .................................................. .................. 259
6.6.3.3 Analistas de operaciones de TI ............................................ .................................................. .... 260
Página 9
6.6.3.4 Operadores de TI ............................................. .................................................. ................... 260

6.6.4 Roles de gestión de aplicaciones ............................................ .................................. 260
6.6.4.1 Responsables de aplicaciones / jefes de equipo ......................................... .................................. 260
6.6.4.2 Analista / Arquitecto de Aplicaciones ........................................... ............................................ 261
6.6.5 Roles de gestión de eventos ............................................ ........................................... 262
6.6.5.1 El rol del Service Desk ......................................... ................................................ 262
6.6.5.2 El papel de la gestión técnica y de aplicaciones ........................................ ............. 262
6.6.5.3 El papel de la gestión de operaciones de TI ......................................... ............................... 262
6.6.6 Roles de gestión de incidentes ............................................ ....................................... 263
6.6.6.1 Administrador de incidentes ............................................. .................................................. ........... 263
6.6.6.2 Primera línea ............................................. .................................................. ......................... 263
6.6.6.3 Segunda línea ............................................. .................................................. .................... 263
6.6.6.4 Tercera línea ............................................. .................................................. ........................ 264
6.6.7 Solicitar roles de cumplimiento ............................................ ............................................ 264
6.6.8 Roles de gestión de problemas ............................................ ...................................... 265
6.6.8.1 Gestor de problemas ............................................. .................................................. .......... 265
6.6.8.2 Grupos de resolución de problemas ........................................... .................................................. ..265
6.6.9 Roles de gestión de acceso ............................................ ........................................ 266
6.6.9.1 El rol del Service Desk ......................................... ................................................ 266
6.6.9.2 El papel de la gestión técnica y de aplicaciones ........................................ ............. 266
6.6.9.3 El papel de la gestión de operaciones de TI ......................................... ............................... 267
6.7 Estructuras de organización de operaciones de servicio ............................................. ............. 268
6.7.1 Organización por especialización técnica ........................................... .................... 268
6.7.2 Organización por actividad ............................................ ............................................. 270
6.7.3 Organización para gestionar procesos ........................................... ............................... 272
6.7.4 Organización de las operaciones de TI por geografía .......................................... ..................... 273
6.7.5 Estructuras organizativas híbridas ............................................ ................................... 275
6.7.5.1 Funciones combinadas ............................................. .................................................. ....... 276
6.7.5.2 Organización de la aplicación y la gestión técnica .......................................... ........... 278
6.7.5.3 Geografía .............................................. .................................................. .................... 278
6.7.5.4 Estructura combinada de gestión técnica y de aplicaciones ....................................... 279
7 Consideraciones tecnológicas ............................................... ............................. 281
7.1 Requisitos genéricos ............................................... ............................................ 282
7.1.1 Autoayuda ............................................ .................................................. .................. 282
7.1.2 Flujo de trabajo o motor de proceso ........................................... ....................................... 282
7.1.3 CMS integrado ............................................. .................................................. ...... 282
7.1.4 Tecnología de descubrimiento / implementación / licencias ......................................... .............. 282
7.1.5 Mando a distancia ............................................. .................................................. ....... 283
7.1.6 Utilidades de diagnóstico ............................................. .................................................. ... 283
7.1.7 Informes .............................................. .................................................. ............... 283
7.1.8 Cuadros de mando .............................................. .................................................. ........... 283
7.1.9 Integración con Business Service Management .......................................... ......... 284
7.2 Gestión de eventos ............................................... ................................................ 285
7.3 Gestión de incidentes ............................................... ............................................ 286
7.3.1 Tecnología ITSM integrada ............................................ ...................................... 286
7.3.2 Flujo de trabajo y escalamiento automático ........................................... .......................... 286
7.4 Cumplimiento de la solicitud ............................................... .................................................. 287
7.5 Gestión de problemas ............................................... ........................................... 288
7.5.1 Tecnología de gestión de servicios integrados ........................................... ............ 288
7.5.2 Gestión de cambios ............................................. ............................................... 288
7.5.3 CMS integrado ............................................. .................................................. ...... 288
7.5.4 Base de datos de errores conocidos ............................................ .............................................. 288
7.6 Gestión de acceso ............................................... ............................................. 289
7.7 Mesa de servicio ............................................... .................................................. ........ 290
7.7.1 Telefonía .............................................. .................................................. .............. 290
7.7.2 Herramientas de soporte ............................................. .................................................. .......... 290
7.7.2.1 Base de datos de errores conocidos ............................................ .................................................. .... 291
Página 10
7.7.2.2 Scripts de diagnóstico ............................................. .................................................. ........... 291

7.7.2.3 Interfaz web de autoayuda .......................................... .................................................. ..... 291
7.7.2.4 Mando a distancia ............................................. .................................................. ............... 292
7.7.3 Planificación de la continuidad del servicio de TI para las herramientas de soporte de ITSM ....................................... ... 292
8 Consideraciones de implementación ............................................... ....................... 293
8.1 Gestión de cambios en la operación del servicio ............................................ ................... 294
8.1.1 Cambiar desencadenantes ............................................. .................................................. ...... 294
8.1.2
8.1.3 Evaluación decambio
Medición del cambios .............................................
exitoso .................................................
........................................... ........................... 295 294
8.2 Operación del servicio y gestión de proyectos ............................................ ........... 296
8.3 Evaluación y gestión de riesgos en la operación del servicio .......................................... .. 297
8.4 Personal operativo en Diseño y Transición de Servicios .......................................... .... 298
8.5 Planificación e implementación de tecnologías de gestión de servicios ... 299
8.5.1 Licencias .............................................. .................................................. ................. 299
8.5.1.1 Licencias dedicadas ............................................. .................................................. ......... 299
8.5.1.2 Licencias compartidas ............................................. .................................................. ............. 299
8.5.1.3 Licencias web ............................................. .................................................. .................. 299
8.5.1.4 Servicio bajo demanda ............................................ .................................................. ......... 300
8.5.2 Despliegue .............................................. .................................................. ........... 300
8.5.3 Comprobaciones de capacidad ............................................. .................................................. ..... 301
8.5.4 Momento del despliegue de la tecnología ........................................... ............................... 301
8.5.5 Tipo de introducción ............................................ .................................................. .302
9 Desafíos, factores críticos de éxito y riesgos .......................................... ... 303
9.1 Desafíos ................................................ .................................................. .......... 303
9.1.1 Falta de compromiso con el personal de desarrollo y proyectos ...................................... 303
9.1.2 Justificación de la financiación ............................................. .................................................. .... 304
9.1.3 Desafíos para los gerentes de operación del servicio .......................................... .............. 304
9.2 Factores críticos de éxito .............................................. ......................................... 307
9.2.1 Apoyo a la gestión ............................................. ................................................ 307
9.2.2 Apoyo empresarial ............................................. .................................................. .... 307
9.2.3 Campeones .............................................. .................................................. ............ 308
9.2.4 Dotación de personal y retención ............................................ ................................................ 308
9.2.5 Formación en gestión de servicios ............................................ .................................... 309
9.2.6 Herramientas adecuadas ............................................. .................................................. .......... 310
9.2.7 Validez de las pruebas ............................................ .................................................. ..... 310
9.2.8 Medición e informes ............................................ ...................................... 310
9.3 Riesgos ................................................ .................................................. ................... 311
9.3.1 Pérdida de servicio ............................................. .................................................. ............ 311
9.3.2 Riesgos para la operación exitosa del servicio .......................................... ........................ 311
Epílogo ................................................. .................................................. ....... 313
Apéndice A: Orientación complementaria de la industria ............................................ ... 314
A1 COBIT ................................................ .................................................. .................. 315
A2 ISO / IEC 20000 ............................................. .................................................. ....... 317
A3 CMMI ................................................ .................................................. ................... 318
Cuadro de mando integral A4 ............................................... ............................................... 318
A5 Gestión de la calidad ............................................... .............................................. 319
A6 ITIL y el marco OSI ............................................ ..................................... 319
Apéndice B: Comunicación en la operación del servicio ........................................... 320
B1 Comunicación operativa de rutina .............................................. ........................ 320
B2 Comunicación entre turnos .............................................. ............................... 322
B3 Informes de desempeño ............................................... .......................................... 323
Rendimiento del servicio de TI ............................................... .................................................. .323
Rendimiento del equipo o departamento de operación de servicio ............................................ ......... 325
Rendimiento de la infraestructura o del proceso .............................................. ............................. 327
Página 11
B4 Comunicación en proyectos .............................................. ...................................... 328

B5 Comunicación relacionada con cambios ............................................. ......................... 330
B6 Comunicación relacionada con excepciones ............................................. ...................... 332
B7 Comunicación relacionada con emergencias ............................................. .................. 334
B8 Comunicación con usuarios y clientes ............................................ ............... 336
Apéndice C: Kepner y Tregoe ............................................ .......................... 338
C1 Definición del problema .............................................. .................................................. .339
C2 Describiendo el problema .............................................. ............................................... 339
C3 Establecimiento de posibles causas .............................................. ...................................... 339
C4 Prueba de la causa más probable ............................................ .................................. 339
C5 Verificación de la verdadera causa ............................................. ............................................... 340
Apéndice D: Diagramas de Ishikawa ............................................. .......................... 341
Apéndice E: Descripción detallada de la gestión de instalaciones ............................. 343
E1 Gestión de edificios ............................................... ............................................. 344
Alojamiento de equipos E2 ............................................... ................................................. 345
Gestión de energía E3 ............................................... ............................................... 346
E4 Acondicionamiento ambiental y sistemas de alerta ............................................ ....... 348
E5 Seguridad ................................................ .................................................. ................... 350
E6 Control de acceso físico .............................................. .......................................... 350
E7 Envío y recepción .............................................. .......................................... 350
E8 Participación en la gestión de contratos ............................................. ..................... 351
E9 Mantenimiento ................................................ .................................................. ........ 351
Apéndice F: Control de acceso físico ............................................ ................... 353
Glosario................................................. .................................................. ......... 358
Lista de acrónimos ................................................ .................................................. ............. 358
Lista de definiciones ................................................ .................................................. ............ 362
Pagina 12
Prefacio
Prólogo de OGC
Desde su creación, ITIL ha crecido hasta convertirse en el enfoque más aceptado

a la gestión de servicios de TI en el mundo. Sin embargo, junto con este éxito viene
la responsabilidad de asegurar que la guía se mantenga al día con un cambio global
ambiente de negocios. Los requisitos de gestión de servicios se configuran inevitablemente
por el desarrollo de tecnología, modelos de negocio revisados y el aumento
Expectativas del cliente. Nuestra última versión de ITIL se ha creado en respuesta
a estos desarrollos.
Esta es una de las cinco publicaciones principales que describen la gestión de servicios de TI.
prácticas que componen ITIL. Son el resultado de un proyecto de dos años para revisar
y actualice la guía. El número de profesionales de la gestión de servicios.
en todo el mundo que han ayudado a desarrollar el contenido de estas publicaciones es
impresionante. Su experiencia y conocimiento han contribuido al contenido de
Brindarle un conjunto consistente de orientación de alta calidad. Esto es apoyado por el
desarrollo continuo de un esquema integral de calificaciones, junto con
formación y consultoría acreditadas.
Ya sea que forme parte de una empresa global, un departamento gubernamental o una pequeña
negocios, ITIL le brinda acceso a experiencia en administración de servicios de clase mundial.
Esencialmente, coloca los servicios de TI donde pertenecen: en el corazón del éxito
operaciones de negocios.
Peter Fanning
Director ejecutivo interino
Oficina de Comercio Gubernamental
Página 13
Prólogo del arquitecto jefe
La guía de práctica de gestión de servicios de ITIL se estructura en torno al servicio

Ciclo vital. Común en todo el ciclo de vida es la práctica general en sí, que se basa
sobre procesos, funciones, actividades, modelos organizativos y medición,
que en conjunto permiten que la Gestión de Servicios de TI (ITSM) se integre con el
procesos de negocio, proporcionan valor medible y hacen evolucionar la industria de ITSM
adelante en nuestra búsqueda de la excelencia en el servicio.
En ningún otro lugar del ciclo de vida del servicio ITIL, el efecto de cómo nos desempeñamos como
los proveedores de servicios tocan a los clientes tan íntimamente como las operaciones de servicio. Esta
es donde se entregan la estrategia, el diseño, la transición y las mejoras y
apoyado en el día a día.
La publicación Service Operation da vida a la gestión del servicio para el
negocio, y la responsabilidad por el desempeño de los servicios, las personas
quienes los crean y la tecnología que los habilita son monitoreados, controlados
y entregado en esta etapa del ciclo de vida del servicio.
Esta publicación nos ayudará a guiarnos a todos para lograr la excelencia en el servicio y a ver
el valor de ITSM en una visión amplia y centrada en el negocio. Si eres nuevo
para la práctica de ITIL o un practicante experimentado, la guía en esta publicación
ampliará su visión y conocimiento de cómo ser el mejor servicio de su clase
proveedor a través de la implementación de la Operación del Servicio.
Hay un dicho que dice que la retrospectiva es 20/20. La guía en la operación del servicio es
destilado de más de 20 años de experiencia en ITSM por expertos mundiales, empresas
personas y practicantes de ITSM y las lecciones aprendidas por ellos sobre lo que
la excelencia en el servicio realmente es y cómo lograrla.
Cualquier persona involucrada en los servicios operativos se beneficiará de la orientación en el

siguientes páginas de esta publicación. Service Operation ofrece el mejor asesoramiento y
orientación de todo el mundo y un camino hacia lo que es posible en su futuro.
Sharon Taylor
Arquitecto jefe, Prácticas de gestión de servicios de ITIL
Página 14
Prefacio
Esta publicación abarca y reemplaza los aspectos operativos de la
Publicaciones ITIL Service Support y Service Delivery y también cubre la mayoría de
el alcance de la gestión de la infraestructura de las TIC. También incorpora operativa
aspectos de la planificación a la implementación, gestión de aplicaciones, software
Publicaciones de Gestión de activos y Gestión de la seguridad.
Los principios básicos de la gestión de servicios de TI de mejores prácticas englobados en

las versiones anteriores de ITIL permanecen sin cambios. El sentido común sigue siendo común
¡sentido!
Sin embargo, las tecnologías, herramientas y relaciones han cambiado significativamente,

incluso en el tiempo relativamente corto desde que se completó la última versión de ITIL.
Si bien esta publicación reutiliza y actualiza material relevante de la anterior
versiones cuando sea apropiado, también incluye muchos conceptos nuevos y la industria
prácticas para brindar una cobertura completa de la guía de mejores prácticas para el servicio actual
Operación en un solo volumen, para los negocios y la tecnología de hoy
ambiente.
Información del contacto
Se pueden encontrar detalles completos de la gama de material publicado bajo el banner de ITIL.
en www.best-management-practice.com/itil
Si desea informarnos de cualquier cambio que pueda ser necesario en este

publicación, regístrelos en www.best-management-practice.com/changelog
Para obtener más información sobre cualificaciones y acreditación de formación, visite

www.itil-officialsite.com. Alternativamente, comuníquese con:
Mesa de servicio APMG

Casa de la espada
Totteridge Road
High Wycombe
Buckinghamshire
HP13 6DG
Tel: +44 (0) 1494 452450

Correo electrónico: servicedesk@apmgroup.co.uk
Página 15
Agradecimientos
Arquitecto jefe y autores
Sharon Taylor (Aspect Group Inc) Arquitecto jefe
David Cannon (HP) Autor
David Wheeldon (HP) Autor
Equipo de creación de ITIL
El equipo de creación de ITIL contribuyó a esta guía comentando el contenido.

y alineación en todo el conjunto. Así que también debemos agradecer a los otros autores de ITIL,
específicamente Jeroen Bronkhorst (HP), Gary Case (Pink Elephant), Ashley Hanna
(HP), Majid Iqbal (Universidad Carnegie Mellon), Shirley Lacy (ConnectSphere),
Vernon Lloyd (Fox IT), Ivor Macfarlane (Guillemot Rock), Michael Nieves
(Accenture), Stuart Rance (HP), Colin Rudd (ARTÍCULOS) y George Spalding (Pink
Elefante).
Mentores
Christian Nissen y Paul Wilkinson
Contribuciones adicionales
Varias personas contribuyeron generosamente con su tiempo y experiencia a esta Operación de Servicio.
publicación. Jim Clinch, como gerente de proyectos de OGC, agradece el apoyo brindado por HP a
el equipo de autores sobre el desarrollo de esta publicación y, en particular, la contribución de
Peter Doherty y Robert Stroud, y por el apoyo de Jenny Dugmore, coordinadora de Working
Grupo ISO / IEC 20000, Janine Eves, Carol Hulm, Aidan Lawes y Michiel van der Voort.
Los autores también desean agradecer a Stuart Rance y Ashley Hanna de Hewlett-Packard,
Christian F Nissen (Itilligence), Maria Vase (Itilligence), Eu Jin Ho (UBS), Jan Bjerregaard, (Sun
Microsystems), Jan Øberg (ØBERG Partners), Lars Zobbe Mortensen (Zobbe Consult &
Zoftware), Mette Nielsen (Carlsberg IT), Michael Imhoff (IBM), Niels Berner (Novo Nordisk), Nina
Schertiger (HP), Signe-Marie Hernes Bjerke (DNV), Steen Sverker Nilsson (Westergaard CSM),
Ulf Myrberg (BiTa), Russell Jukes, Debbi Jancaitis, Sheldon Parmer, Ramon Alanis, Tim Benson
y Nenen Ong de Hewlett-Packard IT, Jaye Thompson, Dee Seymour, Andranik Ziyalyan,
Young Chang, Lauren Abernethy, April McCowan, Becky Wershbale, Rob Garman y Scott
McPherson, Sandra Breading, Rick Streeter, Leon Gantt, Charlotte Devine, Greg Algorri, Mary
Fischer, Bill Thayer y Diana Osberg de la empresa de TI empresarial de The Walt Disney Company, Dennis
Deane y John Sowerby de DHL, Richard Fahey y Chris Hughes de HP Global Delivery
Servicios de aplicación, Cindi Locker y Dhiraj Gupta de Progressive Casualty Insurance
Company, Peter Doherty y Robert Stroud de Computer Associates y Paul Tillston de
Hewlett-Packard, Brian Jakubec, Vernon Blakes, Angela Chin, Colin Lovell, Ken Hamilton, Rose
Página 16
Lariviere, Jenny McPhee, Tom Nielsen, Roc Paez, Lloyd Robinson, Paul Wilmot, Jeanette Smith
y Ken Wendle de Hewlett-Packard.
Con el fin de desarrollar prácticas de gestión de servicios ITIL para reflejar las mejores prácticas actuales y
producir publicaciones de valor duradero, OGC consultó ampliamente con diferentes partes interesadas
en todo el mundo en cada etapa del proceso. OGC también quisiera agradecer a las siguientes
individuos y sus organizaciones por sus contribuciones para actualizar la guía de ITIL:
El Grupo Asesor de ITIL
Pippa Bass, OGC; Tony Betts, Independiente; Signe-Marie Hernes Bjerke, Det Norske Veritas;
Alison Cartlidge, Xansa; Diane Colbeck, DIYmonde Solutions Inc; Ivor Evans, DIYmonde
Solutions Inc; Karen Ferris, ProActive; Malcolm Fry, FRY-Consultants; John Gibert, independiente;
Colin Hamilton, RENARD Consulting Ltd; Lex Hendriks, EXIN; Carol Hulm, computadora británica
Sociedad-ISEB; Tony Jenkins, DOMAINetc; Phil Montanaro, EDS; Alan Nance, ITPreneurs;
Christian Nissen, Itilligence; Don Page, Grupo Marval; Bill Powell, IBM; Sergio Rubinato Filho,
CALIFORNIA; James Siminoski, SOScorp; Robert E. Stroud, CA; Jan van Bon, Inform-IT; Ken Wendle, HP;
Paul Wilkinson, Getronics PinkRoccade; Takashi Yagi, Hitachi.
Revisores
Jorge Acevedo, Computec SA; Balaji Alapilla; Valerie Arraj, InteQ; Colin Ashcroft, Ciudad de
Londres; William Bagley, saludos cordiales; Martijn Bakker, Getronics PinkRoccade; Jeff Bartrop, BT y
Servicio al cliente directo; Rajesh Basava Amatyappa Bellary, Satyam; John Bennett, Centram
Limitado; Ian Bevan, Fox IT; Enrico Boverino, CA; Bart Van Brabant, Post; Ronald Browning, CA;
Stephen Bull, Sierra Systems; Bradley Busch, InTotality; Howard Carpenter, IBM; Liang Cheng,
IBM; John Clark, HP; Nicole Conboy, Nicole Conboy y asociados; Sharon Dale, aQuip
Internacional; Sandra Daly, Dawling Consultancy; Tony Domain, Blue Yonder; Michael Donahue,
IBM; Ken Doughty; Andre J. Emmell, DKMStech; Matthew Evans, Process Worx; Juan antonio
Fernández, Quint Wellington Redrood; Karen Ferris, servicios proactivos; Juan José Figueiras,
Globant; Liz Gallacher; Rae Garrett, elefante rosa; Klaus Goedel, HP; David Gooda, Genesys
Consultante; Detlef Gross, Automation Consulting Group GmbH; Matthias Hall, Universidad de
Dundee; John Hannan, mejores prácticas de TI; Jonas Hansen, MMIT; Oliver Hast, Scoops; Jabe
Hickey, IBM; Graham Hill, Metisc; Kevin Hite, Microsoft; Sergio Hrabinski, Xelere; Scott Jaegar,
Plexante; Chris Jay; Chunyang Jia, Microsoft; Masthan Kadhar Kadhar, Cognizant; Tony Kelman
Smith, HP; Peter Koepp, independiente; Joanne Kopcho, Capgemini America; Rene van Kuijen;
Debbie Langenfield, IBM; Horacio Laprea; Sarah Lascelles, Interserve Project Services Ltd; Pedro
Loos, Accenture Services GmbH; Marcos López, Microsoft; Emmanuel Marchand, Advens;
James Marmion, Grupo Yell; Jesús Martín, Ibermatica SA; Luis Moran, Independiente; Steve
Morgan, KPMG; Ron Morton, HP; Philip Mougis, TCS; Richard Mulholland, IBM; Ron Muns, HDI;
Darren Murtagh, Retravision; Krisna Nugraha, Cleon Consulting; Shuichi Owa, Niandc; Sampo
Pasanen, Efecte; Rodrigo Pementa, Pink Elephant; Eddy Peters, CTG; Steve Phelan, Luna
Mono; Carol Piccus, CA; Poul Mols Poulsen, Coop Norden IT; Roger Purdie, El arte de
Servicio; Glen Ralph, iCore Ltd; Padmini Ramamurthy, Satyam Computer Services Ltd; Keith
Reynolds, NSS Consulting; Manfred Rieder, HP; Stephanie Roddy, Grupo Camelot; Mieke
Roelens, CTA; Frances Scarff, OGC; Markus Schiemer, Unisys; Barbara Schiesser, TIC suiza;
Klaus Seidel, Microsoft; Migel Sergey; Mamak Shafai; Prakash Sharma; Gilbert Silva, Techbiz
Informatica Ltd; Jim Siminoski, Soscorp; Dierk Soellner, Mod-gruppe; José Esteban,
Departamento de Transporte, Gobierno de los Estados Unidos; Michala Sterling, Concejo del Distrito de Mid Sussex;
Helen Sussex, acmg de Logic; Rohan Thuraisingham, Friends Provident Management Services Ltd;
Matthew Tolman, Sandvik; Cheryl Tovizi, MWH Global; Frank Victor, Victor GmbH; Corde
Wagner; Christoph Wettstein, CLAVIS klw AG; Andi Wijaya, IBM; Aaron Wolfe, elefante rosa;
Mike Yang, IBM; YoungHoon Youn, IBM.
Página 17
1. Introducción
Esta publicación proporciona asesoramiento y orientación sobre las mejores prácticas sobre todos los aspectos de
Gestionar el funcionamiento diario de la tecnología de la información de una organización .
(TI) servicios. Cubre temas relacionados con las personas, los procesos , la infraestructura.
la tecnología y las relaciones necesarias para garantizar la alta calidad y la rentabilidad
prestación del servicio de TI necesario para satisfacer las necesidades comerciales.
El advenimiento de la nueva tecnología y las ahora borrosas líneas entre lo tradicional

silos de tecnología de hardware, redes, telefonía y software de aplicación s
gestión significa que se necesita un enfoque actualizado para gestionar las operaciones de servicio .
necesario. Organización s son cada vez más propensos a considerar diferentes formas de
proporcionar su TI a un costo y flexibilidad óptimos , con la introducción de la TI de servicios públicos
servicios de TI de pago por uso, provisión de TI virtual, capacidad dinámica y adaptables
Computación empresarial, así como opciones de subcontratación y subcontratación de tareas .
Estas alternativas han dado lugar a una gran variedad de relaciones comerciales de TI, tanto
interna y externamente, que han aumentado en complejidad tanto como el
las tecnologías que se gestionan tienen. Dependencia empresarial de estos complejos
las relaciones son cada vez más críticas para la supervivencia y la prosperidad.
Página 18
1.1 Resumen
La operación del servicio es la fase del ciclo de vida de ITSM responsable de

actividades de "negocios como de costumbre".
La operación del servicio puede verse como la "fábrica" de TI. Esto implica un enfoque más cercano
sobre las actividades diarias y la infraestructura que se utilizan para prestar servicios.
Sin embargo, esta publicación se basa en el entendimiento de que la
El propósito de la Operación del Servicio es brindar y brindar soporte a los servicios. Administración de
la infraestructura y las actividades operativas siempre deben apoyar este propósito.
Los procesos bien planificados e implementados no servirán de nada si el día a día

el funcionamiento de esos procesos no se lleva a cabo, controla y gestiona adecuadamente.
Tampoco serán posibles mejoras en el servicio si las actividades diarias para monitorear
rendimiento , evaluar métricas y recopilar datos no se llevan a cabo de manera sistemática
durante la operación de servicio.
El personal de Operación del Servicio debe contar con procesos y herramientas de apoyo para
Permitirles tener una visión general del funcionamiento y la prestación del servicio (en lugar de
solo los componentes separados , como hardware, aplicaciones de software y
redes, que componen el servicio de un extremo a otro desde una perspectiva empresarial ) y
para detectar cualquier amenaza o falla en la calidad del servicio .
Dado que los servicios pueden ser proporcionados, en su totalidad o en parte, por uno o más socios / proveedores.
organización s, la Operación del Servicio vista de extremo a extremo de servicios debe estar
extendido para abarcar aspectos externos de la prestación de servicios, y cuando
Se necesitan procesos y herramientas compartidos o interconectados necesarios para gestionar
Flujos de trabajo interorganizacionales.
La operación del servicio no es una unidad organizativa ni un proceso único, pero

incluye varias funciones y muchos procesos y actividades, que son
descrito en los Capítulos 4, 5 y 6
Página 19
1.2 Contexto
1.2.1 Gestión de servicios
TI es un término de uso común que cambia de significado con el contexto. Desde el principio
perspectiva, los sistemas de TI , las aplicaciones y la infraestructura son componentes o sub-
ensamblajes de un producto más grande. Habilitan o están integrados en procesos y
servicios. Desde la segunda perspectiva, TI es una organización con su propio conjunto de
capacidades y recursos s. Las organizaciones de TI pueden ser de varios tipos, como
funciones comerciales, unidades de servicios compartidos y unidades centrales de nivel empresarial.
Desde la tercera perspectiva, la TI es una categoría de servicios que utilizan las empresas. Ellos
son típicamente aplicaciones e infraestructura de TI que se empaquetan y ofrecen como
servicios de organizaciones de TI internas o proveedores de servicios externos . Los costos de TI son
tratados como gastos comerciales. Desde la cuarta perspectiva, TI es una categoría de
activos comerciales que brindan una serie de beneficios para sus propietarios, que incluyen, pero
sin limitarse a ingresos, ingresos y ganancias. Los costos de TI se tratan como inversiones.
1.2.2 Buenas prácticas en el dominio público
Las organizaciones operan en entornos dinámicos con la necesidad de aprender y

adaptar. Es necesario mejorar el rendimiento mientras se gestionan las compensaciones. Debajo
presión similar, los clientes buscan ventajas de los proveedores de servicios. Ellos persiguen
estrategias de abastecimiento que mejor sirvan a sus propios intereses comerciales. En muchos
países, agencias gubernamentales y empresas sin fines de lucro tienen un
propensión a subcontratar en aras de la eficacia operativa . Esto pone
presión adicional sobre los proveedores de servicios para mantener una ventaja competitiva
en cuanto a las alternativas que puedan tener los clientes. El aumento en
La subcontratación ha expuesto particularmente a los proveedores de servicios internos a inusuales
competencia.
Para hacer frente a la presión, las organizaciones se comparan con sus pares.
y tratar de cerrar las brechas en las capacidades. Una forma de cerrar esas brechas es la
adopción de buenas prácticas en toda la industria. Hay varias fuentes para
buenas prácticas, incluidos los marcos públicos, los estándares y los
conocimiento de organizaciones e individuos (ver Figura 1.1).
Página 20
Figura 1.1 Fuente de la práctica de gestión de servicios
Los marcos y estándares públicos son atractivos en comparación con los de propiedad.
conocimiento:
• El conocimiento patentado está profundamente arraigado en las organizaciones y, por lo tanto,

difícil de adoptar, replicar o transferir, incluso con la cooperación del
propietarios. Este conocimiento suele adoptar la forma de conocimiento tácito que se
inextricable y pobremente documentado.
• El conocimiento patentado se personaliza para el contexto local y específico
necesidades empresariales, hasta el punto de ser idiosincrásicas. A menos que los destinatarios
de tal conocimiento tienen circunstancias coincidentes, el conocimiento puede no
ser igual de eficaz en su uso.
• Los propietarios de conocimientos patentados esperan ser recompensados por su
inversiones a plazo. Pueden hacer que dicho conocimiento esté disponible solo bajo
condiciones comerciales, a través de compras y acuerdos de licencia s.
• Marcos y estándares disponibles públicamente como ITIL, Control
Objetivos para TI ( COBIT ), CMMI, eSCM-SP, PRINCE2 , ISO 9000 , ISO
20000 y ISO 27001 se validan a través de un conjunto diverso de entorno s
y situaciones en lugar de la experiencia limitada de una sola organización .
Están sujetos a una amplia revisión en múltiples organizaciones y
disciplinas. Son examinados por diversos conjuntos de socios, proveedores y
competidores.
• Es más probable que el conocimiento de los marcos públicos se distribuya ampliamente
entre una gran comunidad de profesionales a través de
formación y certificación . Es más fácil para las organizaciones adquirir tales
conocimiento a través del mercado laboral.
Página 21
Ignorar los marcos y estándares públicos puede colocar innecesariamente a una organización
en una desventaja. Las organizaciones deben cultivar sus propias
conocimiento sobre un cuerpo de conocimiento basado en marcos públicos y
normas. La colaboración y la coordinación entre organizaciones son más fáciles para el
base de prácticas y estándares compartidos .
1.2.3 ITIL y buenas prácticas en la gestión de servicios
El contexto de esta publicación es el marco ITIL como fuente de buenos

práctica en Gestión de Servicios . ITIL es utilizado por organizaciones de todo el mundo para
Establecer y mejorar las capacidades en la Gestión de servicios. ISO / IEC 20000
proporciona un estándar formal y universal para las organizaciones que buscan tener su
Capacidades de gestión de servicios auditadas y certificadas. Si bien ISO / IEC 20000 es un
estándar que se debe alcanzar y mantener, ITIL ofrece un conjunto de conocimientos útiles
para alcanzar el estándar.
La biblioteca ITIL tiene los siguientes componentes :
• ITIL Core: guía de mejores prácticas aplicable a todo tipo de organizaciones

que prestan servicios a una empresa
• Guía complementaria de ITIL: un conjunto complementario de publicaciones
con orientación específica para sectores industriales, tipos de organización, operaciones
modelos y arquitectura tecnológica s.
ITIL Core consta de cinco publicaciones (consulte la Figura 1.2). Cada uno proporciona el
orientación necesaria para un enfoque integrado como lo requiere la ISO / IEC
20000 especificación estándar :
• Operación de servicio
• Mejora continua del servicio .
Página 22
Figura 1.2 Núcleo de ITIL
Cada publicación aborda las capacidades que tienen un impacto directo en un servicio.
desempeño del proveedor . La estructura del núcleo tiene la forma de un ciclo de vida . Es
iterativo y multidimensional. Asegura que las organizaciones estén configuradas para
Aprovechar las capacidades en un área para aprender y mejorar en otras. los
Se espera que Core proporcione estructura, estabilidad y solidez al servicio.
Capacidades de gestión , con principios, métodos y herramientas duraderos. Esto sirve
para proteger las inversiones y proporcionar la base necesaria para la medición,
aprendizaje y mejora.
La guía en ITIL se puede adaptar para cambios de uso en diversos negocios.
entorno sy estrategias organizativas. La orientación complementaria
proporciona flexibilidad para implementar el Core en una amplia gama de entornos.
Los profesionales pueden seleccionar la guía complementaria según sea necesario para proporcionar tracción
para el Core en un contexto empresarial dado, de la misma manera que los neumáticos se seleccionan en función de
el tipo de automóvil, el propósito y las condiciones de la carretera. Esto es para aumentar el
durabilidad y portabilidad de los activos de conocimiento y para proteger las inversiones en
Capacidades de gestión de servicios.
1.2.3.1 Estrategia de servicio
Página 23
El volumen de Estrategia de servicio proporciona orientación sobre cómo diseñar , desarrollar y

implementar la Gestión de Servicios, no solo como una capacidad organizativa , sino también
como activo estratégico . Se proporciona orientación sobre los principios que sustentan la
práctica de la Gestión de Servicios que son útiles para desarrollar el Servicio
Políticas de gestión, directrices y procesos en todo el Servicio ITIL
Ciclo de vida . La orientación de la estrategia del servicio es útil en el contexto del diseño del servicio ,
Transición del servicio , operación del servicio y mejora continua del servicio .
Los temas cubiertos en la estrategia de servicio incluyen el desarrollo de mercados,
y externo, activos de servicio , catálogo de servicios e implementación de estrategia
a través del ciclo de vida del servicio. Gestión financiera , Cartera de servicios
Gestión , Desarrollo Organizacional y Riesgos Estratégicos se encuentran entre otros
temas principales.
Las organizaciones utilizan la guía para establecer objetivos y expectativas de

desempeño para atender a los clientes y los espacios de mercado y para identificar,
seleccionar y priorizar oportunidades. La estrategia de servicio consiste en garantizar que
Las organizaciones están en condiciones de manejar los costos y riesgos asociados con sus
portafolios de servicios y están configurados no solo para la efectividad operativa sino para
rendimiento distintivo. Las decisiones tomadas con respecto a la estrategia del servicio
consecuencias de gran alcance, incluidas las de efecto retardado.
Las organizaciones que ya practican ITIL utilizan este volumen para guiar una revisión estratégica
de sus capacidades de gestión de servicios basadas en ITIL y para mejorar la
alineación entre esas capacidades y sus estrategias comerciales. Este volumen
de ITIL anima a los lectores a detenerse y pensar por qué se debe hacer algo
antes de pensar en cómo. Las respuestas al primer tipo de preguntas se acercan más a la
negocio del cliente. La estrategia de servicio amplía el alcance del marco ITIL
más allá de la audiencia tradicional de profesionales de ITSM.
1.2.3.2 Diseño de servicios
El volumen de Diseño de servicios proporciona una guía para el diseño y desarrollo.

de servicios y procesos de gestión de servicios. Cubre principios de diseño y
métodos para convertir los objetivos estratégicos en carteras de servicios y servicios
activos. El alcance del Diseño de servicios no se limita a nuevos servicios. Incluye el
cambios y mejoras necesarios para aumentar o mantener el valor de
clientes durante el ciclo de vida de los servicios, la continuidad de los servicios, el logro
de los niveles de servicio y la conformidad con las normas y los reglamentos. Guía
organizaciones sobre cómo desarrollar capacidades de diseño para la gestión de servicios.
1.2.3.3 Transición del servicio
El volumen de Transición del servicio proporciona una guía para el desarrollo y

mejora de las capacidades para la transición de servicios nuevos y modificados a
operación s. Esta publicación proporciona orientación sobre cómo los requisitos de
La estrategia de servicio codificada en el diseño del servicio se realiza eficazmente en Service
Página 24
Operaciones mientras se controlan los riesgos de fallas e interrupciones. La publicación

combina prácticas en Gestión de versiones , Gestión de programas y Riesgos
Management y los coloca en el contexto práctico de Service Management . Eso
proporciona orientación sobre la gestión de la complejidad relacionada con los cambios en los servicios
y los procesos de gestión de servicios , evitando consecuencias no deseadas mientras
permitiendo la innovación. Se proporciona orientación sobre la transferencia del control de
servicios entre el cliente y el proveedor de servicios .
1.2.3.4 Operación del servicio
Este volumen incorpora prácticas en la gestión de Operaciones de Servicio . Eso

incluye orientación sobre cómo lograr la eficacia y la eficiencia en la entrega y
Soporte de servicios para asegurar valor para el cliente y el servicio.
proveedor. Los objetivos estratégicos se logran en última instancia a través de las operaciones de servicio,
por lo tanto, lo convierte en una capacidad crítica . Se proporciona orientación sobre cómo mantener
estabilidad en las operaciones de servicio, permitiendo cambios en el diseño, escala, alcance y
niveles de servicio. Las organizaciones reciben pautas de proceso detalladas ,
métodos y herramientas para su uso en dos perspectivas de control principales : reactivo y
proactivo. Los gerentes y profesionales reciben conocimientos que permiten
ellos para tomar mejores decisiones en áreas como la gestión de la disponibilidad de
servicios, control de la demanda, optimización de la utilización de la capacidad , programación de
operaciones y solución de problemas s. Se proporciona orientación sobre operaciones de apoyo.
a través de nuevos modelos y arquitecturas como servicios compartidos, informática de servicios públicos ,
servicios web y comercio móvil.
1.2.3.5 Mejora continua del servicio
Este volumen proporciona una guía fundamental para la creación y el mantenimiento de valor para
clientes mediante un mejor diseño , introducción y funcionamiento de los servicios. Eso
combina principios, prácticas y métodos de Gestión de la Calidad , Cambio
Gestión y mejora de la capacidad. Las organizaciones aprenden a darse cuenta
mejoras incrementales y a gran escala en la calidad del servicio , operacional
eficiencia y continuidad del negocio. Se proporciona orientación para vincular la mejora
esfuerzos y resultados con estrategia de servicio, diseño de servicio y servicio
Transición. Un sistema de retroalimentación de circuito cerrado , basado en Planificar-Hacer-Verificar-Actuar
(PDCA) especificado en ISO / IEC 20000 , está establecido y es capaz de
recibir insumos para el cambio desde cualquier perspectiva de planificación .
La gestión operativa diaria de los servicios de TI está significativamente influenciada

por qué tan bien se ha definido la estrategia general de servicios de TI de una organización y
qué tan bien se han planificado e implementado los procesos de ITSM. Este es el
cuarta publicación de la serie ITIL Service Management Practices y la otra
Las publicaciones sobre estrategia de servicio, diseño de servicios y transición de servicios deben
ser consultado para obtener orientación sobre las mejores prácticas en estas etapas importantes antes de
Operación de servicio.
Página 25
La operación del servicio es extremadamente importante, ya que es una operación operativa del día a día.
sobre la base de que ocurren eventos que pueden tener un impacto adverso en la calidad del servicio. El camino en
cuál es la infraestructura de TI de una organización y sus procesos ITSM de soporte
operado tendrá la influencia más directa e inmediata a corto plazo sobre
calidad del servicio .
Página 26
1.3 Propósito
La operación del servicio es una fase crítica del ciclo de vida de ITSM . Bien planeado y bien
los procesos implementados no servirán de nada si el funcionamiento diario de los
los procesos no se llevan a cabo, controlan y gestionan correctamente. Ni servicio
las mejoras serán posibles si las actividades diarias para monitorear el desempeño , evaluar
Las métricas y la recopilación de datos no se llevan a cabo sistemáticamente durante el Servicio
Operación.
El personal de Operación del Servicio debe contar con procesos y herramientas de apoyo para
Permitirles tener una visión general del funcionamiento y la prestación del servicio (en lugar de
solo los componentes separados , como hardware, aplicaciones de software y
redes, que componen el servicio de un extremo a otro desde una perspectiva empresarial) y
para detectar cualquier amenaza o falla en la calidad del servicio .
Dado que los servicios pueden ser proporcionados, en su totalidad o en parte, por uno o más socios / proveedores.
organizaciones, la vista Operación del servicio del servicio de un extremo a otro debe ser
extendido para abarcar aspectos externos de la prestación de servicios, y cuando
Se necesitan procesos y herramientas compartidos o interconectados necesarios para gestionar
Flujos de trabajo interorganizacionales.
1.4 Uso
Esta publicación debe utilizarse junto con las otras cuatro publicaciones.
que componen el ciclo de vida del servicio ITIL .
Los lectores deben saber que las pautas de mejores prácticas en este y otros
los volúmenes no pretenden ser prescriptivos. Cada organización es única y
debe 'adaptar y adoptar' la guía para sus propias necesidades específicas, entorno y
cultura . Esto implicará tener en cuenta el tamaño de la organización,
habilidades / recursos , cultura, financiamiento, prioridades y madurez y madurez de ITSM existentes
modificar la guía según corresponda para adaptarse a las necesidades de la organización.
Para las organizaciones que encuentran ITIL por primera vez, alguna forma de evaluación inicial para
comparar los procesos y prácticas actuales de la organización con los
recomendado por ITIL sería un punto de partida muy valioso. Estos
Las evaluaciones se describen con más detalle en el Servicio continuo de ITIL .
Publicación de mejoras .
Cuando existan brechas importantes, puede ser necesario abordarlas en etapas durante
un período de tiempo para cumplir con las prioridades comerciales de la organización y mantenerse al día con
lo que la organización puede absorber y pagar
Página 27
1.5 Resumen del capítulo
El Capítulo 2 presenta el concepto de Gestión de servicios como práctica. Aquí,

La Gestión de Servicios se posiciona como un componente estratégico y profesional de
cualquier organización. Este capítulo también proporciona una descripción general del funcionamiento del servicio como
un componente crítico de la práctica de gestión de servicios.
Los principios clave de la Operación del Servicio se tratan en el Capítulo 3 de este

publicación. Estos principios describen algunos de los conceptos y principios básicos
en el que se basa el resto de la publicación.
El Capítulo 4 cubre los procesos realizados dentro de la Operación del Servicio, la mayoría de
Los procesos de Operación del Servicio son reactivos debido a la naturaleza del trabajo.
que se realizan para mantener los servicios de TI en una condición sólida y estable. Esta
El capítulo también cubre los procesos proactivos para enfatizar que el objetivo del Servicio
La operación es estabilidad, pero no estancamiento. La operación del servicio debe ser
buscando constantemente formas de hacer las cosas mejor y de manera más rentable, y
los procesos proactivos tienen un papel importante que desempeñar aquí.
El Capítulo 5 cubre una serie de actividades de Operación de Servicios Comunes, que son
grupos de actividades y procedimientos realizados por las funciones de operación del servicio.
Estas actividades especializadas, y a menudo técnicas, no son procesos en el verdadero
sentido de la palabra, pero todos son vitales para la capacidad de brindar servicios de TI de calidad
a un costo óptimo .
El Capítulo 6 cubre los aspectos organizacionales de la Operación del Servicio: el

individuos o grupos que llevan a cabo procesos o actividades de Operación del Servicio -
e incluye alguna orientación sobre las estructuras organizativas de la operación del servicio.
El capítulo 7 describe las herramientas y la tecnología que se utilizan durante el servicio.

Operación.
El capítulo 8 cubre algunos aspectos de la implementación que deberán ser

considerado antes de que la fase operativa del ciclo de vida se active.
El capítulo 9 destaca los desafíos, los factores críticos de éxito y los riesgos que se enfrentan
durante la operación del servicio , mientras que el epílogo resume y concluye el
publicación.
ITIL no es el único que brinda orientación a los gerentes de TI y al

los apéndices describen algunos de los marcos complementarios clave, metodologías
y enfoques que se utilizan comúnmente junto con ITIL durante el servicio
Operación
Página 28
2 Gestión de servicios como práctica
2.1 ¿Qué es la gestión de servicios?
La gestión de servicios es un conjunto de capacidades organizativas especializadas para

proporcionar valor a los clientes en forma de servicios. Las capacidades toman el
forma de funciones y procesos para gestionar servicios a lo largo de un ciclo de vida , con
especializaciones en estrategia , diseño , transición, operación y continua
mejora. Las capacidades representan una organización de servicio ‘s de capacidad ,
competencia y confianza para la acción. El acto de transformar los recursos en
servicios valiosos son el núcleo de la gestión de servicios. Sin estos
capacidades, una organización de servicios es simplemente un conjunto de recursos que por sí mismo
tiene un valor intrínseco relativamente bajo para los clientes.
Definición de gestión de servicios
La gestión de servicios es un conjunto de capacidades organizativas especializadas para

proporcionar valor a los clientes en forma de servicios.
Las capacidades organizativas están determinadas por los desafíos que se espera que afronten.
superar. Un ejemplo de esto es cómo en la década de 1950 Toyota desarrolló
Capacidades para superar el desafío del capital financiero y de menor escala.
en comparación con sus rivales estadounidenses. Toyota desarrolló nuevas capacidades en producción
ingeniería, gestión de operaciones y gestión de proveedores para compensar
su incapacidad para pagar grandes inventarios, fabricar componentes , producir materias primas
o poseer las empresas que los produjeron. [Fuente: Magretta, Joan 2002. ¿Qué
La gestión es: cómo funciona y por qué es asunto de todos . La prensa libre.]
Las capacidades de gestión de servicios están influenciadas de manera similar por lo siguiente
desafíos que distinguen a los servicios de otros sistemas de creación de valor, como
como manufactura, minería y agricultura:
• Naturaleza intangible de la salida y los productos intermedios de servicio.

Procesos: Difícil de medir, controlar y validar (o probar).
• La demanda está estrechamente relacionada con los activos del cliente : usuarios y otros
activos del cliente tales como procesos, aplicaciones , documentos y
las transacciones llegan con la demanda y estimulan la producción de servicios.
• Alto nivel de contacto para productores y consumidores de servicios: Poco o ningún
amortiguador entre el cliente, el front-office y el back-office.
• La naturaleza perecedera de servicio de salida y el servicio de capacidad : Hay
valor para el cliente de la garantía del suministro continuo de
calidad constante . Los proveedores necesitan asegurar una oferta constante de demanda
de los clientes.
Sin embargo, la gestión de servicios es más que un conjunto de capacidades. También es un

práctica profesional respaldada por un amplio cuerpo de conocimientos, experiencia
y habilidades. Una comunidad global de individuos y organizaciones en el público y
Página 29
El sector privado fomenta su crecimiento y madurez . Existen esquemas formales para

educación, capacitación y certificación de organizaciones e individuos en ejercicio
influir en su calidad. Mejores prácticas de la industria , investigación académica y
Los estándares contribuyen a su capital intelectual y se basan en él.
Los orígenes de la Gestión de Servicios se encuentran en negocios de servicios tradicionales como

aerolíneas, bancos, hoteles y compañías telefónicas. Su práctica ha crecido con la
adopción por parte de las organizaciones de TI de un enfoque orientado al servicio para la gestión de TI
aplicaciones , infraestructura y procesos. Soluciones a problemas empresariales y
El apoyo a los modelos de negocio , estrategias y operaciones se encuentran cada vez más en el
forma de servicios. La popularidad de los servicios compartidos y la subcontratación ha
contribuyó al aumento del número de organizaciones que prestan servicios
proveedores , incluidas las unidades organizativas internas. Esto a su vez ha fortalecido
la práctica de la Gestión del Servicio y al mismo tiempo impuso una mayor
desafíos sobre él.
Página 30
2.2 ¿Qué son los servicios?
2.2.1 La propuesta de valor
Definición de servicio
Un servicio es un medio de entrega de valor a los clientes mediante la facilitación de resultado s

los clientes quieren lograr, sin la propiedad de costos y riesgos específicos .
Los servicios son un medio de ofrecer valor a los clientes al facilitar los resultados.
los clientes quieren lograr, sin la propiedad de costos y riesgos específicos.
Los servicios facilitan los resultados al mejorar el desempeño de las tareas asociadas
y reducir el efecto de las limitaciones. El resultado es un aumento en la probabilidad
de los resultados deseados.
Figura 2.1 Una conversación sobre la definición y el significado de servicios
Página 31
2.3 Funciones y procesos a lo largo del ciclo de vida
2.3.1 Funciones
Las funciones son unidades de organizaciones especializadas para realizar ciertos tipos de trabajo.
y responsable de los resultados específicos . Son autónomos, con capacidades
y recursos necesarios para su desempeño y resultados. Capacidades
incluir métodos de trabajo internos a las funciones. Las funciones tienen su propio cuerpo de
conocimiento, que se acumula a partir de la experiencia. Proporcionan estructura y
estabilidad a las organizaciones.
Las funciones son un medio de estructurar las organizaciones para implementar la

principio de especialización. Las funciones normalmente definen roles y los asociados
autoridad y responsabilidad por un desempeño y resultados específicos.
La coordinación entre funciones a través de procesos compartidos es un patrón común
en diseño organizacional . Las funciones tienden a optimizar sus métodos de trabajo a nivel local, a
centrarse en los resultados asignados. Mala coordinación entre funciones, combinadas
con un enfoque hacia adentro, conduce a silos funcionales que dificultan la alineación y la retroalimentación
fundamental para el éxito de la organización en su conjunto. Los modelos de proceso ayudan a evitar
este problema con las jerarquías funcionales mediante la mejora de funciones cruzadas
coordinación y control . Los procesos bien definidos pueden mejorar la productividad dentro
y entre funciones.
2.3.2 Procesos
Los procesos son ejemplos de sistemas de circuito cerrado porque proporcionan cambios
y transformación hacia una meta y utilizar la retroalimentación para autorreforzarse y
acción de autocorrección (ver Figura 2.2). Es importante considerar la totalidad
proceso o cómo un proceso encaja en otro.
Figura 2.2 Un proceso básico
Página 32
Las definiciones de proceso describen acciones, dependencias y secuencia. Procesos

tienen las siguientes características:
• Medible: podemos medir el proceso de manera relevante. Eso

está impulsado por el rendimiento. Los gerentes quieren medir el costo , la calidad y otros
variables, mientras que los profesionales se preocupan por la duración y la productividad.
• Resultados específicos: la razón por la que existe un proceso es para entregar un
resultado. Este resultado debe ser identificable y contable individualmente. Mientras nosotros
puede contar con los cambios, es imposible contar el número de la mesa de servicio s
se completaron.
• Cliente s: cada proceso entrega sus resultados primarios a un cliente o
accionista . Pueden ser internos o externos a la organización, pero el
El proceso debe cumplir con sus expectativas.
• Responde a un evento específico : si bien un proceso puede estar en curso o
iterativo, debe ser rastreable hasta un desencadenante específico.
Las funciones a menudo se confunden con procesos. Por ejemplo, hay

conceptos erróneos sobre la gestión de la capacidad como una gestión de servicios
proceso. Primero, la Gestión de la Capacidad es una capacidad organizativa con
procesos y métodos de trabajo especializados. Ya sea una función o un proceso
depende enteramente del diseño de la organización. Es un error asumir que Capacidad
La gestión solo puede ser un proceso. Es posible medir y controlar
capacidad y para determinar si es adecuada para un propósito determinado. Asumiendo
que siempre sea un proceso , con resultados contables discretos , puede ser un error .
2.3.3 Especialización y coordinación a lo largo del ciclo de vida
La especialización y la coordinación son necesarias en el enfoque del ciclo de vida .

Retroalimentación y control entre las funciones y los procesos dentro y fuera de
los elementos del ciclo de vida lo hacen posible. El patrón dominante en el
El ciclo de vida es el progreso secuencial desde SS hasta SD-ST-SO y viceversa.
a SS a través de CSI. Sin embargo, ese no es el único patrón de acción. Cada elemento
del ciclo de vida proporciona puntos para la retroalimentación y el control.
La combinación de múltiples perspectivas permite una mayor flexibilidad y control

a través de entornos y situaciones. El enfoque del ciclo de vida imita la realidad de
la mayoría de las organizaciones donde la gestión eficaz requiere el uso de múltiples
perspectiva de control s. Los responsables del diseño , desarrollo y
La mejora de los procesos para la Gestión de servicios puede adoptar un proceso basado
perspectiva de control. Los responsables de la gestión de acuerdos , contratos y
Los servicios pueden ser mejor atendidos por una perspectiva de control basada en el ciclo de vida con
distintas fases. Estos dos puntos de vista de control se benefician del sistema de pensamiento s.
Cada perspectiva de control puede revelar patrones que pueden no ser evidentes desde el
otro.
Página 33
2.4 Fundamentos de la operación del servicio

2.4.1 Propósito / meta / objetivo
El propósito de la Operación del Servicio es coordinar y realizar las actividades y

Procesos necesarios para prestar y gestionar servicios en los niveles acordados para la empresa.
usuarios y clientes . La operación del servicio también es responsable de la
gestión de la tecnología que se utiliza para prestar y dar soporte a los servicios.
Los procesos bien diseñados e implementados serán de poco valor si el día a día
El funcionamiento diario de esos procesos no se lleva a cabo, controla y
administrado. Tampoco serán posibles mejoras en el servicio si las actividades diarias para
monitorear el desempeño , evaluar métricas y recopilar datos no son sistemáticamente
realizado durante la operación de servicio.
2.4.2 Alcance
La operación del servicio incluye la ejecución de todas las actividades en curso necesarias para
prestar y apoyar los servicios. El alcance de la operación del servicio incluye:
• Los propios servicios. Cualquier actividad que forme parte de un servicio es

incluido en la Operación del Servicio, ya sea que lo realice el Servicio
Proveedor, un proveedor externo o el usuario o cliente de ese servicio
• Procesos de gestión de servicios. La gestión continua y
La ejecución de muchos procesos de Gestión de servicios se realiza en
Operación del servicio, aunque varios procesos ITIL (como
Gestión de Cambios y Capacidad) se originan en el Diseño del Servicio o
Etapa de transición del servicio del ciclo de vida del servicio , están en uso
continuamente en operación de servicio. Algunos procesos no están incluidos
específicamente en la Operación del Servicio, como la Definición de la Estrategia , la
proceso de diseño en sí. Estos procesos se centran más en el largo plazo.
actividades de planificación y mejora, que están fuera del alcance directo de
Operación de servicio; sin embargo, la operación del servicio proporciona información y
influye en ellos regularmente como parte del ciclo de vida de la Gestión de servicios.
• Tecnología. Todos los servicios requieren algún tipo de tecnología para ofrecerlos.
La gestión de esta tecnología no es un tema aparte, sino una parte integral de
la gestión de los propios servicios. Por lo tanto, una gran parte de este
La publicación se ocupa de la gestión de la infraestructura utilizada.
para prestar servicios.
• Gente. Independientemente de los servicios, procesos y tecnología
administrado, se trata de personas. Son las personas las que impulsan la demanda de
la organización ‘s servicios y productos y es la gente que decide cómo
esto se hará. En última instancia, son las personas las que gestionan la tecnología,
procesos y servicios. No reconocer esto resultará (y ha
dado) en el fracaso de los proyectos de Gestión del Servicio s
Página 34
2.4.3 Valor para el negocio
Cada etapa del ciclo de vida del servicio ITIL proporciona valor a la empresa. Por ejemplo,
el valor del servicio se modela en la estrategia del servicio ; se diseña el costo del servicio ,
predicho y validado en el diseño del servicio y la transición del servicio ; y medidas
para la optimización se identifican en la Mejora Continua del Servicio . El funcionamiento de
El servicio es donde se ejecutan estos planes , diseños y optimizaciones y
Medido. Desde el punto de vista del cliente , la operación del servicio es donde el valor real
es visto.
Sin embargo, hay un lado negativo de esto:
• Una vez que se ha diseñado y probado un servicio, se espera que se ejecute dentro de
los objetivos presupuestarios y de retorno de la inversión establecidos anteriormente en el
ciclo de vida . En realidad, sin embargo, muy pocas organizaciones planifican eficazmente la
costos de la gestión continua de los servicios. Es muy fácil cuantificar la
costos de un proyecto, pero es muy difícil cuantificar lo que costará el servicio
después de tres años de funcionamiento.
• Es difícil obtener financiación durante la fase operativa , arreglar el diseño
defectos o requisitos imprevistos s - ya que esto no era parte del original
propuesta de valor. En muchos casos es solo después de algún tiempo en funcionamiento.
que estos problemas surgen. La mayoría de las organizaciones no tienen un
mecanismo para revisar los servicios operativos para su diseño y valor. Esto queda
a la Gestión de Incidentes y Problemas para resolverlos, como si fuera puramente un
problema operativo.
• Es difícil obtener fondos adicionales para herramientas o acciones (incluyendo
capacitación) con el objetivo de mejorar la eficiencia de la Operación del Servicio. Este es
en parte porque no están directamente vinculados a la funcionalidad de un
servicio y en parte porque hay una expectativa del cliente de que
Estos costos deberían haberse incorporado al costo del servicio desde el
comenzando. Desafortunadamente, la tasa de cambio tecnológico es muy alta.
Poco después de que se haya implementado una solución que gestionará de manera eficiente un
conjunto de servicios, se dispone de nueva tecnología que puede hacerlo más rápido,
más barato y más eficaz.
• Una vez que un servicio ha estado operativo durante algún tiempo, pasa a formar parte del
línea de base de lo que la empresa espera de los servicios de TI . Intenta
optimizar el servicio o utilizar nuevas herramientas para gestionarlo de forma más eficaz.
visto como exitoso solo si el servicio ha sido muy problemático en el
pasado. En otras palabras, algunos servicios se dan por sentados y cualquier acción
optimizarlos se percibe como 'arreglar servicios que no están rotos'.
Esta publicación sugiere una serie de procesos, funciones y medidas que

tienen como objetivo abordar estas áreas.
Página 35
2.4.4 Optimización del rendimiento de la operación del servicio
La operación del servicio se optimiza de dos maneras:
• Mejora incremental a largo plazo. Esto se basa en evaluar el
rendimiento y salida de todos los procesos, funciones y funciones de operación del servicio
salidas a lo largo del tiempo. Los informes se analizan y se toma una decisión sobre
si se necesitan mejoras y, de ser así, cuál es la mejor manera de implementarlas
a través del Diseño y la Transición del Servicio. Los ejemplos incluyen la implementación
de un nuevo conjunto de herramientas, cambios en los diseños de procesos , reconfiguración del
infraestructura, etc. Este tipo de mejora se trata en detalle en el
Publicación de mejora continua del servicio.
• Mejora continua a corto plazo de las prácticas laborales dentro del
Procesos de operación del servicio, funciones y tecnología en sí. Estos son
mejoras generalmente más pequeñas que se implementan sin ningún cambio
a la naturaleza fundamental de un proceso o tecnología. Ejemplos incluyen
puesta a punto , equilibrio de la carga de trabajo , reasignación y formación de personal, etc.
Aunque ambos se analizan con cierto detalle dentro del alcance del Servicio
Operación, la publicación de Mejora Continua del Servicio proporcionará una
marco y alternativas dentro de las cuales la mejora puede ser impulsada como parte de
el apoyo general de los objetivos comerciales s.
2.4.5 Procesos dentro de la operación del servicio
Hay una serie de procesos clave de Operación del Servicio que deben vincularse
para proporcionar una estructura de soporte de TI general eficaz. La estructura general es brevemente
descrito aquí y luego cada uno de los procesos se describe con más detalle en
Capítulo 4.
2.4.5.1 Gestión de eventos
Event Management monitorea todos los eventos que ocurren en todo el departamento de TI
infraestructura , para monitorear el funcionamiento normal y para detectar y escalar excepciones
condiciones.
2.4.5.2 Gestión de incidentes y problemas
La gestión de incidentes se concentra en restaurar

interrumpió los servicios a los usuarios lo más rápido posible, con el fin de minimizar el negocio
impacto .
La gestión de problemas implica: análisis de la causa raíz para determinar y resolver la

causa de los incidentes , actividades proactivas para detectar y prevenir futuros
problemas / incidentes y un subproceso de error conocido para permitir un diagnóstico más rápido
y resolución si ocurren más incidentes.
Página 36
2.4.5.3 Cumplimiento de la solicitud
El cumplimiento de solicitudes es el proceso para tratar las solicitudes de servicio , muchas de las cuales
en realidad , cambios más pequeños y de menor riesgo , inicialmente a través del Service Desk , pero
utilizando un proceso separado similar al de Gestión de incidentes pero con
Tablas / registros de solicitud de cumplimiento separados , cuando sea necesario, vinculados al
Registro (s) de incidente o problema que inició la necesidad de la solicitud. Ser un
Solicitud de servicio, es normal que se definan y cumplan algunos requisitos previos (p. Ej.
necesita ser probado, repetible, preaprobado, procesado).
Para resolver una o más incidencias, problemas o Errores conocidos, alguna forma
de cambio puede ser necesario. Se pueden manejar cambios más pequeños, a menudo estándar
a través de un proceso de cumplimiento de solicitudes, pero más grande, de mayor riesgo o poco frecuente
los cambios deben pasar por un proceso formal de gestión del cambio .
2.4.5.4 Gestión de acceso
La gestión de acceso es el proceso de otorgar a los usuarios autorizados el derecho a utilizar

un servicio , al tiempo que restringe el acceso a usuarios no autorizados. Se basa en ser
capaz de identificar con precisión a los usuarios autorizados y luego gestionar su capacidad para
acceder a los servicios según sea necesario durante las diferentes etapas de sus Recursos Humanos
(RRHH) o ciclo de vida contractual . La gestión de acceso también se ha denominado Identidad
o Gestión de derechos en algunas organizaciones.
2.4.6 Funciones dentro de la operación del servicio
Los procesos por sí solos no darán como resultado una Operación del Servicio eficaz . Un establo
También se necesitan infraestructura y personal debidamente capacitado. Conseguir
Esto, la Operación del Servicio se basa en varios grupos de personas capacitadas, todas enfocadas en
utilizar procesos para adaptar la capacidad de la infraestructura a las necesidades del
negocio.
Estos grupos se dividen en cuatro funciones principales , enumeradas aquí y discutidas en detalle en
Capítulo 6.
2.4.6.1 Mesa de servicio
El Service Desk es el punto de contacto principal para los usuarios cuando hay un servicio.
interrupción, para solicitudes de servicio , o incluso para algunas categorías de solicitudes de
Cambiar . El Service Desk proporciona un punto de comunicación a los usuarios y un
punto de coordinación para varios grupos y procesos de TI
2.4.6.2 Gestión técnica
La gestión técnica proporciona las habilidades técnicas detalladas y los recursos necesarios.
para respaldar el funcionamiento continuo de la infraestructura de TI . Manejo tecnico
Página 37
también juega un papel importante en el diseño , prueba, lanzamiento y mejora de TI

Servicio s. En organizaciones pequeñas, es posible gestionar esta experiencia en un
un solo departamento, pero las organizaciones más grandes suelen dividirse en varios
Departamentos técnicamente especializados.
2.4.6.3 Gestión de operaciones de TI
La gestión de operaciones de TI ejecuta las actividades operativas diarias necesarias para

administrar la infraestructura de TI. Esto se hace de acuerdo con el Performance
Estándares definidos durante el Diseño del Servicio . En algunas organizaciones, se trata de una
departamento centralizado, mientras que en otros algunas actividades y personal están centralizados
y algunos son proporcionados por departamentos distribuidos o especializados. Operaciones de TI
La administración tiene dos funciones que son únicas y generalmente formales
Estructuras organizacionales. Estos son:
• Control de operaciones de TI , que generalmente está compuesto por turnos de operadores y

lo que garantiza que se lleven a cabo las tareas operativas de rutina. Operaciones de TI
Control también proporcionará actividades de seguimiento y control centralizadas ,
generalmente usando un Puente de Operaciones o un Centro de Operaciones de Red.
• La gestión de instalaciones se refiere a la gestión de la TI física.
entorno , generalmente centros de datos o salas de informática. En muchos
Las organizaciones de Gestión Técnica y de Aplicaciones están ubicadas junto con
Operaciones de TI en grandes centros de datos.
2.4.6.4 Gestión de aplicaciones
La administración de aplicaciones es responsable de administrar las aplicaciones en todo

su ciclo de vida. La función de gestión de aplicaciones admite y mantiene
aplicaciones operativas y también juega un papel importante en el diseño, pruebas
y mejora de aplicaciones que forman parte de los servicios de TI. Solicitud
La administración generalmente se divide en departamentos según la aplicación
portafolio de la organización , permitiendo así una especialización más fácil y más enfocada
apoyo.
2.4.6.5 Interfaces con otras etapas del ciclo de vida de la gestión de servicios
Hay varios otros procesos que se ejecutarán o admitirán durante

Operación del servicio , pero que se controlan durante otras fases del servicio.
Ciclo de vida de la gestión . Estos se discutirán en la parte final del Capítulo 4 y
incluir:
• Gestión del cambio , que es un proceso importante que debe ser de cerca
vinculado a la gestión de la configuración y la gestión de versiones . Estos
Los temas se tratan principalmente en la publicación Transición del servicio .
• Gestión de la capacidad y la disponibilidad , que se tratan en el Servicio
Publicación de diseño.
Página 38
• Gestión financiera , que se cubre en la Estrategia de servicio.

publicación.
• Gestión del conocimiento, que se cubre en la Transición del servicio
publicación.
• Continuidad del servicio de TI , que se trata en la publicación Diseño del servicio .
• Servicio de informe y medición, que están cubiertos en el continuo
Publicación de mejora del servicio .
Página 39
3 Principios de funcionamiento del servicio

Al considerar la operación del servicio , es tentador centrarse solo en la gestión
las actividades del día a día y la tecnología como fines en sí mismos. Sin embargo, Service
La operación existe dentro de un contexto mucho mayor. Como parte de la gestión de servicios
Ciclo de vida, se encarga de ejecutar y realizar procesos que optimicen
el costo y la calidad de los servicios. Como parte de la organización , es responsable de
Permitir que la empresa cumpla con sus objetivos s. Como parte del mundo de la tecnología,
es responsable del funcionamiento eficaz de los componentes que apoyan los servicios.
Los principios de este capítulo están destinados a ayudar a la operación del servicio.
profesionales para lograr un equilibrio entre todos estos roles y centrarse en
gestionar eficazmente los aspectos del día a día manteniendo una perspectiva de
el contexto mayor.
Página 40
3.1 Funciones, grupos, equipos, departamentos y divisiones
La publicación Service Operation utiliza varios términos para referirse a la forma en que
las personas están organizadas para ejecutar procesos o actividades. Hay varios
definiciones publicadas para cada término y no es el propósito de esta publicación
entrar en el debate sobre cuál es la mejor definición. Tenga en cuenta que lo siguiente
las definiciones son genéricas y no prescriptivas. Se proporcionan simplemente para definir
supuestos y para facilitar la comprensión del material. El lector debe
adaptar estos principios a las prácticas organizativas que se utilizan en sus propias
organización.
• Función : una función es un concepto lógico que se refiere a las personas y

medidas automatizadas que ejecutan un proceso definido, una actividad o un
combinación de procesos o actividades. En organizaciones más grandes, una función
puede ser desglosado y realizado por varios departamentos, equipos y
grupos, o puede estar incorporado dentro de una sola unidad organizativa (p. ej.
Mesa de servicio ). En organizaciones más pequeñas, una persona o grupo puede realizar
múltiples funciones, por ejemplo, un departamento de gestión técnica también podría
incorporar la función Service Desk.
• Grupo: un grupo es un número de personas que son similares de alguna manera. En
En esta publicación, los grupos se refieren a personas que realizan actividades similares -
a pesar de que pueden trabajar en diferentes tecnologías o informar a diferentes
estructuras organizativas o incluso en diferentes empresas. Los grupos son
no suelen ser estructuras organizativas formales , pero son muy útiles para definir
procesos comunes en toda la organización, por ejemplo, garantizar que todas las personas
quienes resuelven incidentes completan el Registro de Incidentes de la misma manera. En
En esta publicación, el término 'grupo' no se refiere a un grupo de empresas.
que son propiedad de la misma entidad.
• Equipo: Un equipo es un tipo de grupo más formal. Estas son personas que trabajan
juntos para lograr un objetivo común , pero no necesariamente en el mismo
estructura de organización. Los miembros del equipo pueden estar ubicados o trabajar en
múltiples ubicaciones diferentes y operar virtualmente. Los equipos son útiles para
colaboración, o para hacer frente a una situación de carácter temporal o transitorio
naturaleza. Los ejemplos de equipos incluyen equipos de proyectos , desarrollo de aplicaciones
equipos (a menudo formados por personas de varias unidades de negocio diferentes)
y equipos de resolución de incidentes o problemas .
• Departamento: los departamentos son estructuras organizativas formales que existen
para realizar un conjunto específico de actividades definidas de forma continua.
Los departamentos tienen una estructura jerárquica de informes con gerentes que
suelen ser responsables de la ejecución de las actividades y también del día-
gestión actual del personal del departamento.
• División: una división se refiere a una serie de departamentos que se han
agrupados, a menudo por geografía o línea de productos. Una división es
normalmente autónomo y es capaz de planificar y ejecutar todas las actividades en un
cadena de suministro .
Página 41
• Rol : un rol se refiere a un conjunto de comportamientos o acciones conectados que son

realizado por una persona, equipo o grupo en un contexto específico. Por ejemplo,
un departamento de Gestión Técnica puede desempeñar el papel de Problema
Gestión al diagnosticar la causa raíz de las incidencias. Este mismo
También podría esperarse que el departamento desempeñe varios otros roles en diferentes
veces, por ejemplo, puede evaluar el impacto de los cambios ( Gestión de cambios
función), gestionar el rendimiento de los dispositivos bajo su control (Capacidad
Rol gerencial), etc. El alcance de su rol y lo que los impulsa a
desempeñan ese papel están definidos por el proceso relevante y acordados por su línea
gerente.
Página 42
3.2 Lograr el equilibrio en la operación del servicio
La operación del servicio es más que la ejecución repetitiva de un conjunto estándar de

procedimientos o actividades. Todas las funciones , procesos y actividades están diseñados para
prestar un nivel de servicios especificado y acordado, pero deben entregarse en
un entorno en constante cambio .
Esto forma un conflicto entre mantener el status quo y adaptarse a

cambios en el entorno empresarial y tecnológico. Uno de servicio
Por lo tanto, el papel clave de la operación es hacer frente a este conflicto y lograr un
equilibrio entre conjuntos de prioridades en conflicto.
Esta sección de la publicación destaca algunas de las tensiones y conflictos clave

e identifica cómo las organizaciones de TI pueden reconocer que están sufriendo un
desequilibrio al tender más hacia un extremo o hacia el otro. También proporciona
algunas pautas de alto nivel sobre cómo resolver el conflicto y así avanzar hacia
un enfoque de mejores prácticas. Por tanto, todo conflicto representa una oportunidad para
crecimiento y mejora.
3.2.1 Vista de TI interna versus vista de negocio externa
El conflicto más fundamental en todas las fases del ciclo de vida de ITSM es entre el
visión de TI como un conjunto de servicios de TI (la visión empresarial externa) y la visión de TI
como un conjunto de componentes tecnológicos (visión de TI interna).
• La visión externa de TI es la forma en que los servicios son experimentados por sus
usuarios y clientes . No siempre entienden, ni les importa
sobre, los detalles de qué tecnología se utiliza para administrar esos servicios.
Lo único que les preocupa es que los servicios se presten según sea necesario.
y estuvo de acuerdo.
• La visión interna de TI es la forma en que los componentes y sistemas de TI se
logró entregar los servicios. Dado que los sistemas de TI son complejos y
diversa, esto a menudo significa que la tecnología es administrada por varios
diferentes equipos o departamentos, cada uno de los cuales se centra en lograr
buen rendimiento y disponibilidad de "sus" sistemas.
Ambos puntos de vista son necesarios para la prestación de servicios. La organización que
se centra solo en los requisitos comerciales sin pensar en cómo van
cumplir terminará haciendo promesas que no se pueden cumplir. La organización que
se centra solo en los sistemas internos sin pensar en los servicios que
El soporte terminará con servicios costosos que ofrecen poco valor.
El potencial de conflicto de roles entre los puntos de vista externo e interno es el resultado
de muchas variables, incluida la madurez de la organización, su gestión
cultura , su historia, etc. Esto hace que un equilibrio sea difícil de lograr, y la mayoría
las organizaciones tienden más hacia un rol que hacia el otro. Claro que no
Página 43
La organización estará totalmente enfocada interna o externamente, pero se encontrará en un

posición a lo largo de un espectro entre los dos. Esto se ilustra en la Figura 3.1:
Figura 3.1 Lograr un equilibrio entre el enfoque externo e interno
La Tabla 3.1 describe algunos ejemplos de las características de los puestos en el

extremos extremos del espectro. El propósito de esta tabla es ayudar a las organizaciones
en identificar a qué extremo están más cerca, no en identificar posiciones de la vida real para
qué organizaciones deben aspirar.
Enfoque interno extremo Enfoque externo extremo
Enfoque principal Desempeño y gestión de TI Alcanzar altos niveles de servicio de TI

Dispositivos de infraestructura , sistemas y rendimiento con poca consideración de cómo
personal, con poca atención al final se logra
resultado en el servicio de TI
Métrica s • Centrarse en lo técnico • Enfoque en la externa métrica s

rendimiento sin mostrar sin mostrar personal interno
lo que esto significa para los servicios cómo se derivan o cómo
• Métricas internas (p. Ej., Red se pueden mejorar
uptime) informado al • Se espera que el personal interno
negocio en lugar de servicio diseñar sus propias métricas para
métricas de rendimiento . medir interna
rendimiento.
Cliente / usuario • Alta consistencia de entrega, • Mala consistencia de la entrega

experiencia pero solo entrega un • 'Se compone de buena gente
porcentaje de lo que con buenas intenciones, pero
Necesidades del negocio. no siempre se puede ejecutar '
• Utiliza un enfoque de 'empuje' para • Modo de funcionamiento reactivo .
entrega, es decir, prefiere tener • Utiliza un enfoque de 'tracción' para
un conjunto estándar de servicios para entrega, es decir, prefiere entregar
servicios personalizados sobre
Página 44
todas las unidades de negocio . petición
Operaciones • Operaciones estándar en • Múltiples equipos de entrega y

estrategia el tablero múltiples tecnologías
• Todos los nuevos servicios deben adaptarse • Las nuevas tecnologías requieren
en la arquitectura actual nuevos enfoques de operaciones
y procedimiento s. y, a menudo, nuevas operaciones de TI
equipos.
Procedimientos y Céntrese exclusivamente en cómo gestionar la Se centra principalmente en lo que necesita

manual tecnología, no en cómo su hacerse y cuando y menos en como
el rendimiento se relaciona con los servicios de TI esto debe lograrse
Estrategia de costos • Reducción de costos lograda • Presupuesto asignado sobre la base

puramente a través de la tecnología de qué unidad de negocio es
consolidación percibido como el que tiene más
• Optimización de operativa necesitar
procedimientos y recursos s • Menos articulado o vocal
• Impacto empresarial del costo las unidades de negocio a menudo tienen
cortar a menudo solo se entiende servicios inferiores como hay
más tarde fondos insuficientes asignados
• Retorno de la inversión a sus servicios.
los cálculos están enfocados
puramente en el ahorro de costes o
'períodos de recuperación'.
Capacitación La formación se lleva a cabo como • La formación se lleva a cabo en un

aprendizaje, donde nuevo proyecto por proyecto
El personal de operaciones debe aprender • No hay estándar
cómo se deben hacer las cosas, no por qué cursos de formación desde
procedimiento
la tecnología esoperativo
constantesy
cambiando.
Personal de operaciones • Personal especializado, organizado • Personal generalista, organizado

según técnica en parte de acuerdo con la técnica
especialidad capacidad y en parte
• El personal trabaja en lo falso según su relación
suposición de que bueno con una unidad de negocio
el logro técnico es el • Confianza en 'heroicidad', donde
lo mismo que un buen cliente el personal hace todo lo posible para
servicio . resolver problemas que podrían
han sido prevenidos por
mejores procesos internos .
Cuadro 3.1 Ejemplos de enfoque interno y externo extremo
Esto no significa que el enfoque externo no sea importante. Todo el punto de

La Gestión de Servicios es proporcionar servicios que cumplan con los objetivos de la
Página 45
organización en su conjunto. Es fundamental estructurar los servicios en torno a los clientes. A

Al mismo tiempo, es posible comprometer la calidad de los servicios al no pensar
sobre cómo se entregarán.
Operación de servicios de edificios con equilibrio entre enfoque interno y externo

Requiere un enfoque dedicado a largo plazo que se refleja en todas las fases del ITSM.
Ciclo de vida del servicio . Esto requerirá lo siguiente:
• Comprensión de los servicios que utiliza la empresa y por qué.

• Comprensión de la importancia relativa y el impacto de esos servicios.
en el negocio.
• Comprensión de cómo se utiliza la tecnología para proporcionar servicios de TI .
• Participación de la operación del servicio en la mejora continua del servicio
proyectos que tienen como objetivo identificar formas de brindar más, aumentar el servicio
calidad y menor costo .
• Procedimientos y manuales que describen la función de las operaciones de TI tanto en la
gestión de tecnología y prestación de servicios de TI.
• Un conjunto de métricas claramente diferenciadas para informar a la empresa sobre el
logro de los objetivos del servicio; e informar a los gerentes de TI sobre la
eficiencia y efectividad de la Operación del Servicio.
• Todo el personal de operaciones de TI comprende exactamente cómo funciona el
La tecnología afecta la prestación de servicios de TI y, a su vez, cómo estos afectan
el negocio y los objetivos comerciales.
• Un conjunto de servicios estándar entregados de manera consistente a todas las Unidades de Negocio y
un conjunto de servicios no estándar (a veces personalizados) entregados a
Unidades de negocio específicas, junto con un conjunto de
Procedimientos (POE) que pueden cumplir con ambos conjuntos de requisitos .
• Una estrategia de costos destinada a equilibrar los requisitos de diferentes negocios.
unidades con los ahorros de costos disponibles a través de la optimización de
tecnología o inversión en nueva tecnología, y una comprensión de la
estrategia de costos por todos los recursos de TI involucrados .
•
•
Una estrategia de retorno de la inversión basada en el valor, más que en los costos .
Participación del personal de operaciones de TI en el diseño y el servicio del servicio
Fases de transición del ciclo de vida de ITSM .
• Aportes y comentarios de la mejora continua del servicio para identificar
áreas donde existe un desequilibrio y los medios para identificar y hacer cumplir
mejora.
• Un claro plan de comunicación y formación para empresas. Mientras que muchos
las organizaciones son buenas en el desarrollo de planes de comunicación para proyectos ,
esto a menudo no se extiende a su fase operativa .
3.2.2 Estabilidad versus capacidad de respuesta
No importa qué tan buena sea la funcionalidad de un servicio de TI y no importa qué tan bien
ha sido diseñado, valdrá mucho menos si los componentes del servicio no son
disponibles o si funcionan de manera inconsistente.
Página 46
Esto significa que la Operación del Servicio debe garantizar que la Infraestructura de TI esté
estable y disponible según lo diseñado. Al mismo tiempo, la operación del servicio debe
reconocer que los requisitos de TI y de negocio cambian.
Algunos de estos cambios son evolutivos. Por ejemplo, la funcionalidad,

el rendimiento y la arquitectura de una plataforma pueden cambiar durante varios años.
Cada cambio trae consigo la oportunidad de brindar mejores niveles de servicio al
negocio. En los cambios evolutivos, es posible planificar cómo responder a las
cambiar y así mantener la estabilidad mientras responde a los cambios.
Sin embargo, muchos cambios ocurren muy rápidamente y, a veces, bajo condiciones extremas.
presión. Por ejemplo, una unidad de negocio gana inesperadamente un contrato que
requiere servicios de TI adicionales, más capacidad y tiempos de respuesta más rápidos . los
La capacidad de responder a este tipo de cambio sin afectar a otros servicios es una
desafío significativo.
Muchas organizaciones de TI no pueden lograr este equilibrio y tienden a centrarse en

ya sea la estabilidad de la infraestructura de TI o la capacidad de responder a los cambios
con rapidez.
Figura 3.2 Lograr un equilibrio entre el enfoque en la estabilidad y la capacidad de respuesta
La Tabla 3.2 describe algunos ejemplos de las características de las posiciones en extremos
extremos del espectro. El propósito de esta tabla es ayudar a las organizaciones a
identificar a qué extremo están más cerca, no identificar posiciones de la vida real para
Página 47
Enfoque extremo en la estabilidad Enfoque extremo en la capacidad de respuesta
Enfoque primario • Tecnología • Salida a la empresa

• Desarrollando y refinando • Acepta los cambios requeridos
gestión de TI estándar antes de determinar lo que
técnicas y procesos es. Tardará en entregarlos.
Típico Puede demostrar que es El personal de TI no está disponible para definir o

problema s cumpliendo con los POE y operativos ejecutar tareas de rutina porque
experimentado Nivel de acuerdo s (OLA), incluso están ocupados en proyectos para nuevos servicios
cuando hay una clara desalineación
requisitos comerciales s
Tecnología • Estrategia de crecimiento basada en • Tecnología comprada para

estrategia de crecimiento analizar la demanda existente en cada nuevo negocio
existente del sistema s requisito
• Se resisten nuevos servicios • Usando múltiples tecnologías
y Unidad de Negocio s y soluciones para similares
a veces tomar posesión de soluciones, para encontrar un poco
'sus propios' sistemas para obtener diferentes necesidades comerciales.
acceso a nuevos servicios.
Tecnología Tecnología existente o estándar que se Sobreaprovisionamiento. Ningún intento es

solía entregar usado; los servicios deben ajustarse a hecho para modelar el nuevo servicio en
Servicio de s trabajar dentro de los parámetros existentes la infraestructura existente. Nuevo,
se compra tecnología dedicada
para cada nuevo proyecto
Capacidad • Previsiones basadas en • Previsiones basadas en el futuro

administración proyecciones de corriente actividad empresarial para cada
carga de trabajo s servicio individualmente y hacer
• El rendimiento del sistema es no tenerlo en cuenta
mantenido en constante actividad u otros servicios de TI
niveles a través de la sintonización y • Las cargas de trabajo existentes no
gestión de la demanda , no por pertinente.
previsión de carga de trabajo y
administración.
Tabla 3.2 Ejemplos de enfoque extremo en la estabilidad y la capacidad de respuesta
Construir una organización de TI que logre un equilibrio entre estabilidad y
La capacidad de respuesta en la operación del servicio requerirá las siguientes acciones:
• Garantizar la inversión en tecnologías y procesos que sean adaptables en lugar de

que rígido, por ejemplo, servidor virtual y tecnología de aplicaciones y el uso de
Cambie los modelos (consulte la publicación Transición del servicio ).
• Cree un proceso sólido de gestión del nivel de servicio (SLM) que esté activo
desde la fase de Diseño del Servicio hasta la Mejora Continua del Servicio
fase del ciclo de vida de ITSM .
Página 48
• Fomentar la integración entre SLM y los demás procesos de diseño de servicios.

para garantizar el mapeo adecuado de los requisitos comerciales para las operaciones de TI
actividades y componentes de la infraestructura de TI . Esto hace que sea más fácil
Modelar el efecto de cambios y mejoras.
• Inicie los cambios en la etapa más temprana adecuada en el ciclo de vida de ITSM.
Esto garantizará que tanto la funcionalidad (empresarial) como la capacidad de gestión (TI
los requisitos operativos) pueden evaluarse y construirse o cambiarse juntos.
• Garantizar la participación de TI en los cambios comerciales lo antes posible en el
Cambiar el proceso para garantizar la escalabilidad , la coherencia y la viabilidad de la TI.
servicios que sustentan los cambios comerciales.
• Los equipos de operación del servicio deben proporcionar información sobre el diseño en curso y
refinamiento de la arquitectura y los servicios de TI (consulte Diseño de servicios y
Publicaciones de estrategia de servicio).
• Implemente y use SLM para evitar situaciones en las que el negocio y la TI
los gerentes y el personal negocian acuerdos informales s.
3.2.3 Calidad de servicio versus costo de servicio
La operación del servicio se requiere de manera constante para brindar el nivel acordado de servicio de TI
a sus clientes y usuarios , mientras que al mismo tiempo mantiene los costos y los recursos
utilización a un nivel óptimo.
La Figura 3.3 representa la inversión realizada para brindar un servicio a

niveles de calidad .
Figura 3.3 Equilibrio entre la calidad y el costo del servicio
Página 49
En la Figura 3.3, un aumento en el nivel de calidad generalmente resulta en un aumento en

el costo de ese servicio y viceversa. Sin embargo, la relación no siempre es
directamente proporcional:
• Al principio del ciclo de vida del servicio, es posible lograr aumentos significativos
en calidad de servicio con una cantidad relativamente pequeña de dinero. Por ejemplo,
Mejorar la disponibilidad del servicio del 55% al 75% es bastante sencillo y
puede que no requiera una gran inversión.
• Más adelante en el ciclo de vida del servicio, incluso las pequeñas mejoras en la calidad son
muy caro. Por ejemplo, mejorar la disponibilidad del mismo servicio
del 96% al 99,9% puede requerir grandes inversiones en alta disponibilidad
tecnología y personal y herramientas de apoyo.
Si bien esto puede parecer sencillo, muchas organizaciones se encuentran bajo severa
presión para aumentar la calidad del servicio y reducir sus costos. En figura
3.3, la relación entre costo y calidad es a veces inversa. Es posible
(generalmente dentro del rango de optimización) para aumentar la calidad y reducir los costos.
Esto normalmente se inicia dentro de la Operación del servicio y se lleva adelante por
Servicio de Mejoramiento contínuo. Algunos costos se pueden reducir gradualmente
tiempo, pero la mayoría de los ahorros de costos se pueden hacer solo una vez. Por ejemplo, una vez
Se ha eliminado la herramienta de software duplicada, no se puede eliminar de nuevo por
mayores ahorros de costes.
Lograr un equilibrio óptimo entre costo y calidad (mostrado entre los

líneas de puntos en la Figura 3.3) es una función clave de la Gestión de servicios . No hay
estándar de la industria para lo que debería ser esta gama, ya que cada servicio tendrá un
diferente rango de optimización, dependiendo de la naturaleza del servicio y el
tipo de objetivo comercial que se está cumpliendo. Por ejemplo, el negocio puede ser
preparado para gastar más para lograr una alta disponibilidad en un servicio de misión crítica,
mientras está preparado para vivir con la menor calidad de una herramienta administrativa.
La determinación del equilibrio adecuado entre costo y calidad debe realizarse durante
las fases del ciclo de vida de la estrategia del servicio y el diseño del servicio , aunque en muchas
organizaciones se deja en manos de los equipos de operaciones de servicio , muchos de los cuales no
Generalmente tienen todos los hechos o autoridad para poder tomar este tipo de decisiones.
Desafortunadamente, también es común encontrar organizaciones que están gastando grandes

cantidades de dinero sin lograr mejoras claras en la calidad. Otra vez,
La Mejora Continua del Servicio podrá identificar la causa de la
ineficiencia, evaluar el equilibrio óptimo para ese servicio y formular una
plan correctivo .
Lograr el equilibrio correcto es importante. Demasiado enfoque en la calidad resultará
en servicios de TI que brindan más de lo necesario, a un costo más alto, y podrían conducir
a una discusión sobre la reducción del precio de los servicios. Demasiado enfoque en el costo
Página 50
dar lugar a la entrega de TI sobre o bajo presupuesto , pero poner el negocio en riesgo a través
servicios de TI de calidad inferior.
Nota especial: ¿qué tan lejos es demasiado?
Durante los últimos años, las organizaciones de TI han estado bajo presión para recortar
costos. En muchos casos, esto resultó en una optimización de los costos y la calidad . Pero, en otro
En algunos casos, los costos se redujeron hasta el punto en que la calidad comenzó a sufrir. Al principio, el
Los signos fueron sutiles: pequeños aumentos en los tiempos de resolución de incidentes y un ligero
aumento en el número de incidentes . Sin embargo, con el tiempo, la situación se volvió
más serio ya que el personal trabajaba muchas horas para manejar múltiples cargas de trabajo y
los servicios se ejecutaban en una infraestructura obsoleta o anticuada.
No existe un cálculo simple para determinar cuándo los costos se han reducido demasiado, pero
Un buen SLM es crucial para que los clientes sean conscientes del impacto de cortar demasiado,
por lo que reconocer estos signos y síntomas de advertencia puede mejorar en gran medida una
capacidad de la organización para corregir esta situación.
Requisitos de nivel de servicio s, junto con una clara comprensión de los

el propósito comercial del servicio y los riesgos potenciales: ayudará a garantizar que
el servicio se entrega al costo apropiado. También ayudarán a evitar 'más
dimensionamiento 'del servicio solo porque el presupuesto está disponible, o' dimensionamiento insuficiente 'porque
la empresa no comprende los requisitos de manejabilidad del
solución. Cualquiera de los resultados causará insatisfacción del cliente e incluso más gastos.
cuando la solución se rediseña o se adapta a los requisitos que deberían
se han especificado durante el diseño del servicio.
Figura 3.4 Lograr un equilibrio entre el enfoque en el costo y la calidad
La Tabla 3.3
extremos del describe
espectro algunos ejemplos
costo / calidad. Elde las características
propósito de es
de esta tabla lasayudar
posiciones en extremos
Página 51
organizaciones en identificar a qué extremo están más cerca, no en identificar real-

puestos de vida a los que deben aspirar las organizaciones.
Enfoque extremo en la calidad Enfoque extremo en el costo
Enfoque principal Ofrecer el nivel de calidad exigido Cumplir con el presupuesto y la reducción de costes s
por la empresa independientemente de lo que
acepta
Típico • Escalando presupuestos • Limita la calidad de

problema s • Los servicios de TI generalmente brindan servicio basado en su
experimentado más de lo necesario para disponibilidad de presupuesto
Éxito en el negocio • Escalada s desde el
• Aumento de las demandas de negocio para obtener más
servicios de calidad . servicio de TI.
Financiero Por lo general, no tiene un método de Los informes financieros se realizan puramente
administración comunicar el costo de los servicios de TI. sobre los montos presupuestados. No hay
Los métodos contables se basan en una forma de vincular las actividades en TI a la
método agregado (por ejemplo, costo de TI por prestación de servicios de TI.
usuario ).
Tabla 3.3 Ejemplos de enfoque extremo en la calidad y el costo
Lograr un equilibrio garantizará la entrega del nivel de servicio necesario para cumplir
los requisitos comerciales s a un costo óptimo (en contraposición al más bajo posible). Esta
requerirá lo siguiente:
• Un proceso de gestión financiera y herramientas que pueden dar cuenta del costo.
de proporcionar servicios de TI; y qué modelos de métodos alternativos de
prestación de servicios a diferentes niveles de costo. Por ejemplo, comparando el
costo de brindar un servicio con una disponibilidad del 98% o con una disponibilidad del 99,9%; o
el costo de proporcionar un servicio con o sin funcionalidad adicional.
• Asegurarse de que las decisiones en torno al costo versus la calidad sean tomadas por el
gerentes apropiados durante la Estrategia de Servicio y el Diseño de Servicio . ESO
Los gerentes operativos generalmente no están equipados para evaluar negocios.
oportunidades y solo se le debe pedir que tome decisiones financieras que
están relacionados con la consecución de eficiencias operativas.
3.2.4 Reactivo versus proactivo
Una organización reactiva es aquella que no actúa a menos que se le indique que lo haga.
por un controlador externo , por ejemplo, un nuevo requisito comercial, una aplicación que tiene
desarrollado o escalado en quejas presentadas por usuarios y clientes . Un
La desafortunada realidad en muchas organizaciones es el enfoque en la gestión reactiva.
erróneamente como el único medio para garantizar servicios que son altamente consistentes y
estable, desalentando activamente el comportamiento proactivo del personal operativo. los
La ironía desafortunada de este enfoque es que desalentar la inversión de esfuerzo en
Página 52
La gestión de servicios proactiva puede, en última instancia, aumentar el esfuerzo y el coste de

actividades reactivas y mayor estabilidad de riesgos y coherencia en los servicios.
Una organización proactiva siempre está buscando formas de mejorar el actual

situación. Analizará continuamente los entornos internos y externos , buscando
en busca de signos de cambios potencialmente impactantes. El comportamiento proactivo generalmente se ve como
positivo, especialmente porque permite a la organización mantener la competitividad
ventaja en un entorno cambiante. Sin embargo, ser demasiado proactivo puede ser
costoso y puede resultar en distracciones del personal. La necesidad de un equilibrio adecuado en
El comportamiento reactivo y proactivo a menudo logra el resultado óptimo.
Generalmente, es mejor administrar los servicios de TI de manera proactiva, pero lograrlo no es

planeado o logrado fácilmente. Esto se debe a que la creación de una organización de TI proactiva
depende de muchas variables, que incluyen:
• La madurez de la organización . Cuanto más tiempo ha estado la organización

entregando un conjunto consistente de servicios de TI, es más probable que comprenda
la relación entre TI y el negocio y la infraestructura de TI y
Servicios de TI.
• La cultura de la organización. Algunas organizaciones tienen una cultura que
centrados en la innovación y es más probable que sean proactivos. Otros son
es más probable que se centren en el statu quo y, como tal, es probable que se resistan
cambiar y tener un enfoque más reactivo.
• El papel que desempeña la TI en el negocio y el mandato que tiene para
influir en la estrategia y táctica del negocio. Por ejemplo, un
empresa donde el CIO es un miembro de la junta es probable que tenga un departamento de TI
organización que es mucho más proactiva y receptiva que una empresa
donde TI se ve como una sobrecarga administrativa .
• El nivel de integración de los procesos y herramientas de gestión. Niveles más altos
de integración facilitará un mejor conocimiento de las oportunidades.
• La madurez y alcance de la Gestión del Conocimiento en la organización;
esto se ve especialmente en organizaciones que han podido almacenar y
Organizar datos históricos de manera efectiva, especialmente Disponibilidad y Problema.
Gestión de datos.
Desde una perspectiva de madurez, está claro que las organizaciones más nuevas tendrán
diferentes prioridades y experiencias de una organización más establecida: ¿qué
Esta es la mejor práctica para una organización madura puede no ser adecuada para una organización más joven.
Por lo tanto, un desequilibrio podría resultar de que una organización sea menor o
mas maduro. Considera lo siguiente:
• Organizaciones menos maduras (u organizaciones con servicios de TI más nuevos o

tecnología) serán generalmente más reactivos, simplemente porque no
conocer todas las variables involucradas en el funcionamiento de su negocio y proporcionar TI
servicios.

Página 53
• El personal de TI en las organizaciones más nuevas tiende a ser generalista porque no está claro
exactamente lo que se requiere para brindar servicios de TI estables a la empresa.
• Los incidentes y problemas en las organizaciones más nuevas son bastante impredecibles
porque la tecnología es relativamente nueva y cambia rápidamente.
• Las organizaciones más maduras tienden a ser más proactivas, simplemente porque
Tienen más datos e informes disponibles y conocen los patrones típicos.
de incidencias y flujos de trabajo. Por lo tanto, pronostican excepciones con mucha más facilidad.
• El personal que trabaja en organizaciones maduras también suele tener más
relaciones establecidas entre el personal de TI y la empresa, por lo que pueden
más proactivo para cumplir con los requisitos comerciales cambiantes : esto es
especialmente cierto cuando la TI se considera un componente estratégico del negocio.
Figura 3.5 Lograr un equilibrio entre ser demasiado reactivo o demasiado proactivo
Página 54
La Tabla 3.4 describe algunos ejemplos de las características de las posiciones en extremos
extremos del espectro. El propósito de esta tabla es ayudar a las organizaciones a
identificar a qué extremo están más cerca, no identificar posiciones de la vida real para
Extremadamente reactivo Extremadamente proactivo
Enfoque primario Responde a las necesidades comerciales y Anticipa negocio requisito s

incidentes solo después de que se informan antes de que se notifiquen y problema s
antes de que ocurran
Típico • Preparándose para entregar nuevos • El dinero se gasta antes del

problemas los servicios llevan mucho tiempo se establecen los requisitos. En
experimentado porque cada proyecto es algunos casos TI compra artículos
tratado como si fuera el primero que nunca se usará porque
• Ocurren incidentes similares ellos anticiparon el mal
una y otra vez, ya que hay requisitos o porque el
no hay forma de marcarlas el proyecto está detenido
• La rotación de personal es alta y • El personal de TI tiende a estar en el
la moral es generalmente baja, ya que organización durante mucho tiempo y
El personal de TI sigue moviéndose desde tienden a asumir que saben
proyecto para proyectar sin los requisitos comerciales
logrando una duradera, estable mejor que el negocio
conjunto de TI de servicio s
Capacidad Espere hasta que haya capacidad Anticipe los problemas de capacidad y gaste
Planificación problemas y luego comprar excedentes dinero para prevenirlos, incluso
capacidad para durar hasta el próximo cuando es poco probable que suceda el escenario
incidente relacionado con la capacidad
Servicio de TI • No existen planes hasta después de un Exceso de planificación (y el gasto excesivo) de él

Continuidad gran evento o desastre Opción de recuperación s. Suele ser inmediato
Planificación • Los planes de TI se centran en se proporciona recuperación para la mayoría de las
recuperando sistemas clave , pero servicios , independientemente de su impacto o
sin asegurar que el prioridad
la empresa puede recuperar su
procesos
Cambio • Los cambios a menudo no son Se solicitan cambios y

administración registrado, o registrado en el último implementado incluso cuando no hay
minuto como emergencia necesidad, es decir, una cantidad significativa de trabajo
Cambiar s hecho para reparar elementos que no están rotos
• No hay tiempo suficiente para
impacto y costo
evaluación s
• Los cambios están mal probados
y controlado, lo que resulta en una
alto número de incidentes s
Tabla 3.4 Ejemplos de comportamiento extremadamente reactivo y proactivo
Página 55
Si bien el comportamiento proactivo en la operación del servicio es generalmente bueno, también hay
momentos en los que se necesita un comportamiento reactivo. El rol de la Operación del Servicio es
por lo tanto, lograr un equilibrio entre ser reactivo y proactivo. Esta voluntad
exigir:
• Procesos formales de gestión de problemas y gestión de incidentes ,

integrado entre la operación del servicio y el servicio continuo
Mejora .
• La capacidad de poder priorizar fallas técnicas y comerciales.
demandas. Esto debe hacerse durante la operación de servicio, pero el
Es necesario poner en marcha mecanismos durante la estrategia y el diseño del servicio.
Estos mecanismos podrían incluir sistemas de categorización de incidentes ,
procedimientos y herramientas de escalada para facilitar la evaluación de impacto para
cambios.
• Datos de configuración y gestión de activos para proporcionar datos donde
requerido, ahorrando tiempo al proyecto y tomando decisiones más precisas.
• Participación continua de SLM en la operación del servicio.
Página 56
3.3 Prestación de servicio
Todo el personal de operaciones de servicio debe ser plenamente consciente de que están allí para 'proporcionar
servicio 'a la empresa. Deben proporcionar una respuesta oportuna (rápida y rápida
entrega de requisito s), profesional y amable servicio para permitir que el
negocio para llevar a cabo sus propias actividades, de modo que las necesidades del cliente comercial
se cumplen y el negocio prospera.
Es importante que el personal está capacitado no sólo en la forma de entregar y dar soporte de TI
servicios , sino también en la forma en que debe prestarse ese servicio. Para
Por ejemplo, el personal que es capaz y ofrece el servicio de manera eficaz puede causar
insatisfacción significativa del cliente si son insensibles o despectivos.
Por el contrario, el ser amable con un cliente no ayudará si el servicio no es
siendo entregado.
Un elemento crítico para ser un proveedor de servicios competente es colocar tanto

énfasis en la contratación y formación de personal para desarrollar la competencia en el trato con
y gestionar las relaciones e interacciones con los clientes como lo hacen en
competencias para la gestión del entorno de TI .
Página 57
3.4 Participación del personal de operaciones en el diseño y el servicio del servicio

Transición
Es extremadamente importante que el personal de Operación del Servicio participan en Servicio

Transición del diseño y del servicio y potencialmente también en la estrategia del servicio donde
apropiado.
Una clave para lograr el equilibrio en la operación del servicio es un conjunto eficaz de
Procesos de diseño. Estos proporcionarán a la gestión de operaciones de TI :
• Definición clara de los objetivos y criterios de desempeño del servicio de TI

• Vinculación de las especificaciones de los servicios de TI con el desempeño de las TI
Infraestructura
• Definición de los operativos requisitos de desempeño
• Un mapeo de servicios y tecnología
• La capacidad de modelar el efecto de los cambios en la tecnología y los cambios en
requisitos comerciales s
• Modelos de costos apropiados (por ejemplo , basados en el cliente o en el servicio) para evaluar
Retorno de la inversión y estrategias de reducción de costos.
La naturaleza de la participación de la gestión de operaciones de TI debe ser cuidadosamente

posicionado. El diseño del servicio es una fase del ciclo de vida de la gestión del servicio que utiliza
un conjunto de procesos, no una función independiente de la Operación del Servicio. Como tal,
muchas de las personas que participan en el diseño de servicios provendrán de TI
Jefe de operaciones.
Esto no solo debe fomentarse, sino que el personal de operación del servicio debe ser
medido en su participación en las actividades de diseño de servicios, y tales actividades
deben incluirse en las descripciones del puesto y los roles , etc. Esto ayudará a garantizar
Continuidad entre los requisitos comerciales y el diseño y la operación de tecnología.
y también ayudará a asegurar que lo que está diseñado también se pueda operar. ESO
El personal de gestión de operaciones también debe participar durante la transición del servicio
para garantizar la coherencia y garantizar que tanto el negocio como la capacidad de gestión
se cumplen los requisitos.
Los recursos deben estar disponibles para estas actividades y el tiempo requerido
debe tenerse en cuenta, según corresponda
Página 58
3.5 Salud operativa
A muchas organizaciones les resulta útil comparar el seguimiento y el control de

Operación del Servicio para el seguimiento y control de la salud.
En este sentido, la Infraestructura de TI es como un organismo que tiene signos vitales de vida que
se puede monitorear para verificar si está funcionando normalmente. Esto significa que es
No es necesario monitorear continuamente todos los componentes de cada sistema de TI para
asegúrese de que esté funcionando.
La salud operativa se puede determinar aislando algunos 'signos vitales' importantes en

dispositivos o servicios que se definen como críticos para la ejecución exitosa de un
Función empresarial vital . Esta podría ser la utilización del ancho de banda en una red.
segmento o utilización de memoria en un servidor principal . Si estos signos están dentro
rangos normales, el sistema está sano y no requiere atención adicional.
Esta reducción en la necesidad de un monitoreo extenso resultará en una reducción de costos.
y equipos y departamentos operativos que se centran en los
áreas para el éxito del servicio .
Sin embargo, al igual que con los organismos, es importante comprobar los sistemas más a fondo.
de vez en cuando, para comprobar si hay problemas que no afecten inmediatamente a los signos vitales.
Por ejemplo, un disco puede estar funcionando perfectamente, pero podría estar acercándose a su valor medio.
Umbral de tiempo entre fallos (MTBF) . En este caso, el sistema debe
puesto fuera de servicio y sometido a un examen completo o "control de salud". En el
Al mismo tiempo, se debe enfatizar que el resultado final debe ser el saludable
funcionamiento del servicio en su conjunto. Esto significa que los controles de salud en
Los componentes deben equilibrarse con las comprobaciones del servicio "de principio a fin". los
La definición de lo que necesita ser monitoreado y lo que es saludable o no saludable es
definido durante el Diseño del Servicio, especialmente la Gestión de Disponibilidad y SLM.
La salud operativa depende de la capacidad de prevenir incidentes y problemas.

invirtiendo en infraestructura confiable y mantenible. Esto se logra a través de
buen diseño de disponibilidad y gestión proactiva de problemas . Al mismo tiempo,
La salud operativa también depende de la capacidad de identificar fallas y localizar
de forma eficaz para que tengan un impacto mínimo en el servicio. Esto requiere
Gestión sólida (preferiblemente automatizada) de incidentes y problemas .
La idea de la salud operativa también ha llevado a un área especializada llamada 'Self

Sistemas de curación '. Esta es una aplicación de Disponibilidad, Capacidad, Conocimiento,
Gestión de Incidentes y Problemas y se refiere a un sistema que ha sido
diseñado para soportar las condiciones de funcionamiento más severas y para detectar,
diagnosticar y recuperarse de la mayoría de los incidentes y errores conocidos . Autocuración
Los sistemas se conocen por diferentes nombres, por ejemplo, Autonomic Systems,
Sistemas adaptativos y sistemas dinámicos. Características de la autocuración
Los sistemas incluyen:
Página 59
• La resiliencia está diseñada e integrada en el sistema, por ejemplo, múltiples

discos redundantes o procesadores múltiples. Esto protege el sistema contra
falla de hardware ya que puede continuar operando usando el duplicado
componente de hardware .
• La resiliencia del software, los datos y el sistema operativo también está diseñada en el
sistema, por ejemplo, bases de datos reflejadas (donde una base de datos está duplicada
en un dispositivo de respaldo ) y tecnología de división de discos (donde los bits individuales de
Los datos se distribuyen en una matriz de discos, de modo que una falla en el disco da como resultado
la pérdida de solo una parte de los datos, que se pueden recuperar fácilmente usando
algoritmos).
• La capacidad de cambiar el procesamiento de un dispositivo físico a otro sin
cualquier interrupción del servicio . Esto podría ser una respuesta a una falla o
porque el dispositivo está alcanzando altos niveles de utilización (algunos sistemas son
diseñado para distribuir las cargas de trabajo de procesamiento de forma continua, para hacer
uso óptimo de la capacidad disponible , que también se conoce como virtualización).
• Construido en el seguimiento de utilidades que permiten al sistema detectar eventos s ya
determinar si estos representan operaciones normales o no.
• Un motor de correlación (ver párrafo 4.1.5.6 sobre Gestión de eventos ). Esta
Permitirá al sistema determinar la importancia de cada evento y
también para determinar si hay alguna respuesta predefinida a ese evento.
• Un conjunto de herramientas de diagnóstico, como secuencias de comandos de diagnóstico , árboles de fallas y un
base de datos de errores conocidos y soluciones comunes . Estos se utilizan como
tan pronto como se detecte un error , para determinar la respuesta adecuada.
• La capacidad de generar un llamado a la intervención humana al generar una alerta o
generando un incidente .
Si bien el concepto de salud operativa no es un concepto central de servicio

Operación , a menudo es una metáfora útil para ayudar a determinar lo que debe ser
monitoreados y con qué frecuencia realizar el mantenimiento preventivo.
Qué y cuándo monitorear el estado operativo se debe determinar en Service

Diseñe , pruebe y perfeccione durante la transición del servicio y optimice d en continuo
Mejora del servicio , según sea necesario.
Página 60
3.6 Comunicación
Se necesita una buena comunicación con otros equipos de TI y departamentos, con el usuario s
y clientes internos, y entre los equipos de Operación del Servicio y
departamentosadecuada.
comunicación mismos. Los problemas a menudo se pueden prevenir o mitigar con
Esta sección tiene como objetivo resumir la comunicación que debe realizarse
en Operación de Servicio. Este no es un proceso separado , sino una lista de verificación del tipo de
comunicación necesaria para el funcionamiento eficaz del servicio.
Un principio importante es que toda comunicación debe tener un propósito previsto.

o una acción resultante. La información no debe comunicarse a menos que exista una
audiencia clara. Además, esa audiencia debería haber participado activamente en
determinar la necesidad de esa comunicación y lo que harán con la
información.
Una descripción detallada de los tipos de comunicación típicos en la operación del servicio.
se incluye en el Apéndice B de esta publicación, junto con una descripción del
audiencia típica y las acciones que se pretenden tomar como resultado de cada
comunicación. Éstos incluyen:
• Comunicación operativa de rutina

• Comunicación entre turno s
• Informes de desempeño
• Comunicación en proyectos
• Comunicación relacionada con cambios
• Comunicación relacionada con excepciones
• Comunicación relacionada con emergencias
• El entrenamiento en procesos nuevos o personalizados y servicios de diseño s
• Comunicación de estrategia y diseño a los equipos de Operación del Servicio .
Tenga en cuenta que no existe un medio de comunicación definitivo, ni existe un

ubicación o frecuencia fija. En algunas organizaciones, la comunicación debe tomar
lugar en reuniones. Otras organizaciones prefieren utilizar el correo electrónico o la comunicación
inherentes a sus herramientas de gestión de servicios .
Por lo tanto, debería haber una política de comunicación dentro de cada equipo o
departamento y para cada proceso . Aunque esto debe ser formal, la política
no debe ser engorroso ni complejo. Por ejemplo, un gerente puede requerir
que todas las comunicaciones relativas a cambios deben enviarse por correo electrónico. Siempre y cuando
esto se especifica en los POE del departamento (en cualquier forma que existan), hay
no es necesario crear una política separada para ello.
Página 61
Aunque el contenido típico de la comunicación es bastante consistente, una vez que los procesos
se han definido, los medios de comunicación están cambiando con cada nuevo
introducción de tecnología. La lista de alternativas está creciendo y, a día de hoy, incluye:
• Correo electrónico, a clientes tradicionales o dispositivos móviles

• Mensajes SMS
• Buscapersonas
•
• Mensajería instantánea y 'chats' basados en la web
Utilidades de Voz sobre Protocolo de Internet (VoIP) que pueden convertir cualquier
dispositivo a un medio de comunicación económico
• Las utilidades de teleconferencia y reuniones virtuales han revolucionado las reuniones
que ahora se llevan a cabo a través de largas distancias
• Utilidades para compartir documentos .
El medio de comunicación en sí está fuera del alcance de esta publicación.

Sin embargo, deben tenerse en cuenta los siguientes puntos:
• La comunicación es primordial y los medios de comunicación deben garantizar

que sirven a este objetivo. Por ejemplo, la necesidad de una comunicación segura
puede eliminar la posibilidad de algunos de los medios anteriores. La necesidad de
la calidad puede eliminar algunas opciones de VoIP.
• Es posible utilizar cualquier medio de comunicación siempre que todos
Los interesados entienden cómo y cuándo se llevará a cabo la comunicación.
sitio.
3.6.1 Reuniones
Las diferentes organizaciones se comunican de diferentes formas. Dónde están las organizaciones
distribuidos, tenderán a depender del correo electrónico y las instalaciones de teleconferencia.
Organizaciones que tienen procesos y herramientas de gestión de servicios más maduros.
tenderá a depender de las herramientas y procesos para la comunicación (por ejemplo, utilizando un
Herramienta de gestión de incidentes para escalar y rastrear incidentes, en lugar de solicitar
correo electrónico o llamadas telefónicas para obtener actualizaciones).
Otras organizaciones prefieren comunicarse mediante reuniones. Sin embargo lo és

importante no entrar en el modo en el que se realiza el único trabajo, o
la gerencia está involucrada, es durante una reunión. Además, las reuniones cara a cara tienden a
aumentar los costos (por ejemplo, viajes, tiempo dedicado a discusiones informales, refrigerios,
etc.), por lo que los organizadores de la reunión deben equilibrar el valor de la reunión con el
número e identidad de los asistentes y el tiempo que pasarán, y obteniendo
a la reunión.
El propósito de las reuniones es comunicarse de manera efectiva con un grupo de personas.

sobre un conjunto común de objetivos o actividades. Las reuniones deberían estar bien
controlado y breve, y el enfoque debe estar en facilitar la acción. Una buena regla es
Página 62
no celebrar una reunión si la información puede ser comunicada eficazmente por

medios automatizados.
Varios factores son esenciales para el éxito de las reuniones. Aunque estos pueden
parecen ser de sentido común, a veces se descuidan:
• Establezca y comunique una agenda clara para asegurar que la reunión

logra su objetivo y ayudar al facilitador a evitar que los asistentes
secuestrando la reunión.
• Asegúrese de que se comprendan las reglas para participar. Las organizaciones tienden
tener un conjunto formal de reglas de reunión, que van desde relativamente informales hasta
muy formal (por ejemplo, Reglas de orden de Roberts).
• Utilice 'estacionamientos' o notas que registran problemas que no son directamente
relevante para el propósito de la reunión, pero que puede ser convocado si el
surge la necesidad de discusión.
• Actas de la reunión: se deben establecer reglas sobre cuándo se deben
tomado. Las actas se utilizan para recordar a las personas a las que se les asignan acciones y
para seguir el progreso de las acciones delegadas. También son útiles en
Asegurar que las decisiones y acciones interfuncionales sean rastreadas y
seguido.
• Utilice técnicas para fomentar el nivel adecuado de participación. Uno
técnica cuando se habla de mejoras, por ejemplo, es el 'mantener, detener,
técnica de inicio. Se anima a los participantes a enumerar los elementos que
les gusta conservar, las cosas que deben detenerse e iniciativas o acciones que
les gustaría que comenzaran.
A continuación se ofrecen ejemplos de reuniones típicas:
3.6.1.1 La reunión de operaciones
Las reuniones de operaciones normalmente se llevan a cabo entre los gerentes de TI.
departamentos, equipos o grupos operativos , al inicio de cada jornada laboral
o semana. El propósito de este tipo de reuniones es concienciar al personal de cualquier problema
relevantes para las operaciones (como cambios en los horarios , eventos comerciales ,
programas de mantenimiento, etc.) y para brindar una oportunidad para que el personal
cuestiones de las que son conscientes. Esta es una oportunidad para asegurar que todos
los departamentos de un centro de datos están sincronizados.
En organizaciones geográficamente dispersas puede que no sea posible tener un solo

reunión de operaciones diaria. En estos casos es importante coordinar la agenda
de las reuniones y asegurar que cada reunión tenga dos componentes :
1. La primera parte del encuentro abarcará aspectos que se aplican a la

organización en su conjunto, por ejemplo, nuevas políticas, cambios que afectan a todas las regiones
y eventos empresariales que abarcan todas las regiones.
Página 63
2. La segunda parte de la reunión cubrirá aspectos que se aplican solo a la

región local, por ejemplo, horarios de operaciones locales , cambios en el equipo local,
etc.
La reunión de operaciones suele estar presidida por el gerente de operaciones de TI o un

Gerente de Operaciones senior y asistido por todos los gerentes y supervisores
(excepto aquellos cuyos turnos no están de servicio). También es útil tener al menos una
representante de la Mesa de Servicio en la reunión para que estén al tanto de
cualquier situación que pudiera dar lugar a incidentes s.
Se deben aprovechar las oportunidades para mejorar los servicios o procesos, si se presentan, y
remitido al equipo responsable de la mejora continua del servicio .
3.6.1.2 Reuniones de departamento, grupo o equipo
Estas reuniones son esencialmente las mismas que las reuniones de operaciones, pero son
dirigido a un único departamento, grupo o equipo de TI. Cada gerente o supervisor
transmite la información de la reunión de operaciones que es relevante para su equipo.
Además, estas reuniones también cubrirán lo siguiente:
• Una discusión más detallada de los incidentes, problemas y cambios que se

aún se está trabajando, con información sobre:
• Avance hasta la fecha
• Confirmación de lo que aún queda por hacer
• Tiempos de finalización estimados
• Solicitud de recursos adicionales , si es necesario
• Discusión de posibles problemas o preocupaciones.
• Confirmación de la disponibilidad del personal para las tareas de la lista
• Confirmación de horarios de vacaciones.
3.6.1.3 Reuniones de clientes
De vez en cuando será necesario realizar reuniones con los clientes , además
de las reuniones periódicas de revisión del nivel de servicio . Ejemplos incluyen:
• Seguimiento de incidentes graves. El propósito de estas reuniones es

reparar la relación con los clientes, sino también para asegurar que TI tenga
toda la información necesaria para evitar la recurrencia. Los clientes también tienen
la oportunidad de brindar información sobre impactos comerciales imprevistos .
Estas reuniones son útiles para acordar acciones para tipos similares de incidentes.
que puede ocurrir en el futuro.
• Un foro de clientes, que se puede utilizar para una variedad de propósitos, que incluyen
probar ideas para nuevos servicios o soluciones, o recopilar requisitos para
servicios o procedimientos nuevos o revisados s. Un foro de clientes es generalmente un
reunión periódica con los clientes para discutir áreas de interés común.
Página 64
3.7 Documentación
Gestión de operaciones de TI y toda la gestión técnica y de aplicaciones

Los equipos y departamentos están involucrados en la creación y mantenimiento de una variedad de
documento s. Estos se detallan en los Capítulos 4, 5 y 6 de esta publicación y
Incluya lo siguiente:
• Participación en la definición y mantenimiento de manuales de procesos para todos

procesos en los que están involucrados. Estos incluirán procesos en otros
fases del ciclo de vida de la gestión de servicios de TI (por ejemplo, capacidad
Gestión , Gestión del Cambio , Gestión de la Disponibilidad ), así como
para todos los procesos incluidos en la fase de Operación del Servicio .
• Establecimiento de manuales de procedimientos técnicos propios . Estos deben mantenerse
actualizado y se debe agregar material nuevo a medida que sea relevante, bajo
Cambio de control. Debe recordarse que sus procedimientos deben
estar siempre estructurados para cumplir con los objetivos y las limitaciones definidas dentro
Procesos de gestión de servicios de nivel superior , como SLM. Por ejemplo,
Un procedimiento técnico para administrar los servidores siempre debe garantizar que
tiene como objetivo lograr los niveles de disponibilidad y rendimiento acordados en el
Acuerdos de nivel operativo y acuerdos de nivel de servicio (SLA).
• Participación en la creación y mantenimiento de documentos de planificación , p. Ej.
los planes de capacidad y disponibilidad y los planes de continuidad del servicio de TI .
• Participación en la creación y mantenimiento del Portafolio de Servicios . Esta
incluirá la cuantificación de los costos y el establecimiento de la viabilidad operativa de
cada servicio propuesto .
• Participación en la definición y mantenimiento de la Gestión del Servicio
herramienta de instrucción de trabajo s a fin de satisfacer informes requisito s
Página 65
4 Procesos de operación del servicio
Los procesos enumerados en el párrafo 2.4.5 se analizan en detalle en este capítulo. Como
una referencia, la estructura general se describe brevemente aquí y luego cada uno de los
Los procesos se describen con más detalle más adelante en el capítulo. Tenga en cuenta que el
roles para cada proceso y las herramientas utilizadas para cada proceso se describen en
Capítulos 6 y 7 respectivamente.
• La gestión de eventos es el proceso que monitorea todos los eventos que ocurren.
a través de la infraestructura de TI para permitir el funcionamiento normal y también para
detectar y escalar condiciones de excepción.
• La gestión de incidentes se concentra en restaurar el servicio a los usuarios como
lo más rápido posible, a fin de minimizar el impacto comercial .
• La gestión de problemas implica el análisis de la causa raíz para determinar y
resolver la causa de eventos e incidentes, actividades proactivas para detectar
y prevenir problemas / incidentes futuros y un subproceso de error conocido para
permiten un diagnóstico y una resolución más rápidos si se producen más incidentes.
NOTA: Sin esta distinción entre incidentes y problemas, y manteniendo

registros separados de incidentes y problemas , existe el peligro de que:
• Los incidentes se cerrarán demasiado pronto en el ciclo de soporte general y

no se tomarán medidas para evitar la recurrencia, por lo que lo mismo
los incidentes tendrán que ser reparados una y otra vez, o
• Los incidentes se mantendrán abiertos para que se pueda realizar el análisis de la causa raíz.
y la visibilidad se perderá cuando el usuario ‘s servicio era en realidad
restaurar d, por lo que es posible que no se cumplan los objetivos de SLA aunque el servicio
ha sido restaurado dentro de las expectativas de los usuarios. Esto a menudo resulta en una
gran número de incidentes abiertos, muchos de los cuales nunca se cerrarán
a menos que se lleve a cabo una "purga" periódica. Esto puede ser muy
motivar y puede prevenir la visibilidad efectiva de los problemas actuales.
• El cumplimiento de la solicitud implica la gestión del cliente o usuario

solicitudes que no se generan como un incidente de un servicio inesperado
retraso o interrupción. Algunas organizaciones pueden optar por manejar tales
solicitudes como una ' categoría ' de incidentes y gestionar la información a través de
un sistema de gestión de incidentes , pero otros pueden elegir (debido a
altos volúmenes o prioridad comercial de tales solicitudes) para facilitar la
provisión de capacidades de cumplimiento de solicitudes por separado a través de la solicitud
Proceso de cumplimiento . Se ha convertido en una práctica popular utilizar un
Proceso de cumplimiento de solicitudes para administrar las solicitudes de clientes y usuarios para todos
tipos de solicitudes que incluyen instalaciones, mudanzas y suministros, así como
los específicos de los servicios de TI . Por lo general, estas solicitudes no están vinculadas a la
mismas medidas de SLA y separando los registros y el flujo del proceso es
emergiendo como la mejor práctica en muchas organizaciones.
Página 66
• Gestión de acceso : este es el proceso de otorgar a los usuarios autorizados la

derecho a utilizar un servicio, al tiempo que se restringe el acceso a usuarios no autorizados. Es
basado en poder identificar con precisión a los usuarios autorizados y luego
Gestionar su capacidad para acceder a los servicios según sea necesario durante las diferentes etapas.
de sus recursos humanos (RR.HH.) o ciclo de vida contractual . Acceso
La gestión también se ha denominado gestión de identidades o derechos en algunos
Organizaciones.
Además, hay varios otros procesos que se ejecutarán o admitirán

durante la operación de servicio, pero que se activan durante otras fases del
Ciclo de vida de la gestión de servicios . Los aspectos operativos de estos procesos
discutirse en la parte final de este capítulo e incluir:
• Gestión del cambio , un proceso importante que debe estar estrechamente vinculado a
Gestión de configuración y gestión de versiones . Estos temas son
cubierto principalmente en la publicación de transición del servicio .
• Gestión de la capacidad y la disponibilidad , cuyos aspectos operativos
se tratan en esta publicación, pero que se tratan con más detalle en la
Publicación de Service Design .
• Gestión financiera , que se cubre en la Estrategia de servicio.
publicación.
• Gestión del conocimiento , que se cubre en la Transición del servicio.
publicación.
• Continuidad del servicio de TI, que se trata en la publicación Service Design.
• Informes y medición de servicios, que se tratan en el
Publicación de mejora del servicio
Página 67
4.1 Gestión de eventos
Un evento se puede definir como cualquier evento detectable o discernible que ha

Importancia para la gestión de la infraestructura de TI o la entrega de TI
servicio y evaluación del impacto que una desviación puede causar a los servicios.
Los eventos suelen ser notificaciones creadas por un servicio de TI, elemento de configuración (CI)
o herramienta de seguimiento .
El funcionamiento efectivo del servicio depende de conocer el estado del

infraestructura y la detección de cualquier desviación de lo normal o esperada operación .
Esto es proporcionado por buenos sistemas de monitoreo y control , que se basan en
dos tipos de herramientas:
• herramientas de monitoreo activo que sondean los CI clave para determinar su estado y
disponibilidad . Cualquier excepción generará una alerta que debe ser
Comunicado a la herramienta o equipo apropiado para la acción.
• herramientas de monitoreo pasivo que detectan y correlacionan alertas operacionales o
comunicaciones generadas por CI.
La capacidad de detectar eventos, darles sentido y determinar el apropiado
La acción
la base deelcontrol
para la proporciona
Monitoreo Event Management
y Control Operacional . Por tanto,
(ver Apéndice B). la gestión de eventos
Además, si estos eventos están programados para comunicarse

información, así como advertencias y excepciones, se pueden utilizar como base para
Automatizar muchas actividades rutinarias de Gestión de operaciones , por ejemplo
ejecutar scripts en dispositivos remotos o enviar trabajos para su procesamiento, o incluso
equilibrar dinámicamente la demanda de un servicio en varios dispositivos para
mejorar el rendimiento .
Por tanto, Event Management proporciona el punto de entrada para la ejecución de muchos
Procesos y actividades de operación del servicio . Además, proporciona una forma de
comparar el rendimiento y el comportamiento reales con los estándares de diseño y
SLA. Como tal, la gestión de eventos también proporciona una base para la garantía del servicio.
e informes; y mejora del servicio. Esto se cubre en detalle en el
4.1.2 Alcance
La gestión de eventos se puede aplicar a cualquier aspecto de la gestión de servicios que

necesita ser controlado y que se puede automatizar. Éstos incluyen:
• Elementos de configuración :
Página 68
• Se incluirán algunos IC porque necesitan permanecer en un

estado (por ejemplo, un interruptor en una red debe permanecer encendido y Event
Las herramientas de gestión lo confirman mediante el seguimiento de las respuestas a los 'pings').
• Se incluirán algunos CI porque su estado debe cambiar
con frecuencia y Event Management se puede utilizar para automatizar este
y actualizar el CMS (por ejemplo, la actualización de un servidor de archivos ).
• Condiciones ambientales (por ejemplo, detección de humo y fuego)
• Monitoreo de licencias de software para su uso para garantizar una licencia óptima / legal
utilización y asignación
• Seguridad (por ejemplo, detección de intrusos)
• Actividad normal (p. Ej., Seguimiento del uso de una aplicación o del rendimiento
de un servidor).
La diferencia entre monitorización y gestión de eventos
Estas dos áreas están estrechamente relacionadas, pero son de naturaleza ligeramente diferente. Evento
La gestión se centra en generar y detectar notificaciones significativas.
sobre el estado de la infraestructura y los servicios de TI .
Si bien es cierto que se requiere monitoreo para detectar y rastrear estas notificaciones,
el seguimiento es más amplio que la gestión de eventos. Por ejemplo, las herramientas de seguimiento
comprobar el estado de un dispositivo para asegurarse de que está funcionando dentro de los límites aceptables,
incluso si ese dispositivo no genera eventos .
En pocas palabras, la gestión de eventos funciona con sucesos que son específicamente
generado para ser monitoreado. El monitoreo rastrea estas ocurrencias, pero también
buscar activamente condiciones que no generen eventos.
El valor de Event Management para el negocio es generalmente indirecto; sin embargo lo és

posible determinar la base de su valor de la siguiente manera:
• Event Management proporciona mecanismos para la detección temprana de incidentes .

En muchos casos es posible que el incidente sea detectado y asignado a
el grupo apropiado para la acción antes de que ocurra una interrupción real del servicio .
• La gestión de eventos hace posible algunos tipos de actividad automatizada
ser monitoreados por excepción, eliminando así la necesidad de costosos y
Monitoreo intensivo de recursos en tiempo real, mientras se reduce el tiempo de inactividad .
• Cuando se integra en otros procesos de gestión de servicios (como, para
ejemplo, disponibilidad o gestión de capacidad ), la gestión de eventos puede
Señalar cambios de estado o excepciones que permitan a la persona apropiada o
equipo para realizar una respuesta temprana, mejorando así el rendimiento de la
proceso . Esto, a su vez, permitirá que la empresa se beneficie de una
y una gestión de servicios más eficiente en general.
Página 69
• La gestión de eventos proporciona una base para operaciones automatizadas , por lo tanto
aumentar la eficiencia y permitir que los costosos recursos humanos sean
se utiliza para trabajos más innovadores, como diseñar nuevos o mejorados
funcionalidad o definir nuevas formas en las que la empresa puede explotar
tecnología para una mayor ventaja competitiva.
4.1.4 Políticas / principios / conceptos básicos
Hay muchos tipos diferentes de eventos, por ejemplo:
• Eventos que significan un funcionamiento regular:

• notificación de que se ha completado una carga de trabajo programada
• un usuario ha iniciado sesión para usar una aplicación
• un correo electrónico ha llegado a su destinatario.
• Eventos que significan una excepción
• un usuario intenta iniciar sesión en una aplicación con la información incorrecta
contraseña
• Se ha producido una situación inusual en un proceso empresarial que puede
indicar una excepción que requiera una mayor investigación comercial (por ejemplo, una
La alerta de la página web indica que un sitio de autorización de pago está
no disponible: afecta la aprobación financiera de las transacciones comerciales )
• la CPU de un dispositivo está por encima de la tasa de utilización aceptable
• un escaneo de PC revela la instalación de software no autorizado.
• Eventos que significan inusual, pero no excepcional, la operación . Estos son un
indicación de que la situación puede requerir un seguimiento más detenido . En algunos casos
la condición se resolverá por sí sola, por ejemplo, en el caso de una inusual
combinación de cargas de trabajo : a medida que se completan, el funcionamiento normal es
restaurar d. En otros casos, la intervención del operador puede ser necesaria si el
situación se repite o si continúa durante demasiado tiempo. Estas reglas o políticas
se definen en los Objetivos de Monitoreo y Control para ese dispositivo o
servicio . Ejemplos de este tipo de eventos son:
• La utilización de la memoria de un servidor alcanza dentro del 5% de su máximo
nivel de desempeño aceptable
• El tiempo de finalización de una transacción es un 10% más largo de lo normal.
Hay dos cosas importantes en los ejemplos anteriores:
• Exactamente lo que constituye una operación normal versus una operación inusual, versus una
¿excepción? No hay una regla definitiva sobre esto. Por ejemplo, un
El fabricante puede proporcionar que un punto de referencia del 75% de utilización de la memoria sea
óptimo para la aplicación X. Sin embargo, se descubre que, bajo la especificación
condiciones de nuestra organización , los tiempos de respuesta comienzan a degradarse por encima de
Utilización del 70%. La siguiente sección explorará cómo estas cifras son
determinado.
• Cada uno se basa en el envío y la recepción de un mensaje de algún tipo. Estos
generalmente se conocen como notificaciones de eventos y no ocurren por casualidad.
Página 70
Los siguientes párrafos explorarán exactamente cómo se definen los eventos,

generado y capturado.
4.1.5 Actividades, métodos y técnicas del proceso
Figura 4.1 El proceso de gestión de eventos
Página 71
La figura 4.1 es una representación genérica de alto nivel de la gestión de eventos . Eso
debe usarse como un punto de referencia y definición, en lugar de un Evento real
Diagrama de flujo de gestión. Cada actividad de este proceso se describe a continuación.
4.1.5.1 Ocurre un evento
Los eventos ocurren continuamente, pero no todos se detectan o registran. Es

por lo tanto, es importante que todos los involucrados en el diseño, desarrollo, gestión
y el soporte de los servicios de TI y la infraestructura de TI en la que se ejecutan comprende
qué tipos de eventos deben detectarse.
Esto se analiza en el párrafo 4.1.10.1, titulado "Instrumentación".
4.1.5.2 Notificación de eventos
La mayoría de los CI están diseñados para comunicar cierta información sobre sí mismos en
una de dos formas:
• Un dispositivo es interrogado por una herramienta de administración, que recopila ciertos

datos específicos. Esto a menudo se conoce como sondeo.
• El CI genera una notificación cuando se cumplen determinadas condiciones. los
La capacidad de producir estas notificaciones debe diseñarse e incorporarse en el
CI, por ejemplo, un gancho de programación insertado en una aplicación .
Las notificaciones de eventos pueden ser propietarias, en cuyo caso solo las
Se pueden utilizar herramientas de gestión para detectar eventos. La mayoría de los CI, sin embargo, generan
Notificaciones de eventos usando un estándar abierto como SNMP (Simple Network
Protocolo de gestión).
Muchos CI están configurados para generar un conjunto estándar de eventos, basado en el

la experiencia del diseñador de lo que se requiere para operar el CI, con la capacidad de
generar tipos adicionales de eventos al 'activar' la generación de eventos relevante
mecanismo. Para otros tipos de CI, alguna forma de software de 'agente' tendrá que ser
instalado para iniciar la monitorización . A menudo, esta función de supervisión es gratuita,
pero a veces hay un costo por la licencia de la herramienta.
En un mundo ideal, el proceso de diseño del servicio debe definir qué eventos deben
generar y luego especificar cómo se puede hacer esto para cada tipo de CI. Durante
Transición del servicio , se establecerían y probarían las opciones de generación de eventos.
En muchas organizaciones, sin embargo, definir qué eventos generar se realiza mediante
prueba y error. Los administradores del sistema utilizan el conjunto estándar de eventos como punto de partida.
apunte y luego ajuste el CI a lo largo del tiempo, para incluir o excluir eventos según sea necesario.
El problema con este enfoque es que solo tiene en cuenta el
necesidades del personal que gestiona el dispositivo y no facilita una buena planificación o
mejora. Además, dificulta mucho el seguimiento y la gestión de la
Página 72
servicio sobre todos los dispositivos y personal. Un enfoque para combatir este problema es
revisar el conjunto de eventos como parte de las actividades de mejora continua.
Un principio general de la notificación de eventos es que cuanto más significativos sean los datos
contiene y cuanto más dirigida sea la audiencia, más fácil será tomar decisiones
sobre el evento. Los operadores a menudo se enfrentan a mensajes de error codificados y
no tengo idea de cómo responderles o qué hacer con ellos. Significativo
datos de notificación y claramente definidas papel s y responsabilidades deben estar
articulado y documentado durante el Diseño del Servicio y la Transición del Servicio (ver
también el párrafo 4.1.10.1 sobre 'Instrumentación'). Si los roles y responsabilidades no son
claramente definido, en una alerta amplia , nadie sabe quién está haciendo qué y esto puede llevar
a cosas que se pierden o esfuerzos duplicados.
4.1.5.3 Detección de eventos
Una vez que se haya generado una notificación de evento, un agente la detectará
ejecutándose en el mismo sistema o transmitido directamente a una herramienta de gestión
diseñado específicamente para leer e interpretar el significado del evento.
4.1.5.4 Filtrado de eventos
El propósito del filtrado es decidir si comunicar el evento a un

herramienta de gestión o ignorarla. Si se ignora, el evento generalmente se registrará en un
log en el dispositivo, pero no se realizarán más acciones.
El motivo del filtrado es que no siempre es posible activar la notificación de eventos

apagado, a pesar de que se ha tomado la decisión de que no es necesario generar
ese tipo de evento . También se puede decidir que solo el primero de una serie de
Se transmitirán notificaciones de eventos repetidos .
Durante el paso de filtrado, se realiza el primer nivel de correlación, es decir, el

determinación de si el evento es informativo, una advertencia o una excepción
(ver siguiente paso). Esta correlación generalmente la realiza un agente que reside en el
CI o en un servidor al que está conectado el CI.
El paso de filtrado
significativo no siempre
y se mueve es necesario.
directamente Paradealgunos
al motor CI, cada
correlación evento
de una es
herramienta de gestión, incluso
si está duplicado. Además, es posible que haya sido posible desactivar todos los eventos no deseados.
notificaciones.
4.1.5.5 Importancia de los eventos
Cada organización tendrá su propia categorización del significado de un

evento , pero se sugiere que al menos estas tres grandes categorías sean
representado:
Página 73
• Informativo: se refiere a un evento que no requiere ninguna acción.

y no representa una excepción. Normalmente se almacenan en el
archivos de registro del sistema o del servicio y se guardan durante un período predeterminado.
Los eventos informativos se utilizan normalmente para comprobar el estado de un dispositivo.
o servicio, o para confirmar la finalización satisfactoria de una actividad .
Los eventos informativos también se pueden utilizar para generar estadísticas (como
número de usuarios conectados a una aplicación durante un período determinado) y
como entrada en las investigaciones (como qué trabajos se completaron con éxito
antes de que se cuelgue la cola de procesamiento de transacciones ). Ejemplos de información
los eventos incluyen:
• Un usuario inicia sesión en una aplicación
• Un trabajo en la cola por lotes se completa correctamente
• Un dispositivo se ha conectado
• Una transacción se completa con éxito.
• Advertencia: una advertencia es un evento que se genera cuando un servicio o
el dispositivo se está acercando a un umbral . Las advertencias están destinadas a notificar al
persona, proceso o herramienta adecuada para que se pueda comprobar la situación
y la adopción de medidas adecuadas a pr caso una excepción. Las advertencias son
normalmente no se genera por una falla del dispositivo . Aunque hay cierto debate
acerca de si la falla de un dispositivo redundante es una advertencia o una
excepción (ya que el servicio aún está disponible). Una buena regla es que cada
La falla debe tratarse como una excepción, ya que el riesgo de un incidente
el impacto en el negocio es mucho mayor. Ejemplos de advertencias son:
• La utilización de la memoria en un servidor es actualmente del 65% y está aumentando. Si
alcanza el 75%, el tiempo de respuesta s será inaceptablemente largo y el
Se infringirá OLA para ese departamento.
• La tasa de colisiones en una red ha aumentado un 15% en el pasado.
hora.
• Excepción: una excepción significa que un servicio o dispositivo está actualmente
operando anormalmente (sin embargo eso ha sido definido). Normalmente, esto
significa que se ha incumplido un OLA y un SLA y la empresa está
siendo impactado. Las excepciones pueden representar una falla total , deteriorada
funcionalidad o rendimiento degradado . Sin embargo, tenga en cuenta que un
la excepción no siempre representa un incidente . Por ejemplo, un
Se puede generar una excepción cuando se descubre un dispositivo no autorizado.
En la red. Esto se puede gestionar mediante el uso de un registro de incidentes
o una Solicitud de Cambio (o incluso ambos), dependiendo de la organización ‘s
Políticas de gestión de incidencias y cambios . Ejemplos de excepciones
incluir:
• Un servidor está abajo
• El tiempo de respuesta de una transacción estándar en la red ha
ralentizado a más de 15 segundos
• Más de 150 usuarios han iniciado sesión en el Libro mayor
aplicación al mismo tiempo
• Un segmento de la red no responde a las solicitudes de rutina.
Página 74
4.1.5.6 Correlación de eventos
Si un evento es significativo, se debe tomar una decisión sobre exactamente qué

es la importancia y qué acciones deben tomarse para abordarlo. Es aquí donde el
Se determina el significado del evento.
La correlación normalmente se realiza mediante un 'motor de correlación', generalmente parte de un

herramienta de gestión que compara el evento con un conjunto de criterios y reglas en un
orden prescrita. Estos criterios a menudo se denominan reglas comerciales, aunque
son generalmente bastante técnicos. La idea es que el evento pueda representar algunos
impacto en el negocio y las reglas se pueden utilizar para determinar el nivel y el tipo
de impacto empresarial.
Un motor de correlación está programado de acuerdo con los estándares de rendimiento.

creado durante el diseño del servicio y cualquier orientación adicional específica para el
entorno operativo .
Entre los ejemplos de lo que tendrán en cuenta los motores de correlación se incluyen:
• Número de eventos similares (p. Ej., Esta es la tercera vez que el mismo usuario
iniciado sesión con la contraseña incorrecta, una aplicación empresarial informa que
Ha habido un patrón inusual de uso de un teléfono móvil que
podría indicar que el dispositivo se ha perdido o ha sido robado)
• Número de CI que generan eventos similares
• Si una acción específica está asociada con el código o los datos del evento.
• Si el evento representa una excepción
• Una comparación de la información de utilización en el evento con un máximo o
estándar mínimo (por ejemplo, ¿el dispositivo ha excedido un umbral ?)
• Si se requieren datos adicionales para investigar más el evento, y
posiblemente incluso una recopilación de esos datos al sondear otro sistema o
base de datos
• Categorización del evento
• Asignar un nivel de prioridad al evento.
4.1.5.7 Disparador
Si la actividad de correlación reconoce un evento , se requerirá una respuesta. los

El mecanismo utilizado para iniciar esa respuesta se llama disparador.
Hay muchos tipos diferentes de disparadores, cada uno diseñado específicamente para la tarea.
tiene que iniciar. Algunos ejemplos incluyen:
• Disparadores de Incidentes que generan un registro en la Gestión de Incidentes

sistema , iniciando así el proceso de gestión de incidentes
• Activadores de cambio que generan una Solicitud de cambio (RFC), por lo tanto
iniciar el proceso de gestión de cambios
Página 75
• Un disparador resultante de una RFC aprobada que se ha implementado pero

causado el evento, o de un cambio no autorizado que ha sido detectado
- en cualquier caso, esto se remitirá a Gestión de cambios para
investigación
• Scripts que ejecutan acciones específicas, como enviar trabajos por lotes o
reiniciar un dispositivo
• Sistemas de megafonía que notificarán a una persona o equipo del evento por móvil
teléfono
• Activadores de bases de datos que restringen el acceso de un usuario a registros específicos o
campos, o que crean o eliminan entradas en la base de datos.
4.1.5.8 Selección de respuesta
En este punto del proceso, hay varias opciones de respuesta disponibles. Eso
Es importante señalar que las opciones de respuesta se pueden elegir en cualquier combinación.
Por ejemplo, puede ser necesario conservar la entrada del registro para referencia futura,
pero al mismo tiempo escalar el evento a un personal de administración de operaciones
miembro para la acción.
Las opciones del diagrama de flujo son ejemplos. Diferentes organizaciones tendrán
diferentes opciones, y seguramente serán más detalladas. Por ejemplo, habrá
ser una gama de respuestas automáticas para cada tecnología diferente. El proceso de
determinar cuál es apropiado y cómo ejecutarlo no están representados
en este diagrama de flujo. Algunas de las opciones disponibles son:
• Evento registrado: independientemente de la actividad que se realice, es una buena idea

para tener un registro del evento y las acciones posteriores. El evento puede
registrarse como un registro de eventos en la herramienta de gestión de eventos , o puede
simplemente dejarlo como una entrada en el registro del sistema del dispositivo o aplicación que
generó el evento. Sin embargo, si este es el caso, debe haber un
orden permanente para que el personal apropiado de Gestión de Operaciones verifique
los registros de forma regular e instrucciones claras sobre cómo utilizar cada
Iniciar sesión. También debe recordarse que la información del evento en los registros
puede no ser significativo hasta que ocurra un incidente; y donde el técnico
El personal de administración utiliza los registros para investigar dónde ocurrió el incidente.
originado. Esto significa que el procedimiento de Gestión de eventos para cada
El sistema o el equipo necesitan definir estándares sobre cuánto tiempo se mantienen los eventos.
en los registros antes de ser archivado y eliminado.
• Respuesta automática: algunos eventos se entienden lo suficientemente bien como para
ya se ha definido y automatizado la respuesta adecuada. Este es
normalmente como resultado de un buen diseño o de experiencia previa (normalmente
Gestión de problemas ). El disparador iniciará la acción y luego
evaluar si se completó con éxito. Si no, un incidente o
Se creará
• un registro
Reiniciar un de problemas . Ejemplos de respuestas automáticas incluyen:
dispositivo
• Reiniciar un servicio
Página 76
• Enviar un trabajo por lotes

• Cambiar un parámetro en un dispositivo
• Bloquear un dispositivo o una aplicación para protegerlo contra personas no autorizadas.
acceso.
Nota: bloquear un dispositivo puede resultar en la denegación del servicio a los usuarios autorizados ,
que podría ser explotado por un atacante deliberado, por lo que se debe tener mucho cuidado
tomarse al decidir si se trata de una acción automatizada adecuada.
Cuando se utilice esta respuesta, puede ser prudente combinarla también con una
llamar a la intervención humana, para que la acción automatizada pueda ser rápidamente
revisado y aprobado.
• Alerta e intervención humana: si el evento requiere intervención humana,

será necesario escalar. El propósito de la alerta es asegurar que el
se notifica a la persona con las habilidades apropiadas para lidiar con el evento. los
alerta contendrá toda la información necesaria para que esa persona determine
la acción apropiada, incluida la referencia a cualquier documentación
requerido (por ejemplo, manuales de usuario). Es importante tener en cuenta que esto no es
necesariamente lo mismo que la escalada funcional de un incidente , donde el
El énfasis está en restaurar el servicio dentro de un tiempo acordado (que puede requerir
una variedad de actividades). La alerta requiere que una persona o equipo realice una
acción específica, posiblemente en un dispositivo específico y posiblemente en un
tiempo, por ejemplo, cambiar un cartucho de tóner en una impresora cuando el nivel es bajo.
• Incidente , problema o cambio ? Algunos eventos representarán una situación
donde la respuesta apropiada deberá manejarse a través del
Proceso de gestión de incidencias, problemas o cambios . Estos se discuten
a continuación, pero es importante tener en cuenta que un solo incidente puede iniciar cualquier
o una combinación de estos tres procesos, por ejemplo, un proceso no crítico
la falla del servidor se registra como un incidente, pero como no hay solución , una
El registro de problemas se crea para determinar la causa raíz y la resolución y
se registra un RFC para reubicar la carga de trabajo en un servidor alternativo mientras
el problema esta resuelto.
• Abrir un RFC: hay dos lugares en el proceso de gestión de eventos
donde se puede crear una RFC:
• Cuando ocurre una excepción: por ejemplo, un escaneo de una red
segmento revela que se han agregado dos nuevos dispositivos sin
la autorización necesaria. Una forma de lidiar con esta situación es
para abrir un RFC, que se puede utilizar como vehículo para el cambio
Proceso de gestión para hacer frente a la excepción (como alternativa
al enfoque más convencional de abrir un incidente que
se enviaría a través de la mesa de servicio a la gestión de cambios).
La investigación por parte de Change Management es apropiada aquí ya que
Los cambios no autorizados implican que el proceso de Gestión de cambios
no fue eficaz.
• La correlación identifica que se necesita un cambio : en este caso, el
La actividad de correlación de eventos determina que la respuesta adecuada
Página 77
a un evento es para que algo cambie. Por ejemplo, un

se ha alcanzado el umbral de rendimiento y un parámetro en un
el servidor principal necesita ser ajustado. ¿Cómo funciona la actividad de correlación
determinar esto? Estaba programado para hacerlo en el Servicio
Proceso de diseño o porque esto ha sucedido antes y Problema
Gerencia o Gerencia de Operaciones actualizó la Correlación
Motor para realizar esta acción.
• Abrir un registro de incidente : al igual que con un RFC, se puede generar un incidente
inmediatamente cuando se detecta una excepción, o cuando la correlación
Engine determina que un tipo específico o combinación de evento s
representa un incidente. Cuando se abre un registro de incidente, tanto
Se debe incluir la información que sea posible, con enlaces a los eventos.
en cuestión y, si es posible, un guión de diagnóstico completo .
• Abrir o vincular a un registro de problemas : es raro que un registro de problemas sea
abierto sin incidentes relacionados (por ejemplo, como resultado de un Servicio
Análisis de fallas (consulte la publicación Diseño de servicios ) o evaluación de madurez ,
o debido a una gran cantidad de reintentos de errores de red , aunque se haya producido un error
aún no ha ocurrido). En la mayoría de los casos, este paso se refiere a vincular un incidente
a un registro de problemas existente. Esto ayudará a la gestión de problemas
equipos para reevaluar la gravedad y el impacto del problema , y puede resultar
en una prioridad cambiada a un problema pendiente.
Sin embargo, es posible, con algunas de las herramientas más sofisticadas,

evaluar el impacto de los incidentes y también generar un registro de problemas
automáticamente, cuando se justifique, para permitir que el análisis de la causa raíz
comenzar inmediatamente.
• Tipos especiales de incidentes: en algunos casos, un evento indicará una

excepción que no afecta directamente a ningún servicio de TI , por ejemplo, un
falla la unidad de aire acondicionado redundante o la entrada no autorizada a un centro de datos.
Las pautas para estos eventos son las siguientes:
• Un incidente debe registrarse utilizando un modelo de incidente que sea
apropiado para ese tipo de excepción, por ejemplo, un incidente de operaciones
o Incidente de seguridad (consulte el párrafo 4.2.4.2 para obtener más
Modelos de incidentes ).
• El incidente se debe escalar al grupo que gestiona ese
tipo de incidente.
• Como no hay interrupción, el modelo de incidente utilizado debe reflejar que
se trataba de un problema operativo más que de un problema de servicio . los
las estadísticas normalmente no se informarán a los clientes o usuarios ,
a menos que puedan utilizarse para demostrar que el dinero invertido en
la redundancia fue una buena inversión.
• Estos incidentes no deben utilizarse para calcular el tiempo de inactividad y pueden
de hecho, se puede utilizar para demostrar cuán proactiva ha sido la TI en
poner los servicios a disposición.
Página 78
4.1.5.9 Revisar acciones
Con miles de eventos que se generan todos los días, no es posible formalmente
revise cada evento individual. Sin embargo, es importante comprobar que cualquier
los eventos importantes o excepciones se han manejado de manera adecuada, o para rastrear
tendencias o recuentos de tipos de eventos, etc. En muchos casos, esto se puede hacer
automáticamente, por ejemplo, sondear un servidor que se ha reiniciado utilizando un
secuencia de comandos automatizada para ver que está funcionando correctamente.
En los casos en que los eventos hayan iniciado un incidente, problema y / o cambio , el
Action Review no debe duplicar ninguna revisión que se haya realizado como parte de
esos procesos. Más bien, la intención es garantizar que el traspaso entre
el proceso de gestión de eventos y otros procesos se llevaron a cabo tal como fue diseñado y
que la acción esperada efectivamente tuvo lugar. Esto asegurará que los incidentes,
los problemas o cambios que se originan dentro de la Gestión de Operaciones no se pierden
entre los equipos o departamentos.
La revisión también se utilizará como insumo para la mejora continua y la

evaluación y auditoría del proceso de Gestión de Eventos .
4.1.5.10 Cerrar evento
Algunos eventos permanecerán abiertos hasta que se lleve a cabo una determinada acción, por ejemplo, una
evento que está vinculado a un incidente abierto . Sin embargo, la mayoría de los eventos no están 'abiertos'
o ' cerrado '.
Los eventos informativos simplemente se registran y luego se utilizan como entrada para otros
procesos, como Backup y Storage Management . Los eventos de respuesta automática
normalmente se cierra con la generación de un segundo evento. Por ejemplo, un dispositivo
genera un evento y se reinicia a través de la respuesta automática, tan pronto como eso
el dispositivo vuelve a estar en línea con éxito, genera un evento que se cierra de manera efectiva
el bucle y borra el primer evento.
A veces es muy difícil relacionar el evento abierto y las notificaciones de cierre.

ya que están en diferentes formatos. Es óptimo que los dispositivos de la infraestructura
producir eventos 'abrir' y 'cerrar' en el mismo formato y especificar el cambio de
estado. Esto permite que el paso de correlación en el proceso coincida fácilmente
Cerrar notificaciones.
En el caso de eventos que generaron una incidencia, problema o cambio , estos

debe cerrarse formalmente con un enlace al registro apropiado de la otra
proceso.
Página 79
4.1.6 Disparadores, interfaces de entrada y salida / entre procesos
La gestión de eventos puede iniciarse con cualquier tipo de incidencia. La clave es

definir cuál de estos sucesos es significativo y cuál debe ser actuado
sobre. Los desencadenantes incluyen:
• Excepciones a cualquier nivel de rendimiento de CI definido en el diseño

especificaciones , OLA o SOP
• Excepciones a un procedimiento o proceso automatizado , por ejemplo, un cambio de rutina
que se ha asignado a un equipo de construcción no se ha completado a tiempo
• Una excepción dentro de un proceso empresarial que está siendo supervisado por Event
administración
• La finalización de una tarea o trabajo automatizado.
• Un cambio de estado en un dispositivo o registro de base de datos
• Acceso a una aplicación o base de datos por parte de un usuario o procedimiento automatizado o
trabajo
• Una situación en la que un dispositivo, base de datos o aplicación, etc.ha alcanzado un
umbral predefinido de rendimiento.
Event Management puede interactuar con cualquier proceso que requiera monitoreo y
control , especialmente aquellos que no requieren monitoreo en tiempo real, pero que sí
requieren alguna forma de intervención después de un evento o grupo de eventos.
Ejemplos de interfaces con otros procesos incluyen:
• Interfaz con aplicaciones comerciales y / o procesos comerciales para permitir

eventos comerciales potencialmente importantes que se deben detectar y actuar (p. ej.
una aplicación de negocios informa anormal de la actividad en un cliente cuenta ‘s
que puede indicar algún tipo de fraude o violación de la seguridad ).
• Las principales relaciones de ITSM son con Incidente , Problema y Cambio.
Administración. Estas interfaces se describen con cierto detalle en el párrafo
4.1.5.8.
• La capacidad y la disponibilidad de gestión son fundamentales en la definición de qué evento s
son importantes, cuáles deberían ser los umbrales apropiados y cómo responder
a ellos. A cambio, Event Management mejorará el rendimiento y
disponibilidad de los servicios respondiendo a los eventos cuando ocurren y
informar sobre eventos reales y patrones de eventos para determinar (por
comparación con los objetivos de SLA y los KPI) si hay algún aspecto del
diseño u operación de infraestructura que se puede mejorar.
• Configuration Management puede utilizar eventos para determinar la corriente
estado de cualquier CI en la infraestructura. Comparando eventos con el
Las líneas de base autorizadas en el Sistema de gestión de la configuración (CMS)
ayudar a determinar si se está realizando una actividad de cambio no autorizada
lugar en la organización (consulte la publicación Transición del servicio ).
• Gestión de activos (cubierto con más detalle en el Diseño de servicios y
Publicaciones de transición) pueden utilizar la Gestión de eventos para determinar la
estado del ciclo de vida de los activos . Por ejemplo, se podría generar un evento para
Página 80
señal de que un nuevo activo se ha configurado correctamente y ahora está

operativo .
• Los eventos pueden ser una rica fuente de información que se puede procesar para
inclusión en los sistemas de gestión del conocimiento . Por ejemplo, patrones de
El desempeño puede correlacionarse con la actividad comercial y usarse como entrada.
en futuras decisiones estratégicas y de diseño .
• La gestión de eventos puede desempeñar un papel importante para garantizar que el potencial
el impacto en los SLA se detecta temprano y cualquier falla se rectifica tan pronto como
posible para minimizar el impacto en los objetivos del servicio .
4.1.7 Gestión de la información
La información clave involucrada en la gestión de eventos incluye lo siguiente:
• Mensajes SNMP, que son una forma estándar de comunicar información técnica.
información sobre el estado de los componentes de una infraestructura de TI .
• Bases de información de gestión (MIB) de dispositivos de TI. Un MIB es el
base de datos en cada dispositivo que contiene información sobre ese dispositivo,
incluyendo su sistema operativo, versión de BIOS , configuración del sistema
parámetros, etc. La capacidad de interrogar MIB y compararlos con un
La norma es fundamental para poder generar eventos.
• Software de agente de herramientas de monitoreo del proveedor .
• Los motores de correlación contienen reglas detalladas para determinar la importancia
y respuesta adecuada a los eventos. Los detalles sobre esto se proporcionan en
párrafo 4.1.5.6.
• No existe un registro de eventos estándar para todos los tipos de eventos. El exacto
El contenido y el formato del registro dependen de las herramientas que se utilicen, lo que
supervisado (por ejemplo, un servidor y las herramientas de gestión de cambios
tienen datos muy diferentes y probablemente usan un formato diferente). Sin embargo,
Hay algunos datos clave que generalmente se requieren de cada evento para ser
útil en el análisis. Por lo general, debe incluir:
• Dispositivo
• Componente
• Tipo de falla
• Fecha y hora
• Parámetros en excepción
• Valor.
4.1.8 Métricas
Para cada período de medición en cuestión, las métricas para verificar el

La eficacia y eficiencia del proceso de Gestión de eventos debe incluir
el seguimiento:
• Número de eventos por categoría

• Número de eventos por significado
Página 81
• Número y porcentaje de eventos que requirieron intervención humana y

si esto fue realizado
• Número y porcentaje de eventos que resultaron en incidentes o cambios
• Número y porcentaje de eventos causados por problemas existentes o conocidos
Errores. Esto puede resultar en un cambio en la prioridad del trabajo en ese problema.
o error conocido
• Número y porcentaje de eventos repetidos o duplicados. Esto ayudará en
el ajuste del motor de correlación para eliminar eventos innecesarios
generación y también se puede utilizar para ayudar en el diseño de mejores eventos
funcionalidad de generación en nuevos servicios
• Número y porcentaje de eventos que indican problemas de desempeño (por
ejemplo, el crecimiento en el número de veces que una aplicación excedió su
umbral de transacción s durante los últimos seis meses)
• Número y porcentaje de eventos que indican posibles problemas de disponibilidad
(p. ej., conmutaciones por error a dispositivos alternativos o intercambio excesivo de cargas de trabajo )
• Número y porcentaje de cada tipo de evento por plataforma o aplicación
• Número y proporción de eventos en comparación con el número de incidentes .
4.1.9 Desafíos, factores críticos de éxito y riesgos
4.1.9.1 Desafíos
Hay una serie de desafíos que pueden surgir:
• Un desafío inicial puede ser obtener financiamiento para las herramientas necesarias y
Esfuerzo necesario para instalar y aprovechar los beneficios de las herramientas.
• Uno de los mayores desafíos es establecer el nivel correcto de filtrado.
Establecer el nivel de filtrado incorrectamente puede resultar en inundaciones
con eventos relativamente insignificantes , o no ser capaz de detectar relativamente
eventos importantes hasta que sea demasiado tarde.
• Implementación de los agentes de supervisión necesarios en toda la TI
la infraestructura puede ser una tarea difícil y consume mucho tiempo la actividad que requiere una
compromiso continuo durante un período de tiempo bastante largo: existe el peligro
que pueden surgir otras actividades que puedan desviar los recursos y retrasar la
lanzamiento .
• Adquirir las habilidades necesarias puede llevar mucho tiempo y ser costoso.
4.1.9.2 Factores críticos de éxito
Con el fin de obtener la financiación necesaria, debe elaborarse un Business Case convincente.
preparado mostrando cómo los beneficios de una gestión de eventos eficaz pueden
compensar los costos s - dando un retorno positivo de la inversión.
Uno de los CSF más importantes es lograr el nivel correcto de filtrado. Este es
complicado por el hecho de que el significado de los eventos cambia. Por ejemplo, un
Página 82
que el usuario inicie sesión en un sistema hoy en día es normal, pero si ese usuario deja el
organización e intenta iniciar sesión es una violación de seguridad .
Hay tres claves para el nivel correcto de filtrado, como se indica a continuación:
• Integre la gestión de eventos en todos los procesos de gestión de servicios

donde sea posible. Esto asegurará que solo los eventos importantes para estos
se informan los procesos.
• Diseñar nuevos servicios teniendo en cuenta la gestión de eventos (esto se analiza en
detalle en el párrafo 4.1.10).
• Prueba y error. No importa cuán minuciosamente esté preparada la Gestión de eventos,
Habrá clases de eventos que no se filtrarán correctamente. Evento
Por lo tanto, la administración debe incluir un proceso formal para evaluar la
eficacia del filtrado.
Se necesita una planificación adecuada para la implementación del software del agente de monitoreo en
toda la infraestructura de TI. Esto debe considerarse como un proyecto con realismo.
escalas de tiempo y recursos adecuados asignados y protegidos a lo largo del
duración del proyecto.
4.1.9.3 Riesgos
Los riesgos clave son realmente los ya mencionados anteriormente: no obtener

financiación adecuada; asegurar el nivel correcto de filtrado; y falta de mantenimiento
impulso en la implementación de los agentes de monitoreo necesarios en la TI
Infraestructura . Si alguno de estos riesgos no se aborda, podría tener un impacto adverso en
el éxito de la gestión de eventos.
4.1.10 Diseño para la gestión de eventos
La gestión eficaz de eventos no se diseña una vez que se ha implementado un servicio

en Operaciones. Dado que Event Management es la base para monitorear el
desempeño y disponibilidad de un servicio, los objetivos exactos y los mecanismos para
el monitoreo debe especificarse y acordarse durante la disponibilidad y capacidad
Procesos de gestión (ver publicación Diseño de servicios ).
Sin embargo, esto no significa que Event Management esté diseñado por un grupo de
desarrolladores de sistemas remotos y luego liberados a Operations Management
junto con el sistema que hay que gestionar. Tampoco significa que, una vez
diseñado y acordado, la gestión de eventos se vuelve estática, día a día
Las operaciones definirán eventos adicionales , prioridades, alertas y otras mejoras.
que alimentará el proceso de Mejora Continua de vuelta al Servicio
Estrategia , diseño de servicios , etc.
Se espera que las funciones de Operación del Servicio participen en el diseño del
servicio y cómo se mide (consulte la sección 3.4).
Página 83
Para la gestión de eventos , las áreas de diseño específicas incluyen lo siguiente.
4.1.10.1 Instrumentación
La instrumentación es la definición de lo que se puede monitorear sobre los IC y la forma

en el que su comportamiento puede verse afectado. En otras palabras, la instrumentación se trata de
definir y diseñar exactamente cómo monitorear y controlar la infraestructura de TI
y servicios de TI s.
La instrumentación se trata en parte de un conjunto de decisiones que deben tomarse y en parte

sobre el diseño de mecanismos para ejecutar estas decisiones.
Las decisiones que deben tomarse incluyen:
• ¿Qué necesita ser monitoreado?

• ¿Qué tipo de monitoreo se requiere (por ejemplo, activo o pasivo; desempeño o
producción)?
• ¿Cuándo necesitamos generar un evento?
• ¿Qué tipo de información se necesita comunicar en el evento?
• ¿A quiénes están destinados los mensajes?
Los mecanismos que deben diseñarse incluyen:
• ¿Cómo se generarán los eventos?

• ¿El CI ya tiene mecanismos de generación de eventos como estándar?
característica y, en caso afirmativo, ¿cuál de ellas se utilizará? ¿Son suficientes o no
el CI debe personalizarse para incluir mecanismos adicionales o
¿información?
• ¿Qué datos se utilizarán para completar el registro de eventos ?
• ¿Los eventos se generan automáticamente o hay que sondear el CI?
• ¿Dónde se registrarán y almacenarán los eventos?
• ¿Cómo se recopilarán los datos complementarios?
Nota: Aquí existe una interfaz sólida con el diseño de la aplicación . Todas las aplicaciones
debe codificarse de tal manera que el error significativo y detallado
Los mensajes / códigos se generan en el punto exacto de falla , de modo que estos
ser incluidos en el evento y permitir un rápido diagnóstico y resolución de la
causa subyacente. La necesidad de incluir y probar dichos mensajes de error.
se trata con más detalle en la publicación Transición del servicio .
4.1.10.2 Mensajes de error
La mensajería de error es importante para todos los componentes (hardware, software, redes,
etc.). Es particularmente importante que todas las aplicaciones de software estén diseñadas para
apoyar la gestión de eventos. Esto podría incluir la provisión de errores significativos
mensajes y / o códigos que indiquen claramente el punto específico de falla y el
Página 84
causa más probable. En tales casos, la prueba de nuevas aplicaciones debe incluir
prueba de la generación precisa de eventos .
Nuevas tecnologías como Java Management Extensions (JMX) o HawkNL ™
Proporcionar las herramientas para la construcción distribuida, basada en web, modular y dinámica.
soluciones para la gestión y supervisión de dispositivos, aplicaciones y servicios impulsada
redes. Estos pueden usarse para reducir o eliminar la necesidad de que los programadores
incluir mensajes de error dentro del código, lo que permite un nivel valioso de
normalización e independencia del código.
4.1.10.3 Mecanismos de alerta y detección de eventos
Un buen diseño de gestión de eventos también incluirá el diseño y la población de

las herramientas utilizadas para filtrar, correlacionar y escalar eventos.
Específicamente, el motor de correlación deberá completarse con las reglas y

Criterios que determinarán la importancia y la acción posterior para cada tipo.
del evento.
El diseño minucioso de los mecanismos de alerta y detección de eventos requiere

siguiente:
• El conocimiento empresarial en relación con cualquier proceso empresarial se

gestionado a través de Gestión de eventos
• Conocimiento detallado de los requisitos de nivel de servicio del servicio.
siendo apoyado por cada CI
• Conocimiento de quién va a apoyar a la IC.
• El conocimiento de lo que constituye normal y anormal funcionamiento del CI
• Conocimiento de la importancia de múltiples eventos similares (en el mismo IC
o varios CI similares
• Comprensión de lo que necesitan saber para apoyar a la IC de manera eficaz.
• Información que puede ayudar en el diagnóstico de problemas con el IC
• Familiaridad con los códigos de priorización y categorización de incidentes para que si
es necesario para crear un registro de incidentes , estos códigos se pueden proporcionar
• Conocimiento de otros IC que pueden depender del IC afectado, o
aquellos IC de los que depende
• Disponibilidad de información de errores conocidos de proveedores o de
experiencia.
4.1.10.4 Identificación de umbrales
Los propios umbrales no se configuran ni gestionan a través de Gestión de eventos.

Sin embargo, a menos que estos estén correctamente diseñados y comunicados durante la
proceso de instrumentación , será difícil determinar qué nivel de
el rendimiento es apropiado para cada CI.
Página 85
Además, la mayoría de los umbrales no son constantes. Por lo general, constan de una serie de
variables relacionadas. Por ejemplo, el número máximo de usuarios simultáneos antes
La ralentización del tiempo de respuesta variará dependiendo de qué otros trabajos estén activos en el
servidor . Este conocimiento a menudo solo se adquiere mediante la experiencia, lo que significa que
Los motores de correlación deben ajustarse y actualizarse continuamente a través del
proceso de Mejora Continua del Servicio .
Página 86
4.2 Gestión de incidentes
En la terminología de ITIL , un ' incidente ' se define como:
Una interrupción no planificada de un servicio de TI o una reducción en la calidad de una TI

Servicio. La falla de un elemento de configuración que aún no ha afectado al servicio también se
un incidente, por ejemplo, la falla de un disco de un conjunto de espejos.
La gestión de incidentes es el proceso para tratar todos los incidentes; esto puede
incluir fallas, preguntas o consultas informadas por los usuarios (generalmente a través de un
llamada telefónica al Service Desk ), por parte del personal técnico, o detectada automáticamente
y reportado por herramientas de monitoreo de eventos .
El objetivo principal del proceso de gestión de incidentes es restaurar la normalidad

operación del servicio lo más rápido posible y minimizar el impacto adverso en
operaciones comerciales , asegurando así que los mejores niveles posibles de calidad de servicio
y se mantienen la disponibilidad . 'Operación de servicio normal' se define aquí como
operación del servicio dentro de los límites del SLA.
4.2.2 Alcance
La gestión de incidentes incluye cualquier evento que interrumpa, o que pueda interrumpir,
un servicio. Esto incluye eventos que son comunicados directamente por los usuarios, ya sea
a través del Service Desk o mediante una interfaz de Event Management para
Herramientas de gestión de incidencias.
Los incidentes también pueden ser reportados y / o registrados por personal técnico (si, por ejemplo,
notan algo anormal con un hardware o componente de red que pueden
informar o registrar un incidente y remitirlo al Service Desk). Esto no significa,
sin embargo, que todos los eventos son incidentes. Muchas clases de eventos no están relacionados con
interrupciones en absoluto, pero son indicadores de funcionamiento normal o son simplemente
informativo (ver sección 4.1).
Aunque tanto los incidentes como las solicitudes de servicio se informan al Service Desk,
esto no significa que sean iguales. Las solicitudes de servicio no representan un
interrupción del servicio acordado, pero son una forma de satisfacer las necesidades del cliente y
puede estar abordando un objetivo acordado en un SLA. Se atienden las solicitudes de servicio
por el proceso de Cumplimiento de Solicitudes (ver sección 4.3).
El valor de la gestión de incidentes incluye:
Página 87
• La capacidad de detectar y resolver incidentes que se traducen en un menor tiempo de inactividad.

para el negocio, lo que a su vez significa una mayor disponibilidad del servicio. Esta
significa que la empresa puede explotar la funcionalidad del servicio
como fue diseñado.
• La capacidad de alinear la actividad de TI con las prioridades comerciales en tiempo real. Este es
porque la gestión de incidentes incluye la capacidad de identificar empresas
prioridades y asigne dinámicamente los recursos según sea necesario.
• La capacidad de identificar posibles mejoras a los servicios. Esto sucede como
resultado de comprender lo que constituye un incidente y también de ser
en contacto con las actividades del personal operativo empresarial .
• El Service Desk puede, durante su manejo de incidentes, identificar adicionales
requisitos de servicio o capacitación que se encuentran en TI o en el negocio.
La gestión de incidentes es muy visible para la empresa y, por lo tanto, es más fácil
demostrar su valor que la mayoría de las áreas en la operación del servicio . Por esta razón,
La gestión de incidentes es a menudo uno de los primeros procesos que se implementan en
Proyecto de gestión de servicios s. El beneficio adicional de hacer esto es que Incidente
La gestión se puede utilizar para resaltar otras áreas que necesitan atención, por lo que
proporcionar una justificación del gasto en la implementación de otros procesos.
Hay algunas cosas básicas que deben tenerse en cuenta y decidirse

al considerar la gestión de incidentes. Estos se tratan en esta sección.
4.2.4.1 Escalas de tiempo
Se deben acordar escalas de tiempo para todas las etapas de manejo de incidentes (estas diferirán
dependiendo del nivel de prioridad del incidente) - basado en el
objetivos de respuesta y resolución de incidentes dentro de los SLA, y capturados como objetivos
dentro de los OLA y los contratos subyacentes (UC). Todos los grupos de apoyo deben
plenamente consciente de estos plazos. Deben utilizarse herramientas de gestión de servicios
para automatizar escalas de tiempo y escalar el incidente según sea necesario en función de
reglas definidas.
4.2.4.2 Modelos de incidentes
Muchos incidentes no son nuevos, implican lidiar con algo que ha

sucedió antes y puede que vuelva a suceder. Por esta razón, muchos
a las organizaciones les resultará útil predefinir los modelos de incidentes `` estándar '' , y
aplíquelos a los incidentes apropiados cuando ocurran.
Un modelo de incidente es una forma de predefinir los pasos que se deben tomar para
manejar un proceso (en este caso, un proceso para tratar con un tipo particular de
incidente) de una manera acordada. Las herramientas de soporte se pueden utilizar para gestionar la
Página 88
proceso requerido. Esto garantizará que los incidentes 'estándar' se manejen en un

ruta definida y dentro de escalas de tiempo predefinidas.
Los incidentes que requieran un manejo especializado pueden tratarse de esta manera (por
Por ejemplo, los incidentes relacionados con la seguridad se pueden enrutar a Seguridad de la información
Gestión y capacidad - o incidentes relacionados con el desempeño que serían
enrutado a Gestión de la capacidad .
El modelo de incidente debe incluir:
• Los pasos que se deben tomar para manejar el incidente.

• El orden cronológico en el que se deben seguir estos pasos, con cualquier
dependencias o coprocesamiento definido
• Responsabilidades; quien debe hacer que
• Plazos y umbrales para completar las acciones
• Procedimientos de escalamiento s; quién debe ser contactado y cuándo
• Cualquier actividad necesaria de preservación de evidencia (particularmente relevante para
incidentes relacionados con la seguridad y la capacidad ).
Los modelos deben incorporarse a las herramientas de apoyo para el manejo de incidentes en uso y
las herramientas deben automatizar el manejo, la gestión y la escalada de la
proceso .
4.2.4.3 Incidentes mayores
Debe establecerse un procedimiento separado , con escalas de tiempo más breves y mayor urgencia .
utilizado para incidentes "mayores". Una definición de lo que constituye un incidente mayor debe
ser acordados e idealmente mapeados en el sistema general de priorización de incidentes -
de manera que se tratarán a través del proceso de incidentes mayores .
Nota: las personas a veces usan terminología imprecisa y / o confunden un incidente importante
con un problema . En realidad, un incidente sigue siendo un incidente para siempre; puede crecer en
impacto o prioridad para convertirse en un incidente mayor, pero un incidente nunca 'se convierte' en un
problema. Un problema es la causa subyacente de uno o más incidentes y
sigue siendo una entidad separada siempre!
Es posible que algunos incidentes de menor prioridad también deban manejarse a través de este
procedimiento, debido al posible impacto comercial, y algunos incidentes importantes pueden
No es necesario manejarlo de esta manera si la causa y la resolución son obvias y
El proceso normal de incidentes puede afrontar fácilmente los tiempos de resolución objetivo acordados.
- ¡siempre que el impacto sea bajo!
Cuando sea necesario, el procedimiento de incidente mayor debe incluir la dinámica

Establecimiento de un equipo de incidentes importantes separado bajo el liderazgo directo de
el Gerente de Incidentes, formulado para concentrarse solo en este incidente para garantizar
que se proporcionen los recursos y el enfoque adecuados para encontrar una solución rápida. Si
Página 89
el Service Desk Manager también está cumpliendo el rol de Incident Manager (digamos en un
organización pequeña ), es posible que deba designarse una persona separada para dirigir
el equipo principal de investigación de incidentes, para evitar conflictos de tiempo o prioridades
- pero, en última instancia, debe informar al administrador de incidentes.
Si la causa del incidente necesita ser investigada al mismo tiempo, entonces el

El administrador de problemas también estaría involucrado, pero el administrador de incidentes debe
asegúrese de que la restauración del servicio y la causa subyacente se mantengan separadas.
En todo momento, el Service Desk se asegurará de que todas las actividades se registren y
los usuarios se mantienen plenamente informados del progreso.
El proceso a seguir durante la gestión de una incidencia se muestra en
Figura 4.2. El proceso incluye los siguientes pasos.
Página 90
Figura 4.2 Flujo del proceso de gestión de incidentes
4.2.5.1 Identificación de incidentes
Página 91
El trabajo no puede comenzar a lidiar con un incidente hasta que se sepa que un incidente
ha ocurrido. Suele ser inaceptable, desde una perspectiva empresarial , esperar
hasta que un usuario se vea afectado y se ponga en contacto con la mesa de servicio. En la medida de lo posible, todas las claves
los componentes deben ser monitoreados de modo que las fallas o las fallas potenciales sean
detectado temprano para que el proceso de gestión de incidentes pueda iniciarse rápidamente.
Idealmente, los incidentes deben resolverse antes de que tengan un impacto en los usuarios.
Consulte la sección 4.1 para obtener más detalles.
4.2.5.2 Registro de incidentes
Todos los incidentes deben estar completamente registrados y sellados con la fecha / hora, independientemente de si
se generan a través de una llamada telefónica a la mesa de servicio o si automáticamente
detectado a través de una alerta de evento .
Nota: Si la mesa de servicio y / o el personal de soporte visita al cliente para tratar con uno
incidente, se les puede pedir que se ocupen de otros incidentes "mientras estén allí". Eso
Es importante que si se hace esto, se registre un Registro de Incidentes separado para cada
incidente adicional manejado - para asegurar que se mantenga un registro histórico y se acredite
se da por el trabajo realizado.
Toda la información relevante relacionada con la naturaleza del incidente debe registrarse para
que se mantenga un registro histórico completo, y de modo que si el incidente tiene que ser
referido a otro (s) grupo (s) de apoyo , ellos tendrán toda la información relevante a mano
para ayudarlos.
Es probable que la información necesaria para cada incidente incluya:
• Número de referencia único

• Categorización de incidentes (a menudo dividida en entre dos y cuatro
niveles de subcategorías)
• Urgencia del incidente
• Impacto del incidente
• Priorización de incidentes
• Fecha / hora registrada
• Nombre / ID de la persona y / o grupo que registra el incidente
• Método de notificación (telefónico, automático, correo electrónico, presencial, etc.)
• Nombre / departamento / teléfono / ubicación del usuario
• Método de devolución de llamada (teléfono, correo, etc.)
• Descripción de los síntomas
• Estado del incidente (activo, en espera, cerrado , etc.)
• CI relacionados
• Grupo de apoyo / persona a la que se asigna el incidente
• Problema relacionado / Error conocido
• Actividades realizadas para resolver el incidente
• Fecha y hora de resolución
Página 92
• Categoría de cierre
• Fecha y hora de cierre.
Nota: Si la mesa de servicio no funciona las 24 horas del día, los 7 días de la semana y la responsabilidad de la primera línea
El registro y manejo de incidentes pasa a otro grupo, como Operaciones de TI o
Soporte de red, fuera del horario del Service Desk, entonces este personal debe estar igualmente
riguroso sobre el registro de los detalles del incidente. La formación y la concienciación completas deben
proporcionar a dicho personal sobre este tema.
4.2.5.3 Categorización de incidentes
Parte del registro inicial debe consistir en asignar una categorización de incidentes adecuada
codificación para que se registre el tipo exacto de llamada . Esto será importante más adelante
al mirar tipos / frecuencias de incidentes para establecer tendencias para su uso en Problema
Gestión , Gestión de proveedores y otras actividades de ITSM.
Tenga en cuenta que la verificación de las solicitudes de servicio en este proceso no implica
que las solicitudes de servicio son incidentes. Esto es simplemente un reconocimiento del hecho de que
Las solicitudes de servicio a veces se registran incorrectamente como incidentes (por ejemplo, un usuario
ingresa incorrectamente la solicitud como un incidente desde la interfaz web). Este cheque
detectará dichas solicitudes y se asegurará de que se pasen a la Solicitud
Proceso de cumplimiento .
La categorización de varios niveles está disponible en la mayoría de las herramientas, generalmente a tres o cuatro
niveles de granularidad. Por ejemplo, un incidente puede categorizarse como se muestra en
Figura 4.3.
Página 93
Figura 4.3 Categorización de incidentes de varios niveles
Todas las organizaciones son únicas y, por lo tanto, es difícil dar una orientación genérica.
en las categorías que una organización debería utilizar, especialmente en los niveles inferiores.
Sin embargo, existe una técnica que se puede utilizar para ayudar a una organización a
lograr un conjunto correcto y completo de categorías, si parten de
¡rasguño! Los pasos involucran:
1. Realice una sesión de lluvia de ideas entre los grupos de apoyo relevantes ,
involucrando al Supervisor SD ya los Gerentes de Incidentes y Problemas.
2. Utilice esta sesión para decidir las categorías de nivel superior de "mejor estimación", y
incluir una categoría "otro" . Configure las herramientas de registro relevantes para usar estas
categorías para un período de prueba.
3. Utilice las categorías durante un período de prueba corto (lo suficientemente largo para varios
cien incidentes para caer en cada categoría, pero no demasiado tiempo para que un
el análisis tardará demasiado en realizarse).
4. Realizar un análisis de las incidencias registradas durante el período de prueba. los
El número de incidentes registrados en cada categoría de nivel superior confirmará
si vale la pena tener las categorías - y un análisis más detallado de
la categoría 'otros' debe permitir la identificación de cualquier
categorías de nivel que serán necesarias.
Página 94
5. Un análisis detallado de los incidentes dentro de cada categoría de nivel superior

debe utilizarse para decidir las categorías de nivel inferior que se requerirán.
6. Revise y repita estas actividades después de un período adicional, digamos, de una a
tres meses, y nuevamente con regularidad para garantizar que sigan siendo relevantes. Ser
consciente de que cualquier cambio significativo en la categorización puede causar algunos
dificultades para la generación de informes de gestión o tendencias de incidentes, por lo que deben
estabilizarse a menos que se requieran realmente cambios.
Si se está utilizando un esquema de categorización existente, pero no se cree que esté funcionando
satisfactoriamente, la idea básica de la técnica sugerida anteriormente se puede utilizar para
revisar y modificar el esquema existente.
NOTA: A veces, los detalles disponibles en el momento en que se registra un incidente pueden ser
incompleta, engañosa o incorrecta. Por tanto, es importante que el
La categorización del incidente se verifica y, si es necesario, se actualiza en la llamada.
hora de cierre (en un campo de categorización de cierre separado , para no corromper el
categorización original); consulte el párrafo 4.2.5.9.
4.2.5.4 Priorización de incidentes
Otro aspecto importante del registro de cada incidente es acordar y asignar un

código de priorización apropiado, ya que esto determinará cómo se maneja el incidente
tanto por herramientas de apoyo como por personal de apoyo.
La priorización normalmente se puede determinar teniendo en cuenta tanto la urgencia

del incidente (la rapidez con la que la empresa necesita una resolución ) y el nivel de
impacto que está causando. Una indicación del impacto es a menudo (pero no siempre) el número
de usuarios afectados. En algunos casos, y muy importante, la pérdida de servicio
a un solo usuario puede tener un impacto comercial importante; todo depende de quién esté
tratando de hacer qué, ¡así que los números por sí solos no son suficientes para evaluar la prioridad general !
Otros factores que también pueden contribuir a los niveles de impacto son:
• Riesgo de muerte o de una extremidad

• El número de servicios afectados: pueden ser varios servicios.
• El nivel de pérdidas financieras
• Efecto en la reputación empresarial
• Incumplimientos normativos o legislativos.
Página 95
Una forma eficaz de calcular estos elementos y derivar una prioridad general
El nivel para cada incidente se da en la Tabla 4.1:
Impacto
Alto Medio Bajo
Alto 1 2 3
Urgencia Medio 2 3 4
Bajo 3 4 5
Código de prioridad Descripción Tiempo de resolución objetivo
1 Crítico 1 hora
2 Alto 8 horas
3 Medio 24 horas
4 Bajo 48 horas
5 Planificación Planificado
Tabla 4.1 Sistema de codificación de prioridad simple
En todos los casos, debe proporcionarse una orientación clara, con ejemplos prácticos, para todos
personal de apoyo para permitirles determinar los niveles correctos de urgencia e impacto,
por lo que se asigna la prioridad correcta. Dicha orientación debe producirse durante
negociaciones de nivel de servicio .
Sin embargo, debe tenerse en cuenta que habrá ocasiones en las que, debido a
conveniencia comercial particular o lo que sea, los niveles de prioridad normales deben ser
anulado.las
exceder Cuando
pautasun usuario ,insiste
normales en que
el Service el nivel
Desk debe de prioridad
cumplir con de un incidente
dicha solicitud: debe
y si posteriormente resulta ser incorrecto, esto se puede resolver como un fuera de línea
cuestión de nivel de gestión, en lugar de una disputa que se produce cuando el usuario está en el
teléfono.
Algunas organizaciones también pueden reconocer a VIP (ejecutivos de alto rango, oficiales,
diplomáticos, políticos, etc.) cuyos incidentes serían tratados con mayor prioridad
de lo normal, pero en tales casos es mejor tenerlo en cuenta y documentarlo en
la orientación proporcionada al personal de Service Desk sobre cómo aplicar la prioridad
niveles, por lo que todos conocen las reglas acordadas para los VIP, y quién cae en este
categoría .
Cabe señalar que la prioridad de un incidente puede ser dinámica, si las circunstancias
cambiar, o si un incidente no se resuelve dentro de los tiempos objetivo del SLA, entonces la prioridad
debe modificarse para reflejar la nueva situación.
Página 96
Nota: algunas herramientas pueden tener limitaciones que dificultan la

calcular el rendimiento frente a los objetivos de SLA si se cambia una prioridad durante el
vida de un incidente. Sin embargo, si las circunstancias cambian, el cambio en
debe hacerse prioridad y, si es necesario, hacer ajustes manuales a
herramientas de informes. Idealmente, no se deberían seleccionar herramientas con tales limitaciones.
4.2.5.5 Diagnóstico inicial
Si el incidente se ha enrutado a través de la mesa de servicio, el analista de la mesa de servicio

debe realizar el diagnóstico inicial , normalmente mientras el usuario todavía está hablando por teléfono -
si la llamada se realiza de esta manera, para tratar de descubrir todos los síntomas del incidente
y para determinar exactamente qué ha fallado y cómo corregirlo. Es en este
etapa en la que los guiones de diagnóstico y la información de errores conocidos pueden ser más valiosos en
permitiendo un diagnóstico más temprano y preciso.
Si es posible, el analista de la mesa de servicio resolverá el incidente mientras el usuario aún está
por teléfono - y cierre el incidente si la resolución es exitosa.
Si el analista de Service Desk no puede resolver el incidente mientras el usuario aún está
el teléfono, pero existe la posibilidad de que la Mesa de Servicio pueda hacerlo
dentro del límite de tiempo acordado sin la ayuda de otros grupos de apoyo , el
El analista debe informar al usuario de sus intenciones, informar al usuario sobre el incidente.
número de referencia e intente encontrar una resolución.
4.2.5.6 Escalada de incidentes
• Escalada funcional . Tan pronto como quede claro que el Service Desk
no puede resolver el incidente en sí mismo (o cuando los tiempos objetivo para el primer punto
se ha superado la resolución, ¡lo que ocurra primero!) el incidente
debe ser escalado de inmediato para obtener más apoyo.
Si la organización tiene un grupo de apoyo de segundo nivel y el Service Desk
cree que el incidente puede ser resuelto por ese grupo, debe remitir al
incidente a ellos. Si es obvio que el incidente necesitará información técnica más profunda
conocimiento - o cuando el grupo de segundo nivel no ha podido resolver
el incidente dentro de los tiempos objetivo acordados (lo que ocurra primero), el
incidente se debe escalar inmediatamente al tercer nivel apropiado
grupo de apoyo. Tenga en cuenta que los grupos de apoyo de tercer nivel pueden ser internos, pero
También pueden ser terceros, como proveedores de software o hardware.
fabricantes o mantenedores. Las reglas para la escalada y el manejo de
Los incidentes deben ser acordados en OLA y UC con internos y externos.
grupos de apoyo respectivamente.
Nota: ¡La propiedad del incidente permanece en el Service Desk! A pesar de

cuando se hace referencia a un incidente durante su vida, la propiedad del incidente
permanece en el Service Desk en todo momento. El Service Desk permanece
Página 97
responsable de seguir el progreso, mantener informados a los usuarios y, en última instancia,

para el cierre de incidentes .
• Escalada jerárquica . Si los incidentes son de naturaleza grave (por ejemplo

Incidentes de Prioridad 1) se debe notificar a los gerentes de TI correspondientes, para
con fines informativos al menos. La escalada jerárquica también se utiliza si el
Los pasos de 'Investigación y diagnóstico ' y ' Resolución y recuperación ' son
tardando demasiado o resultando demasiado difícil. La escalada jerárquica debería
Continuar en la cadena de gestión para que los altos directivos estén al tanto
y puede estar preparado y tomar cualquier acción necesaria, como asignar
recursos adicionales o la participación de proveedores / mantenedores. Jerárquico
La escalada también se utiliza cuando hay una disputa sobre a quién
se asigna el incidente .
La escalada jerárquica puede, por supuesto, ser iniciada por el usuario afectado o
gestión de clientes , como mejor les parezca; por eso es importante que TI
los gerentes son informados para que puedan anticipar y prepararse para cualquier
tal escalada.
Los niveles exactos y las escalas de tiempo para la escalada funcional y jerárquica.
deben acordarse, teniendo en cuenta los objetivos de SLA, e integrarse en
herramientas de soporte que luego se pueden utilizar para vigilar y controlar el flujo del proceso
dentro de los plazos acordados.
El Service Desk debe mantener informado al usuario de cualquier escalada relevante que
se lleva a cabo y asegúrese de que el Registro de incidentes se actualice en consecuencia para mantener un
historia de acciones.
Nota sobre la asignación de incidentes
Puede haber muchos incidentes en una cola con el mismo nivel de prioridad , por lo que
ser el trabajo del personal de Service Desk y / o Gestión de Incidentes inicialmente, en
en conjunto con los gerentes de los distintos grupos de apoyo a los que se refieren las incidencias
escalado, para decidir el orden en el que los incidentes deben ser recogidos y
trabajado activamente. Estos gerentes deben asegurarse de que los incidentes se traten en
verdadero orden de prioridad comercial y que el personal no está autorizado a seleccionar
incidentes que elijan!
4.2.5.7 Investigación y diagnóstico
En el caso de incidencias en las que el usuario solo busque información, el Servicio

El escritorio debe poder proporcionar esto con bastante rapidez y resolver la solicitud de servicio.
- pero si se informa de una falla , se trata de un incidente y es probable que requiera
grado de investigación y diagnóstico .
Página 98
Cada uno de los grupos de apoyo involucrados en el manejo del incidente investigará
y diagnosticar lo que ha fallado, y todas esas actividades (incluidos los detalles de
cualquier acción tomada para intentar resolver o recrear el incidente) debe ser completamente
documentado en el registro de incidentes para que un registro histórico completo de todos
Las actividades se mantienen en todo momento.
Nota: a menudo se puede perder un tiempo valioso si la investigación y la acción de diagnóstico (o

de hecho , acciones de resolución o recuperación ) se realizan en serie. Donde sea posible,
tales actividades deben realizarse en paralelo para reducir los plazos generales, y
Las herramientas de apoyo deben diseñarse y / o seleccionarse para permitir esto. Sin embargo, cuidado
debe tomarse para coordinar las actividades, en particular la resolución o recuperación
actividades, de lo contrario, las acciones de diferentes grupos pueden entrar en conflicto o
complicar una resolución!
Es probable que esta investigación incluya acciones como:
• Establecer exactamente lo que ha salido mal o lo que busca el usuario

• Comprender el orden cronológico de eventos s
• Confirmar el impacto total del incidente, incluido el número y el rango.
de usuarios afectados
• Identificar cualquier evento que pudiera haber desencadenado el incidente (por ejemplo, un incidente reciente).
cambio , alguna acción del usuario?)
• Búsquedas de conocimiento buscando ocurrencias anteriores mediante la búsqueda
Registro de incidentes / problemas anteriores y / o bases de datos de errores conocidos o
Registros de errores o bases de datos de conocimiento de los fabricantes / proveedores .
4.2.5.8 Resolución y recuperación
Cuando se ha identificado una resolución potencial , esta debe aplicarse y

probado. Las acciones específicas a realizar y las personas que participarán.
al tomar las acciones de recuperación pueden variar, dependiendo de la naturaleza de la falla :
pero podría involucrar:
• Pedir al usuario que realice actividades dirigidas en su propio escritorio o

equipo remoto
• La Mesa de Servicio que implementa la resolución de manera centralizada (digamos,
reiniciar un servidor ) o mediante software de forma remota para tomar el control de la
• escritorio
Se solicitapara
a losdiagnosticar e implementar
grupos de apoyo una resolución
de especialistas que implementen una recuperación específica
acciones (por ejemplo, Network Support reconfigurando un enrutador)
• Se solicita a un proveedor externo o mantenedor que resuelva la falla.
Incluso cuando se ha encontrado una resolución, se deben realizar pruebas suficientes para
Asegúrese de que la acción de recuperación esté completa y de que el servicio se haya completado
restaurar d a los usuarios.
Página 99
NOTA: en algunos casos puede ser necesario que dos o más grupos tomen
acciones de recuperación separadas, aunque quizás coordinadas, para una resolución general
A ser implementado. En tales casos, la Gestión de Incidentes debe coordinar la
actividades y enlace con todas las partes involucradas.
Independientemente de las acciones que se tomen, o de quién las lleve a cabo, el Registro de Incidentes debe ser
actualizado en consecuencia con toda la información y los detalles relevantes para que un historial completo
es mantenido.
El grupo de resolución debe remitir el incidente al Service Desk para

acción de cierre .
4.2.5.9 Cierre de incidentes
El Service Desk debe verificar que el incidente esté completamente resuelto y que el
los usuarios están satisfechos y dispuestos a aceptar que se puede cerrar el incidente . El servicio
El escritorio también debe verificar lo siguiente:
• Categorización de cierre. Verifique y confirme que el incidente inicial

la categorización era correcta o, cuando la categorización posteriormente
resultó ser incorrecta, actualice el registro para que un cierre correcto
Se registra la categorización del incidente: se solicita asesoramiento u orientación.
del (de los) grupo (s) de resolución, según sea necesario.
• Encuesta de satisfacción del usuario. Realice una devolución de llamada de satisfacción del usuario o un correo electrónico
encuesta para el porcentaje acordado de incidencias.
• Documentación de incidentes. Persiga cualquier detalle sobresaliente y asegúrese de que
el registro de incidentes está completamente documentado para que un registro histórico completo en un
suficiente nivel de detalle está completo.
• ¿ Problema continuo o recurrente ? Determine (junto con el resolutor
grupos) si es probable que el incidente se repita y decida
si es necesaria alguna acción preventiva para evitarlo. En conjunto
con Gestión de problemas , genere un Registro de problemas en todos estos casos para
que se inicie la acción preventiva.
• Cierre formal . Cierre formalmente el registro de incidentes .
Nota: Algunas organizaciones pueden optar por utilizar un período de cierre automático en
incidentes específicos, o incluso todos (por ejemplo, el incidente se cerrará automáticamente después de dos
días laborables si el usuario no se pone en contacto ). Donde este enfoque es para
ser considerado, primero debe ser discutido y acordado completamente con los usuarios, y
ampliamente publicitado para que todos los usuarios y el personal de TI estén al tanto de esto. Puede ser
inadecuado utilizar este método para ciertos tipos de incidentes - como importante
incidentes o los que involucran a VIP, etc.
Página 100
Reglas para reabrir incidentes
A pesar de toda la atención adecuada, habrá ocasiones en las que los incidentes se repitan incluso
aunque han sido formalmente cerrados. Debido a tales casos, es aconsejable tener
reglas predefinidas sobre si un incidente puede reabrirse y cuándo. Podría hacer
sentido, por ejemplo, acordar que si el incidente se repite dentro de un día hábil
entonces se puede reabrir, pero que más allá de este punto se debe producir un nuevo incidente.
planteado, pero vinculado a los incidentes anteriores.
El límite de tiempo exacto / las reglas pueden variar entre organizaciones individuales, pero
Se deben acordar y documentar reglas claras y se debe brindar orientación a todos los servicios.
Personal de escritorio para que se aplique la uniformidad.
Los incidentes pueden desencadenarse de muchas formas. La ruta más común es cuando un usuario
llama al Service Desk o completa una pantalla de registro de incidentes basada en la web, pero
cada vez más incidentes se generan automáticamente a través de herramientas de gestión de eventos .
El personal técnico puede notar fallas potenciales y plantear un incidente, o preguntar al
Service Desk para hacerlo, de modo que se pueda solucionar la falla . Algunos incidentes pueden
también surgen al inicio de los proveedores , que pueden enviar algún tipo de notificación
de una dificultad potencial o real que necesita atención.
Las interfaces con la gestión de incidentes incluyen:
• Gestión de problemas : la gestión de incidentes forma parte del

proceso de abordar los problemas en la organización . Los incidentes son a menudo
causado por problemas subyacentes, que deben resolverse para evitar la
incidente se repita. La gestión de incidentes proporciona un punto donde
estos se informan.
• La gestión de la configuración proporciona los datos utilizados para identificar y
incidentes de progreso. Uno de los usos del CMS es identificar fallas
equipo y para evaluar el impacto de un incidente. También se utiliza para
identificar a los usuarios afectados por problemas potenciales. El CMS también contiene
información sobre las categorías de incidentes que deben asignarse
qué grupo de apoyo . A su vez, la gestión de incidentes puede mantener la
estado de los CI defectuosos. También puede ayudar a Configuration Management a auditar
la infraestructura cuando se trabaja para resolver una incidencia.
• Gestión de cambios : cuando se requiere un cambio para implementar un
solución alternativa o resolución, esto deberá registrarse como un RFC y
progresó a través de la Gestión del Cambio. A su vez, Gestión de incidentes
es capaz de detectar y resolver incidencias que surgen de cambios fallidos.
• Gestión de la capacidad : la gestión de incidentes proporciona un desencadenante para
Monitoreo del desempeño donde parece haber un desempeño
problema. La gestión de la capacidad puede desarrollar soluciones alternativas para los incidentes.
Página 101
• Gestión de disponibilidad ; utilizará los datos de gestión de incidentes para determinar

la disponibilidad de los servicios de TI y observe dónde puede el ciclo de vida del incidente
Ser mejorado.
• SLM: La capacidad de resolver incidentes en un tiempo específico es una parte clave de
entregando un nivel de servicio acordado . La gestión de incidentes habilita SLM
para definir respuestas medibles a las interrupciones del servicio. También proporciona
informes que permiten que SLM revise los SLA de manera objetiva y regular. En
En particular, la gestión de incidentes puede ayudar a definir dónde
Los servicios están en su punto más débil, por lo que SLM puede definir acciones como parte de
el Servicio de Mejoramiento de Programa (SIP) - por favor ver el continuo
Publicación de mejora del servicio para obtener más detalles. SLM define el
niveles aceptables de servicio dentro de los cuales funciona la gestión de incidentes,
incluso:
• Tiempo de respuesta a incidentes s
• Definiciones de impacto
• Tiempos de corrección objetivo
• Definiciones de servicios, que se asignan a los usuarios.
• Reglas para solicitar servicios
• Expectativas de proporcionar retroalimentación a los usuarios .
La mayor parte de la información utilizada en la gestión de incidentes proviene de los siguientes

fuentes:
• Las herramientas de gestión de incidentes , que contienen información sobre:

• Historial de incidentes y problemas
• Categorías de incidentes
• Acción tomada para resolver incidentes
• Guiones de diagnóstico que pueden ayudar a los analistas de primera línea a resolver la
incidente, o al menos recopilar información que ayude a un segundo o
Los analistas de tercera línea lo resuelven más rápido.
• Registro incidente s , que incluyen los datos siguientes:
• Número de referencia único
• Clasificación de incidentes
• Fecha y hora de grabación y cualquier actividad posterior.
• Nombre e identidad de la persona que registra y actualiza el
Registro de incidentes
• Nombre / organización / datos de contacto de los usuarios afectados
• Descripción de los síntomas del incidente
• Detalles de las acciones tomadas para intentar diagnosticar, resolver o recrear
el incidente
• Categoría , impacto , urgencia y prioridad del incidente
• Relación con otros incidentes , problemas , cambios o conocidos
Error s
Página 102
• Detalles del cierre , incluida la hora, la categoría , la acción realizada y la identidad

de la persona que cierra el registro .
La gestión de incidentes también requiere acceso al CMS. Esto le ayudará a identificar

los CI afectados por el incidente y también para estimar el impacto del incidente.
La base de datos de errores conocidos proporciona información valiosa sobre posibles

resoluciones y soluciones alternativas . Esto se analiza en detalle en el párrafo 4.4.7.2.
4.2.8 Métricas
Las métricas que deben ser monitoreadas y reportadas para juzgar la eficiencia
y la eficacia del proceso de gestión de incidentes , y su funcionamiento ,
incluir:
• Número total de incidentes (como medida de control )

• Desglose de incidentes en cada etapa (por ejemplo, registrados, trabajo en progreso ,
cerrado, etc.)
• Tamaño de la acumulación de incidentes actual
• Número y porcentaje de los principales incidentes s
• Tiempo medio transcurrido para lograr la resolución o elusión del incidente, roto
abajo por código de impacto
• Porcentaje de incidentes manejados dentro del tiempo de respuesta acordado (incidente
Los objetivos de tiempo de respuesta pueden especificarse en SLA, por ejemplo, por impacto
y códigos de urgencia )
• Costo promedio por incidente
• Número de incidentes reabiertos y como porcentaje del total
• Número y porcentaje de incidentes asignados incorrectamente
• Número y porcentaje de incidentes categorizados incorrectamente
• Porcentaje de incidentes cerrados por Service Desk sin referencia a
otros niveles de apoyo (a menudo denominado 'primer punto de contacto')
• Número y porcentaje de incidentes procesados por Service Desk
agente
• Número y porcentaje de incidencias resueltas de forma remota, sin necesidad
para una visita
• Número de incidentes manejados por cada modelo de incidente
• Desglose de incidentes por hora del día, para ayudar a identificar picos y asegurar
emparejamiento de recursos s.
Los informes deben producirse bajo la autoridad del Gerente de Incidentes, quien
debe elaborar un cronograma y lista de distribución, en colaboración con el Servicio
El escritorio y el grupo de apoyo manejan incidentes. Las listas de distribución deben al menos
incluyen servicios de TI, gestión y grupos de apoyo especializados . Considere también
poner los datos a disposición de los usuarios y clientes , por ejemplo, a través de informes SLA.
Página 103
4.2.9.1 Desafíos
Existirán los siguientes desafíos para una gestión de incidentes exitosa :
• La capacidad de detectar incidentes lo antes posible. Esto requerirá

la educación del usuario incidentes de informes s, el uso de Super Usuario s (ver
párrafo 6.2.4.5) y la configuración de las herramientas de gestión de eventos .
• Convencer a todo el personal (equipos técnicos y usuarios) de que todas las incidencias
debe estar registrado, y fomentar el uso de autoayuda basados en la web
capacidades (que pueden acelerar la asistencia y reducir los recursos
requisito s).
• Disponibilidad de información sobre problemas y errores conocidos . Esta voluntad
permitir que el personal de gestión de incidentes aprenda de incidentes anteriores y
también para rastrear el estado de las resoluciones .
• Integración en el CMS para determinar las relaciones entre los CI y para
consulte el historial de CI cuando realice el soporte de primera línea .
• Integración en el proceso SLM . Esto ayudará a la gestión de incidentes
correctamente para evaluar el impacto y la prioridad de los incidentes y ayuda a
definir y ejecutar procedimientos de escalamiento s. SLM también se beneficiará de
la información aprendida durante la gestión de incidentes, por ejemplo en
determinar si los objetivos de rendimiento del nivel de servicio son realistas y
realizable.
4.2.9.2 Factores críticos para el éxito
Los siguientes factores serán fundamentales para el éxito de la gestión de incidentes:
• Un buen Service Desk es clave para una gestión exitosa de incidentes

• Objetivos claramente definidos para trabajar, según se definen en los SLA
• Personal de soporte técnico adecuado y orientado al cliente con la
niveles de habilidad correctos, en todas las etapas del proceso
• Herramientas de soporte integradas para impulsar y controlar el proceso
• OLA y UC que son capaces de influir y dar forma a la correcta
comportamiento de todo el personal de apoyo.
4.2.9.3 Riesgos
Los riesgos para la gestión exitosa de incidentes son en realidad similares a algunos de los
desafíos y el reverso de algunos de los factores críticos de éxito mencionados
sobre. Incluyen:
• Estar inundado de incidentes que no se pueden manejar dentro de lo aceptable

escalas de tiempo debido a una falta de disposición o formación adecuada de recursos s
Página 104
• Los incidentes se estancaron y no progresaron como se esperaba debido a

Herramientas de apoyo inadecuadas para generar alertas y acelerar el progreso.
• Falta de fuentes de información adecuadas y / o oportunas debido a
herramientas inadecuadas o falta de integración
• Discrepancias en los objetivos o acciones debido a una alineación deficiente o
OLA y / o UC existentes.
Página 105
4.3 Cumplimiento de la solicitud
El término ' Solicitud de servicio ' se utiliza como descripción genérica para muchos
tipos de demandas que los usuarios imponen al Departamento de TI . Muchos de
En realidad, se trata de cambios pequeños: de bajo riesgo , frecuentes, de bajo coste , etc.
(por ejemplo, una solicitud para cambiar una contraseña, una solicitud para instalar un software adicional
aplicación en una estación de trabajo en particular, una solicitud para reubicar algunos elementos de
equipo de escritorio) o tal vez solo una pregunta solicitando información, pero su
escala y naturaleza frecuente, de bajo riesgo significa que son mejor manejados por un
proceso separado , en lugar de permitir que congestionen y obstruyan el proceso normal
Procesos de gestión de incidencias y cambios .
El cumplimiento de solicitudes es el proceso de tratar las solicitudes de servicio del

usuarios. Los objetivos del proceso de Cumplimiento de Solicitudes incluyen:
• Proporcionar un canal para que los usuarios soliciten y reciban servicios estándar.
para los cuales existe un proceso de aprobación y calificación predefinido
• Para proporcionar información a los usuarios y clientes sobre la disponibilidad de
servicios y el procedimiento para obtenerlos
• Obtener y entregar los componentes de los servicios estándar solicitados
(por ejemplo, licencias y medios de software)
• Para ayudar con información general, quejas o comentarios.
4.3.2 Alcance
El proceso necesario para cumplir con una solicitud variará dependiendo exactamente de lo que se
solicitadas, pero por lo general se pueden dividir en un conjunto de actividades que
tiene que ser realizado. Algunas organizaciones se sentirán cómodas para permitir que el Servicio
Las solicitudes se manejarán a través de sus procesos (y herramientas) de gestión de incidentes :
con las solicitudes de servicio que se manejan como un tipo particular de ' incidente ' (utilizando un
sistema de categorización de alto nivel para identificar aquellos 'incidentes' que de hecho son
Solicitudes de servicio).
Sin embargo, tenga en cuenta que aquí hay una diferencia significativa: un incidente suele
un evento no planificado , mientras que una solicitud de servicio suele ser algo que puede
¡y debe ser planificado!
Por lo tanto, en una organización donde un gran número de solicitudes de servicio deben
ser manejados, y donde las acciones a tomar para cumplir con esas solicitudes son muy
variada o especializada, puede ser apropiado manejar las Solicitudes de Servicio como un
flujo de trabajo completamente separado, y para registrarlos y administrarlos como un
tipo de registro separado .
Página 106
Esto puede ser particularmente apropiado si la organización ha optado por ampliar el

alcance de la Mesa de Servicio para expandir solo los problemas relacionados con TI y usar el
escritorio como punto focal para otros tipos o solicitud de servicio, por ejemplo, un
solicitar el servicio de una fotocopiadora o incluso ir tan lejos como para incluir, por ejemplo,
Problemas de gestión del edificio, como la necesidad de reemplazar un accesorio de iluminación o reparar un
Fuga en la plomería.
Nota: En última instancia, dependerá de cada organización decidir y documentar qué

solicitar que maneje a través del proceso de Cumplimiento de Solicitudes y que otros
tendrá que pasar por una Gestión del Cambio más formal. Siempre estara
áreas grises que impiden que se prescriba una guía genérica de manera útil.
El valor del cumplimiento de solicitudes es proporcionar un acceso rápido y eficaz a

servicios estándar que el personal de la empresa puede utilizar para mejorar su productividad o
la calidad de los servicios y productos comerciales.
El cumplimiento de solicitudes reduce efectivamente la burocracia involucrada en solicitar

y recibir acceso a servicios nuevos o existentes, reduciendo así también el costo de
proporcionar estos servicios. Centralizar el cumplimiento también aumenta el nivel de control
sobre estos servicios. Esto, a su vez, puede ayudar a reducir los costos mediante
negociación con los proveedores , y también puede ayudar a reducir el costo de soporte.
Muchas solicitudes de servicio serán recurrentes con frecuencia, por lo que un flujo de proceso predefinido
(un modelo ) puede ser ideado para incluir las etapas necesarias para cumplir con la solicitud, el
individuos o grupos de apoyo involucrados, escalas de tiempo objetivo y rutas de escalamiento .
Las solicitudes de servicio generalmente se satisfarán mediante la implementación de un cambio estándar
(Consulte la publicación Transición del servicio para obtener más detalles sobre los cambios estándar).
La propiedad de las solicitudes de servicio reside en la mesa de servicio , que
monitorea, escala, despacha y, a menudo, satisface la solicitud del usuario .
4.3.4.1 Solicitar modelos
Algunas solicitudes de servicio ocurrirán con frecuencia y requerirán manejo en un

de manera coherente para cumplir con los niveles de servicio acordados . Para ayudar en esto, muchos
Las organizaciones desearán crear modelos de solicitud predefinidos (que normalmente
incluir alguna forma de aprobación previa por parte de Change Management ). Esto es similar en
concepto a la idea de modelos de incidentes ya descrita en el párrafo 4.2.4.2,
pero se aplica a las solicitudes de servicio.
4.3.5.1 Selección de menú
Página 107
El cumplimiento de solicitudes ofrece grandes oportunidades para las prácticas de autoayuda en las que los usuarios
puede generar una solicitud de servicio utilizando tecnología que se vincula al servicio
Herramientas de gestión . Idealmente, a los usuarios se les debería ofrecer una selección de tipo 'menú' a través de un
interfaz web, para que puedan seleccionar e ingresar detalles de las solicitudes de servicio de
una lista predefinida, donde las expectativas apropiadas se pueden establecer dando objetivo
objetivos / fechas de entrega y / o implementación (en línea con los objetivos de SLA). Dónde
organizaciones están ofreciendo una capacidad de soporte de TI de autoayuda a los usuarios, sería
Tiene sentido combinar esto con un sistema de cumplimiento de solicitudes como se describe.
Las herramientas web especializadas para ofrecer este tipo de experiencia de 'cesta de la compra' pueden ser
utilizado junto con interfaces directamente a las herramientas ITSM integradas de back-end, o
otra automatización de procesos de negocio más general o recurso empresarial
Herramientas de planificación (ERP) que pueden utilizarse para la gestión de la Solicitud
Actividades de cumplimiento.
4.3.5.2 Aprobación financiera
Un paso adicional importante que probablemente sea necesario al tratar con un servicio
La solicitud es la de aprobación financiera.
La mayoría de las solicitudes tendrán algún tipo de implicaciones financieras, independientemente de la

tipo de acuerdos comerciales vigentes. El costo de cumplir con la solicitud debe
primero se establezca. Puede ser posible acordar precios fijos para 'estándar'
solicitudes, y la aprobación previa para tales solicitudes se puede dar como parte de la
organización ‘s anual global de gestión financiera . En todos los demás casos, un
Se debe producir una estimación del costo y enviarla al usuario para fines financieros.
aprobación (el usuario puede necesitar buscar la aprobación de su gestión / financiera
cadena). Si se da la aprobación, además de cumplir con la solicitud, el proceso debe
También incluya el cobro (facturación o cobro cruzado) por el trabajo realizado, si el cobro es
en su lugar.
4.3.5.3 Otra aprobación
En algunos casos, puede ser necesaria una aprobación adicional, como relacionada con el cumplimiento o
aprobación comercial más amplia. El cumplimiento de la solicitud debe tener la capacidad de definir y
verifique dichas aprobaciones cuando sea necesario.
4.3.5.4 Cumplimiento
La actividad de cumplimiento real dependerá de la naturaleza de la Solicitud de servicio .

Algunas solicitudes más simples pueden ser completadas por la Mesa de Servicio , actuando como primera
soporte de línea , mientras que otros tendrán que ser enviados a grupos de especialistas y / o
proveedores para el cumplimiento.
Algunas organizaciones pueden tener grupos de cumplimiento especializados (para 'recoger, empacar y
despacho ') - o puede haber subcontratado algunas actividades de cumplimiento a un tercero
Página 108
proveedor (s). El Service Desk debe monitorear y perseguir el progreso y mantener

el usuario está informado en todo momento, independientemente de la fuente de cumplimiento real.
4.3.5.5 Cierre
Una vez cumplida la Solicitud de servicio, debe remitirse de nuevo al

Mesa de servicio para cierre . El Service Desk debe pasar por el mismo cierre
proceso como se describe anteriormente en el párrafo 4.2.5.9 - comprobar que el usuario
satisfecho con el resultado .
La mayoría de las solicitudes se activarán a través de un usuario que llame al Service Desk o
un usuario que completa algún tipo de pantalla de entrada de autoayuda basada en la web para hacer su
petición. Esto último a menudo implicará una selección de una cartera de
tipos de solicitud Las interfaces principales con el cumplimiento de solicitudes incluyen:
• Mesa de servicio / gestión de incidentes : muchas solicitudes de servicio pueden venir

a través de la Mesa de Servicio y puede ser manejado inicialmente a través del Incidente
Proceso de gestión. Algunas organizaciones pueden optar por que todas las solicitudes
se manejan a través de esta ruta, pero otros pueden optar por tener una
proceso, por razones ya discutidas anteriormente en este capítulo.
• También se necesita un vínculo sólido entre el cumplimiento de la solicitud, el lanzamiento ,
Gestión de activos y configuración , ya que algunas solicitudes serán para
Implementación de componentes nuevos o actualizados que se pueden
desplegada. En tales casos, el 'lanzamiento' puede predefinirse, construirse y probarse
pero solo se despliega a pedido de aquellos que quieren la 'liberación'. Sobre
implementación, el CMS deberá actualizarse para reflejar el cambio . Dónde
apropiadas, también serán necesarias verificaciones / actualizaciones de licencias de software.
Cuando corresponda, será necesario relacionar las Solicitudes de servicio relacionadas con TI con
cualquier incidente o problema que haya iniciado la necesidad de la solicitud (como
sea el caso de cualquier otro tipo de cambio).
El cumplimiento de la solicitud depende de la información de las siguientes fuentes:
• Las solicitudes de servicio contendrán información sobre:

• Qué servicio se solicita
• Quién solicitó y autorizó el servicio
• Qué proceso se utilizará para cumplir con la solicitud
• A quién se asignó y qué medidas se tomaron
• La fecha y hora en que se registró la solicitud, así como la fecha.
y hora de todas las acciones tomadas
• Detalles de cierre.
Página 109
• Solicitudes de cambio: en algunos casos, el proceso de cumplimiento de solicitudes

ser iniciado por un RFC. Esto es típico cuando se relaciona la Solicitud de servicio
a un CI
• La cartera de servicios , para permitir que el alcance de la solicitud de servicio acordada
ser identificado
• Las políticas de seguridad prescribirán los controles que se ejecutarán o cumplirán
al proporcionar el servicio, por ejemplo, asegurándose de que el solicitante está autorizado
para acceder al servicio, o que el software tiene licencia.
4.3.8 Métricas
Las métricas necesarias para juzgar la eficacia y eficiencia de Request

El cumplimiento incluirá lo siguiente (cada métrica deberá desglosarse por
tipo de solicitud, dentro del período):
• El número total de solicitudes de servicio (como medida de control )

• Desglose de las solicitudes de servicio en cada etapa (por ejemplo, registradas, WIP, cerradas ,
etc.)
• El tamaño de la acumulación actual de solicitudes de servicio pendientes
• El tiempo medio transcurrido para manejar cada tipo de solicitud de servicio.
• El número y porcentaje de solicitudes de servicio completadas dentro de los
tiempos objetivo
• El costo promedio por tipo de solicitud de servicio
• Nivel de satisfacción del cliente con el manejo de solicitudes de servicio (como
medido en alguna forma de encuesta de satisfacción).
4.3.9.1 Desafíos
Los siguientes desafíos se enfrentarán al introducir el cumplimiento de solicitudes:
• Definir y documentar claramente el tipo de solicitudes que se manejarán.

dentro del proceso de Cumplimiento de la Solicitud (y aquellos que irán
a través de la Mesa de Servicio y ser manejados como incidentes o aquellos que
necesidad de pasar por la Gestión del Cambio formal ), de modo que todas las partes estén
absolutamente claro en el alcance.
• El establecimiento de autoayuda capacidades front-end que permiten que el usuario es a
interactuar con éxito con el proceso de cumplimiento de solicitudes .
4.3.9.2 Factores críticos de éxito
El cumplimiento de la solicitud depende de los siguientes factores críticos de éxito :
• Acuerdo de qué servicios se estandarizarán y quién está autorizado para

solicítelos. El coste de estos servicios también debe ser acordado. Esto puede
Página 110
realizarse como parte del proceso SLM. Cualquier variación de los servicios debe
también se definirá.
• Publicación de los servicios a los usuarios como parte del Catálogo de Servicios . Es
importante que se pueda acceder fácilmente a esta parte del catálogo de servicios,
tal vez en la Intranet, y debería ser reconocido como la primera fuente de
información para usuarios que buscan acceso a un servicio .
• Definición de un procedimiento estándar de cumplimiento para cada uno de los servicios que se
solicitado. Esto incluye todas las políticas de adquisiciones y la capacidad de
generar órdenes de compra y órdenes de trabajo
• Un único punto de contacto que se puede utilizar para solicitar el servicio. Este es
proporcionado a menudo por la Mesa de Servicio o mediante una solicitud de Intranet, pero
podría ser a través de una solicitud automatizada directamente en la Solicitud
Sistema de cumplimiento o adquisiciones .
• Herramientas de autoservicio necesarias para proporcionar una interfaz frontal a los usuarios. Es
Es esencial que se integren con las herramientas de cumplimiento de back-end, a menudo
gestionado a través de Incidencias o Gestión de Cambios .
4.3.9.3 Riesgos
Los riesgos que se pueden encontrar con el cumplimiento de la solicitud incluyen:
• Alcance mal definido , donde las personas no tienen claro exactamente cuál es el
Se espera que el proceso maneje
• Interfaces de usuario mal diseñadas o implementadas para que los usuarios
dificultad para plantear las solicitudes que necesitan
• Procesos de cumplimiento back-end mal diseñados u operados que son
incapaz de atender el volumen o la naturaleza de las solicitudes que se realizan
• Capacidades de monitoreo inadecuadas , por lo que no se pueden obtener métricas precisas.
reunido.
Página 111
4.4 Gestión de problemas
ITIL define un ' problema ' como la causa de uno o más incidentes .
La gestión de problemas es el proceso responsable de gestionar el ciclo de vida de todos
problemas. Los objetivos principales de la gestión de problemas son prevenir
que ocurran problemas e incidentes resultantes, para eliminar los incidentes recurrentes
y minimizar el impacto de incidentes que no se pueden prevenir.
4.4.2 Alcance
La gestión de problemas incluye las actividades necesarias para diagnosticar la causa raíz.
de incidentes y para determinar la resolución de dichos problemas . Tambien es
responsable de asegurar que la resolución se implemente a través del
Procedimientos de control apropiados , especialmente Gestión de cambios y Liberación.
Gestión .
La gestión de problemas también mantendrá información sobre problemas y

soluciones y soluciones alternativas adecuadas , de modo que la organización pueda
Reducir el número y el impacto de los incidentes a lo largo del tiempo. A este respecto, Problema
La administración tiene una interfaz sólida con la administración del conocimiento y las herramientas
como la Base de datos de errores conocidos se utilizará para ambos.
Aunque la gestión de incidentes y problemas son procesos separados,

estrechamente relacionados y normalmente utilizarán las mismas herramientas, y pueden utilizar similares
sistemas de categorización, impacto y codificación de prioridad s. Esto asegurará una
comunicación cuando se trata de incidentes y problemas relacionados.
La gestión de problemas trabaja junto con la gestión de incidentes y el cambio.

Gestión para garantizar que se incremente la disponibilidad y la calidad del servicio de TI .
Cuando se resuelven los incidentes, se registra información sobre la resolución. Sobre
tiempo, esta información se utiliza para acelerar el tiempo de resolución e identificar
soluciones permanentes, reduciendo el número y tiempo de resolución de incidencias. Esta
resulta en menos tiempo de inactividad y menos interrupciones en los sistemas críticos del negocio.
El valor adicional se deriva de lo siguiente:
• Mayor disponibilidad de servicios de TI

• Mayor productividad del personal comercial y de TI
• Reducción del gasto en soluciones alternativas o arreglos que no funcionan
• Reducción del coste de esfuerzo en la extinción de incendios o resolución de incidencias repetidas.
Página 112
Hay algunos conceptos importantes de gestión de problemas que deben tenerse en cuenta
en cuenta desde el principio. Éstos incluyen:
4.4.4.1 Modelos de problemas
Muchos problemas serán únicos y requerirán un tratamiento individual, pero
Es concebible que algunos incidentes puedan repetirse debido a causas latentes o subyacentes.
problemas (por ejemplo, donde el costo de una resolución permanente será alto y
Se ha tomado la decisión de no seguir adelante con una solución costosa, sino de
'vivir con' el problema).
Además de crear un registro de errores conocidos en la base de datos de errores conocidos (consulte
párrafo 4.4.5.7) para garantizar un diagnóstico más rápido , la creación de un modelo de problema
para manejar estos problemas en el futuro puede ser útil. Esto es muy similar en
concepto a la idea de modelos de incidentes ya descrita en el párrafo 4.2.4.2,
pero aplicado tanto a problemas como a incidentes.
La gestión de problemas consta de dos procesos principales:
• Gestión reactiva de problemas , que generalmente se ejecuta como parte de

Operación del servicio, por lo que se trata en esta publicación.
• Gestión proactiva de problemas que se inicia en la operación del servicio ,
pero generalmente impulsado como parte de la Mejora Continua del Servicio .
El proceso reactivo de Gestión de Problemas se muestra en la Figura 4.4. Esto es un

gráfico simplificado para mostrar el flujo normal del proceso, pero en realidad algunos de los estados
puede ser iterativo o puede ser necesario realizar variaciones para manejar
situaciones.
Página 113
Figura 4.4 Flujo del proceso de gestión de problemas
4.4.5.1 Detección de problemas
Es probable que existan múltiples formas de detectar problemas en todas las organizaciones.
Estos incluirán:
Página 114
• Sospecha o detección de una causa de una o más incidencias por parte del Servicio
Escritorio, lo que resulta en un registro de problemas que se levanta - el escritorio puede tener
resuelto el incidente pero no ha determinado una causa definitiva y
sospecha que es probable que se repita, por lo que generará un Registro de problemas para permitir
la causa subyacente a resolver. Alternativamente, puede ser inmediatamente
obvio desde el principio que un incidente, o incidentes, ha sido causado por
un problema importante, por lo que se generará un Registro de problemas sin demora.
• Análisis de una incidencia por parte de un grupo de soporte técnico que revela que un
existe un problema subyacente, o es probable que exista.
• Detección automatizada de una falla de infraestructura o aplicación , utilizando
herramientas de eventos / alertas automáticamente para generar un incidente que pueda revelar la
necesidad de un registro de problemas.
• Una notificación de un proveedor o contratista de que existe un problema que debe
ser resuelto.
• Análisis de incidentes como parte de la gestión proactiva de problemas - resultante
en la necesidad de generar un registro de problemas para que la falla subyacente pueda ser
investigado más.
Se deben realizar análisis frecuentes y regulares de los datos de incidentes y problemas para
Identifique cualquier tendencia a medida que se haga perceptible. Esto requerirá
categorización detallada de incidentes / problemas e informes periódicos de patrones
y áreas de alta ocurrencia. Informes 'Top ten', con capacidades de desglose para
niveles más bajos, es útil para identificar tendencias.
Se incluyen más detalles sobre cómo deben manejarse las tendencias detectadas en el
4.4.5.2 Registro de problemas
Independientemente del método de detección , todos los detalles relevantes del problema deben
ser registrado para que exista un registro histórico completo . Esta debe ser la fecha y la hora
estampado para permitir un control y escalamiento adecuados .
Se debe hacer una referencia cruzada a los incidentes que iniciaron el Problema.
Registro - y todos los detalles relevantes deben copiarse de los registros de incidentes a
el registro de problemas. Es difícil ser exacto, ya que los casos pueden variar, pero normalmente
esto incluirá detalles como:
• Detalles del usuario

• Detalles del servicio
• Detalles del equipo
• Fecha / hora registrada inicialmente
• Detalles de prioridad y categorización
• Descripción del incidente
• Detalles de todas las acciones de diagnóstico o intentos de recuperación tomadas.
Página 115
4.4.5.3 Categorización de problemas
Los problemas deben categorizarse de la misma manera que los incidentes (y es aconsejable
utilizar el mismo sistema de codificación ) para que la verdadera naturaleza del problema pueda ser
se puede rastrear fácilmente en el futuro y se puede obtener información de gestión significativa
adquirido.
4.4.5.4 Priorización de problemas
Los problemas deben priorizarse de la misma manera y por las mismas razones que
incidentes, pero también se deben tomar en cuenta la frecuencia y el impacto de los incidentes relacionados
en cuenta. El sistema de codificación descrito anteriormente en la Tabla 4.1 (que combina
impacto con urgencia para dar un nivel de prioridad general) se puede utilizar para priorizar
problemas de la misma manera que podría usarse para incidentes, aunque el
definiciones y orientación para apoyar al personal sobre lo que constituye un problema, y la
Los objetivos de servicio relacionados en cada nivel, obviamente, deben diseñarse por separado.
La priorización de problemas también debe tener en cuenta la gravedad de los problemas.

La gravedad en este contexto se refiere a la gravedad del problema de una infraestructura.
perspectiva, por ejemplo:
• ¿Se puede recuperar el sistema o es necesario reemplazarlo?

• ¿Cuánto costará ?
• ¿Cuántas personas, con qué habilidades, se necesitarán para solucionar el problema?
• ¿Cuánto tiempo llevará solucionar el problema?
• ¿Qué tan extenso es el problema (por ejemplo, cuántos IC se ven afectados)?
4.4.5.5 Investigación y diagnóstico de problemas
Se debe realizar una investigación para tratar de diagnosticar la causa raíz de la

problema: la velocidad y la naturaleza de esta investigación variarán según el
impacto, gravedad y urgencia del problema, pero el nivel adecuado de
Se deben aplicar recursos y experiencia para encontrar una resolución acorde
con el código de prioridad asignado y el objetivo de servicio establecido para esa prioridad
nivel.
Hay una serie de técnicas útiles para la resolución de problemas que se pueden utilizar para
ayudan a diagnosticar y resolver problemas, y estos deben usarse según corresponda.
Estas técnicas se describen con más detalle más adelante en esta sección.
El CMS debe usarse para ayudar a determinar el nivel de impacto y para ayudar en
señalando y diagnosticando el punto exacto de falla . La base de datos de errores Know
(KEDB) también debe ser accedido y técnicas de búsqueda de problemas (como claves
búsquedas de palabras) deben usarse para ver si el problema ha ocurrido antes y, si
entonces, para encontrar la resolución.
Página 116
A menudo es valioso tratar de recrear la falla, a fin de comprender lo que ha ocurrido.

salió mal, y luego probar varias formas de encontrar el más apropiado y
resolución rentable del problema . Para hacer esto de manera efectiva sin causar
más interrupciones para los usuarios , será necesario un sistema de prueba que refleje el
entorno de producción .
Hay muchas técnicas de análisis, diagnóstico y resolución de problemas disponibles.

y se ha realizado mucha investigación en esta área. Algunos de los más útiles y
Las técnicas de uso frecuente incluyen:
• Análisis cronológico : cuando se trata de un problema difícil, hay

informes a menudo contradictorios sobre exactamente lo que ha sucedido y cuándo. Es
por lo tanto, es muy útil documentar brevemente todos los eventos en orden cronológico
- proporcionar una cronología de los eventos. Esto a menudo permite ver qué
Los eventos pueden haber sido provocados por otros, o para descartar cualquier reclamo que
no están respaldados por la secuencia de eventos.
• Análisis del valor del dolor : aquí es donde se toma una visión más amplia del impacto
de un incidente o problema, o del tipo de incidente / problema. En lugar de solo
Analizar el número de incidentes / problemas de un tipo particular en un
período particular, se realiza un análisis más profundo para determinar exactamente
¿Qué nivel de dolor le han causado a la organización / empresa estos
incidentes / problemas. Se puede diseñar una fórmula para calcular este nivel de dolor.
Normalmente, esto podría incluir tener en cuenta:
• El número de personas afectadas
• La duración del tiempo de inactividad causado
• El costo para la empresa (si se puede calcular o calcular fácilmente
estimado).
Teniendo en cuenta todos estos factores, se obtiene una imagen mucho más detallada de
aquellos incidentes / problemas o tipos de incidentes / problemas que están causando la mayoría
el dolor puede ser determinado, para permitir un mejor enfoque en aquellas cosas que realmente
importan y merecen la máxima prioridad para resolver
• Kepner y Tregoe: Charles Kepner y Benjamin Tregoe desarrollaron un

forma útil de análisis de problemas que se puede utilizar formalmente para investigar
problemas de raíces más profundas. Definieron las siguientes etapas:
• definiendo el problema
• describir el problema en términos de identidad, ubicación, tiempo y tamaño
• estableciendo posibles causas
• probando la causa más probable
• Verificando la verdadera causa.
El método se describe con más detalle en el Apéndice C.
• Lluvia de ideas : a menudo puede ser valioso reunir los

personas, ya sea físicamente o por medios electrónicos, y para 'intercambiar ideas'
Página 117
problema: con personas que aportan ideas sobre cuál puede ser la causa potencial
be y posibles acciones para resolver el problema. Sesiones de lluvia de ideas
puede ser muy constructivo e innovador, pero es igualmente importante que
alguien, tal vez el administrador de problemas, documenta el resultado y
cualquier acción acordada y mantiene un grado de control en la (s) sesión (es).
• Diagramas de Ishikawa : Kaoru Ishikawa (1915-1989), líder en japonés
control de calidad , desarrolló un método para documentar causas y efectos
que puede ser útil para ayudar a identificar hacia dónde puede estar yendo algo
mal o mejorar. Un diagrama de este tipo suele ser el resultado de una
sesión de lluvia de ideas donde los solucionadores de problemas pueden ofrecer sugerencias. los
El objetivo principal está representado por el tronco del diagrama y los factores primarios.
se representan como ramas. A continuación, se añaden factores secundarios como tallos,
etcétera. La creación del diagrama estimula la discusión y, a menudo, conduce a
mayor comprensión de un problema complejo . Un diagrama de ejemplo es
que figura en el Apéndice D.
• Análisis de Pareto: esta es una técnica para separar importantes potenciales
causas de cuestiones más triviales. Deben seguirse los siguientes pasos:
1. Forme una tabla que enumere las causas y su frecuencia como porcentaje.
2. Organice las filas en orden decreciente de importancia de las causas, es decir
la causa más importante primero.
3. Agregue una columna de porcentaje acumulativo a la tabla. Con este paso, el gráfico
debería parecerse a la tabla 4.2, que ilustra 10 causas de
falla de la red en una organización .
Fallos de la red
Causas Porcentaje del cálculo total acumulado
Controlador de red 35 0 + 35% 35
Corrupción de archivos 26 35% + 26% 61
Abordar los conflictos 19 61% + 19% 80
SO del servidor 6 80% + 6% 86
Error de secuencia de comandos 5 86% + 5% 91
Cambio no probado 3 91% + 3% 94
Error del operador 2 94% + 2% 96
Error de copia de seguridad 2 96% + 2% 98
Intentos de intrusión 1 98% + 1% 99
Falla de disco 1 99% + 1% 100
Tabla 4.2 Gráfico de clasificación de causas de Pareto
Página 118
4. Cree un gráfico de barras con las causas, en orden de su porcentaje del total.
5. Superponga un gráfico de líneas de los porcentajes acumulados. El completado
El gráfico se ilustra en la Figura 4.5.
6. Dibuje una línea al 80% en el eje y paralela al eje x. Entonces suelta la línea en
el punto de intersección con la curva en el eje x. Este punto en la x-
El eje separa las causas importantes de las causas triviales. Esta linea es
representado como una línea de puntos en la Figura 4.5.
Figura 4.5 Causas importantes versus causas triviales
A partir de este gráfico, se ve claramente que hay tres causas principales por las que la red
fracaso en la organización . Por lo tanto, estos deben dirigirse primero.
Página 119
4.4.5.6 Soluciones provisionales
En algunos casos, puede ser posible encontrar una solución a los incidentes causados por
el problema - una forma temporal de superar las dificultades. Por ejemplo, un
Se puede hacer una enmienda manual a un archivo de entrada para permitir que un programa se complete
se ejecuta correctamente y permite que un proceso de facturación se complete satisfactoriamente, pero es
Es importante que continúe el trabajo sobre una resolución permanente cuando esté justificado:
En este ejemplo, la razón por la que el archivo se corrompe en primer lugar debe
ser encontrado y corregido para evitar que esto vuelva a suceder.
En los casos en que se encuentre una solución alternativa, es importante que el problema
El registro permanece abierto y los detalles de la solución siempre se documentan
dentro del Registro de problemas .
4.4.5.7 Generación de un registro de errores conocidos
Tan pronto como se complete el diagnóstico , y particularmente cuando se haya

se ha encontrado (aunque es posible que todavía no sea una resolución permanente), un Conocido
El registro de errores se debe generar y colocar en la base de datos de errores conocidos , de modo que si
surgen más incidentes o problemas, se pueden identificar y el servicio
restaurar d más rápidamente.
Sin embargo, en algunos casos puede resultar ventajoso generar un registro de errores conocidos
incluso antes en el proceso general, solo con fines informativos, por ejemplo,
aunque el diagnóstico no esté completo o no se haya encontrado una solución alternativa,
desaconsejable establecer un punto de procedimiento concreto exactamente cuando se produce un error conocido
Debe levantarse récord. ¡Debe hacerse tan pronto como sea útil hacerlo!
La base de datos de errores conocidos y la forma en que debe usarse se describen en más
detalle en el párrafo 4.4.7.2.
4.4.5.8 Resolución de problemas
Idealmente, tan pronto como se haya encontrado una solución, debería aplicarse para resolver el problema.
problema, pero en realidad pueden ser necesarias salvaguardas para garantizar que esto no
causar más dificultades. Si se requiere algún cambio en la funcionalidad, esto requerirá
una RFC que se planteará y aprobará antes de que se pueda aplicar la resolución. Si el
El problema es muy grave y se necesita una solución urgente por motivos comerciales, entonces
un RFC de emergencia debe ser manejado por el Aviso de cambio de emergencia
Junta (ECAB). De lo contrario, el RFC debe seguir el cambio establecido .
Proceso de gestión para ese tipo de cambio, y la resolución debe ser
se aplica solo cuando el cambio ha sido aprobado y programado para su publicación . En
Mientras tanto, el KEDB debe usarse para ayudar a resolver rápidamente cualquier
ocurrencias de los incidentes / problemas que ocurren.
Página 120
Nota: Puede haber algunos problemas para los que un Business Case para su resolución
no se puede justificar (por ejemplo, cuando el impacto es limitado pero el costo de resolución
sería extremadamente alto). En tales casos, se puede tomar la decisión de dejar el
Problema Registro abierto pero para usar una descripción de solución alternativa en el Error conocido
Grabe para detectar y resolver cualquier recurrencia rápidamente. Se debe tener cuidado de
utilice el código apropiado para marcar el registro de problemas abierto para que no
contar contra el desempeño del equipo que realiza el proceso y para que
no se realiza ningún retrabajo no autorizado.
4.4.5.9 Cierre del problema
Cuando se ha completado cualquier cambio (y se ha revisado con éxito ), y el

se ha aplicado una resolución , el Registro de problemas debe cerrarse formalmente , como
en caso de que existan registros de incidentes relacionados que aún estén abiertos. Un cheque debe ser
realizado en este momento para asegurar que el registro contiene un historial completo
descripción de todos los eventos , y si no es así, el registro debe actualizarse.
El estado de cualquier registro de error conocido relacionado debe actualizarse para mostrar que
se ha aplicado la resolución.
4.4.5.10 Revisión de problemas importantes
Después de cada gran problema (según lo determinado por la organización ‘s sistema de prioridad ),
Mientras los recuerdos aún están frescos, se debe realizar una revisión para aprender las lecciones.
para el futuro. Específicamente, la revisión debe examinar:
• Esas cosas que se hicieron correctamente

• Esas cosas que se hicieron mal
• ¿Qué se podría hacer mejor en el futuro?
• Cómo prevenir la recurrencia
• Si ha habido alguna responsabilidad de terceros y si se ha seguido
se necesitan acciones.
Estas revisiones se pueden utilizar como parte de las actividades de capacitación y concienciación para brindar apoyo.
personal - y cualquier lección aprendida debe documentarse en forma apropiada
procedimientos , instrucciones de trabajo , guiones de diagnóstico o registros de errores conocidos. los
El administrador de problemas facilita la sesión y documenta las acciones acordadas.
El conocimiento aprendido de la revisión debe incorporarse a un servicio.

Revisar la reunión con el cliente comercial para asegurarse de que el cliente esté al tanto de
las acciones tomadas y los planes para evitar que ocurran incidentes importantes en el futuro .
Esto ayuda a mejorar la satisfacción del cliente y asegura a la empresa que el Servicio
Operation s está manejando incidentes importantes de manera responsable y trabajando activamente para
prevenir su futura recurrencia.
4.4.5.11 Errores detectados en el entorno de desarrollo
Página 121
Es raro que una nueva aplicación , sistema o versión de software esté completamente
libre de errores . Es más probable que durante las pruebas de estas nuevas aplicaciones, los sistemas
o libera un sistema de priorización que se utilizará para erradicar los más graves
fallas , pero es posible que las fallas menores no se rectifiquen, a menudo debido a la
Equilibrio que debe lograrse entre la entrega de nuevas funcionalidades a la empresa.
lo más rápido posible y garantizando códigos o componentes totalmente libres de fallas .
Donde se toma la decisión de lanzar algo al entorno de producción

que incluye deficiencias conocidas, estas deben registrarse como Errores conocidos en el
KEDB, junto con detalles de soluciones o actividades de resolución. Debería
ser un paso formal en la aprobación de las pruebas que garantice que esta transferencia siempre
tiene lugar (consulte la publicación Transición del servicio ).
La experiencia ha demostrado que si esto no sucede, dará lugar a un apoyo mucho mayor.
cuesta cuando el usuario comienza a experimentar las fallas y a generar incidentes que han
para ser diagnosticado nuevamente y resuelto de nuevo.
La gran mayoría de los registros de problemas se activarán como reacción a uno o más
incidentes, y muchos se plantearán o iniciarán a través del personal de Service Desk. Otro
Los registros de problemas y los correspondientes registros de errores conocidos pueden activarse en
pruebas, en particular las últimas etapas de las pruebas, como la aceptación del usuario
Pruebas / Ensayos (UAT), si se toma la decisión de seguir adelante con una liberación incluso
aunque se conocen algunas fallas . Los proveedores pueden desencadenar la necesidad de algún problema
Registros mediante la notificación de posibles fallas o deficiencias conocidas en su
productos o servicios (por ejemplo, se puede dar una advertencia sobre el uso de un
CI particular y un registro de problemas se pueden generar para facilitar la investigación
por el personal técnico de la condición de tales elementos de configuración dentro de la organización que está TI
Infraestructura ).
La relación
discutido enprincipal
detalle enentre la gestión
los párrafos de incidentes
4.2.6 y problemas
y 4.4.5.1. Otras ha sido
interfaces clave incluyen
el seguimiento:
• Gestión de cambios : la gestión de problemas garantiza que todos
resoluciones o soluciones alternativas que requieren un cambio en un CI son
enviado a través de Gestión de cambios a través de un RFC. Cambio
La gerencia monitoreará el progreso de estos cambios y mantendrá
Se aconseja la gestión de problemas. La gestión de problemas también
involucrados en rectificar la situación causada por cambios fallidos.
• Gestión de la configuración : la gestión de problemas utiliza el CMS
para identificar los IC defectuosos y también para determinar el impacto de los problemas s
y resolución s. El CMS también se puede utilizar para formar la base de
el KEDB y mantener o integrar con los registros de problemas.
Página 122
• Gestión de versiones y despliegues : es responsable de la puesta en marcha

El problema se soluciona en el entorno en vivo . También ayuda a
asegurarse de que los errores conocidos asociados se transfieran desde el
desarrollo de la base de datos de errores conocidos en el error conocido en vivo
Base de datos. La gestión de problemas ayudará a resolver problemas
causado por fallas durante el proceso de liberación .
• Gestión de disponibilidad : participa en la determinación de cómo
reduzca el tiempo de inactividad y aumente el tiempo de actividad. Como tal, tiene un cierre
relación con la gestión de problemas, especialmente el proactivo
áreas. Gran parte de la información de gestión disponible en Problema
La administración se comunicará a la administración de disponibilidad.
• Gestión de la capacidad : algunos problemas requerirán una investigación por parte de
Equipos y técnicas de gestión de la capacidad, por ejemplo, rendimiento.
cuestiones. La gestión de la capacidad también ayudará a evaluar
medidas proactivas. La gestión de problemas proporciona gestión
información relativa a la calidad de las decisiones tomadas durante la
Proceso de planificación de capacidad .
• Continuidad del servicio de TI : la gestión de problemas actúa como un punto de entrada
en la Gestión de la Continuidad del Servicio de TI donde un problema significativo
no se resuelve antes de que comience a tener un impacto importante en el
negocio.
• servicio de Mejoramiento contínuo
• Gestión del nivel de servicio : la ocurrencia de incidentes y
Los problemas afectan el nivel de prestación de servicios medido por SLM.
La gestión de problemas contribuye a mejorar el servicio
nivel s, y su información de gestión se utiliza como base de
algunos de los componentes de revisión del SLA . SLM también proporciona
parámetros dentro de los cuales funciona la gestión de problemas, como
información de impacto y el efecto en los servicios de la propuesta
resoluciones y medidas proactivas.
• Gestión financiera : ayuda a evaluar el impacto de
propuestas de resolución o soluciones alternativas , así como el valor del dolor
Análisis . La gestión de problemas proporciona información de gestión
sobre el costo de resolver y prevenir problemas , que se utiliza
como entrada en los sistemas de presupuestación y contabilidad y el costo total
de cálculos de propiedad.
4.4.7.1 CMS
El CMS llevará a cabo los detalles de todos los componentes s de la infraestructura de TI , así
como la relación s entre estos componentes. Actuará como una fuente valiosa
para el diagnóstico de problemas y para evaluar el impacto de los problemas (por ejemplo, si este disco
Página 123
está inactivo, qué datos hay en ese disco; qué servicios utilizan esos datos; qué usuario usa
esos servicios?). Como también contendrá detalles de actividades anteriores, también puede ser
utilizado como una fuente valiosa de datos históricos para ayudar a identificar tendencias o potenciales
debilidades - una parte clave de una gestión proactiva de problemas (ver Continua
Publicación de mejora del servicio ).
4.4.7.2 Base de datos de errores conocidos
El propósito de una base de datos de errores conocidos es permitir el almacenamiento de

conocimiento de incidentes y problemas, y cómo se superaron, para permitir
diagnóstico y resolución más rápidos si se repiten.
El registro de errores conocidos debe contener detalles exactos de la falla y los síntomas
que ocurrió, junto con detalles precisos de cualquier solución alternativa o resolución
acción que se puede tomar para restaurar el servicio y / o resolver el problema. Un
El recuento de incidentes también será útil para determinar la frecuencia con la que los incidentes
es probable que se repitan e influyan en las prioridades, etc.
Cabe señalar que un Business Case para una resolución permanente para algunos
los problemas pueden no existir. Por ejemplo, si un problema no causa problemas graves
interrupción y existe una solución y / o el costo de resolver el problema en gran medida
supera los beneficios de una resolución permanente, entonces se puede tomar una decisión
tolerar la existencia del problema. Sin embargo, aún será deseable
diagnosticar e implementar una solución lo más rápido posible, que es donde
KEDB puede ser de ayuda.
Es esencial que cualquier dato que se ingrese en la base de datos se pueda

recuperado. El administrador de problemas debe estar completamente capacitado y familiarizado con el
métodos / algoritmos de búsqueda utilizados por la base de datos seleccionada y deben
Asegúrese de que cuando se agreguen nuevos registros , los criterios clave de búsqueda relevantes sean
correctamente incluido.
Se debe tener cuidado para evitar la duplicación de registros (es decir, el mismo problema
descritos de dos o más formas como registros separados). Para evitar esto, el Problema
El administrador debe ser la única persona que pueda ingresar un nuevo registro. Otro apoyo
Se debería permitir, de hecho, animar a los grupos a proponer nuevos registros, pero
estos deben ser examinados por el administrador de problemas antes de ingresar al KEDB. En
Grandes organizaciones donde el personal de Gestión de Problemas existe en múltiples ubicaciones.
pero se utiliza un solo KEDB (¡recomendado!), se debe acordar un procedimiento
entre todo el personal de Gestión de problemas para garantizar que dicha duplicación no pueda
ocurrir. Esto puede implicar la designación de un solo miembro del personal como el KEDB central.
Gerente.
El KEDB debe utilizarse durante las fases de diagnóstico de incidentes y problemas para
intente acelerar el proceso de resolución , y se deben agregar nuevos registros como
lo antes posible cuando se ha identificado y diagnosticado un nuevo problema.
Página 124
Todo el personal de apoyo debe estar completamente capacitado y familiarizado con el valor que
KEDB puede ofrecer y la forma en que debe usarse. Deberían poder fácilmente
recuperar y utilizar datos.
Nota: Algunas herramientas / implementaciones pueden optar por delinear los errores conocidos simplemente
cambiando un campo en el Registro de problemas original . Esto es aceptable siempre que
el mismo nivel de funcionalidad está disponible.
El KEDB, al igual que el CMS, forma parte de una gestión del conocimiento del servicio más amplia .
Sistema (SKMS) ilustrado en la Figura 4.6. Se puede obtener más información sobre SKMS
que se encuentra en la publicación Service Transition .
Figura 4.6 Sistema de gestión del conocimiento del servicio
4.4.8 Métricas
Las siguientes métricas deben usarse para juzgar la efectividad y eficiencia de

el proceso de Gestión de Problemas , o su funcionamiento :
• El número total de problemas registrados en el período (como control

la medida)
•
El porcentaje
porcentaje quedenoproblemas
lo son!) resueltos dentro de los objetivos de SLA (y el
• El número y el porcentaje de problemas que superaron su objetivo.
tiempos de resolución
• La acumulación de problemas pendientes y la tendencia (estática, reductora o
¿creciente?)
• El costo promedio de manejar un problema
Página 125
• El número de problemas importantes (abiertos y cerrados y atrasos)

• El porcentaje de revisiones de problemas importantes realizadas con éxito
• El número de errores conocidos agregados al KEDB
• El porcentaje de precisión del KEDB (de las auditorías de la base de datos)
• El porcentaje de revisiones de problemas importantes completadas correctamente y en
hora.
Todas las métricas deben desglosarse por categoría , impacto , gravedad, urgencia y
nivel de prioridad y en comparación con períodos anteriores.
Una dependencia importante para la gestión de problemas es el establecimiento de un

proceso y herramientas eficaces de gestión de incidentes. Esto asegurará que los problemas
se identifican lo antes posible y que se realiza la mayor cantidad de trabajo en
calificación como sea posible. Sin embargo, también es fundamental que los dos procesos tengan
interfaces formales y prácticas de trabajo comunes s. Esto implica lo siguiente:
• Vinculación de herramientas de gestión de incidentes y problemas

• La capacidad de relacionarse de incidentes y Registro de problema s
• El personal de segunda y tercera línea debe tener una buena relación de trabajo.
con personal en la primera línea
• Asegurarse de que todo el personal que trabaja comprenda bien el impacto empresarial
en la resolución de problemas .
Además, es importante que la gestión de problemas pueda utilizar todos los conocimientos
y recursos de gestión de la configuración disponibles.
Otro MCA es la formación continua del personal técnico en ambos aspectos técnicos de
su trabajo, así como las implicaciones comerciales de los servicios que apoyan y el
procesos que utilizan
Página 126
4.5 Gestión de acceso
La gestión de acceso es el proceso de otorgar a los usuarios autorizados el derecho a utilizar

un servicio , al tiempo que impide el acceso a usuarios no autorizados. También ha sido
denominada Gestión de derechos o Gestión de identidades en diferentes
Organizaciones.
La gestión de acceso proporciona a los usuarios el derecho a utilizar un servicio o

grupo de servicios. Por tanto, es la ejecución de políticas y acciones definidas en
Gestión de seguridad y disponibilidad .
4.5.2 Alcance
La gestión de acceso es efectivamente la ejecución de la disponibilidad y

Gestión de la seguridad de la información , ya que permite a la organización gestionar
la confidencialidad , disponibilidad e integridad de los datos de la organización y
propiedad intelectual.
La gestión de acceso garantiza que los usuarios tengan derecho a utilizar un servicio, pero
no garantiza que este acceso esté disponible en todos los horarios acordados; esto es
proporcionado por la gestión de disponibilidad.
La gestión de acceso es un proceso que es ejecutado por todos los técnicos y

La función de gestión de aplicaciones no suele ser una función separada.
Sin embargo, es probable que haya un único punto de control de coordinación, generalmente en TI.
Gestión de operaciones o en el Service Desk .
La gestión de acceso puede iniciarse mediante una solicitud de servicio a través del servicio
Escritorio.
La gestión de acceso proporciona el siguiente valor:
• El acceso controlado a los servicios asegura que la organización pueda

mantener más eficazmente la confidencialidad de su información
• Los empleados tienen el nivel adecuado de acceso para ejecutar sus trabajos de manera efectiva.
• Hay menos probabilidad de que se cometan errores en la entrada de datos o en el uso de
un servicio crítico por parte de un usuario no calificado (por ejemplo, sistemas de control de producción )
• La capacidad de auditar el uso de los servicios y rastrear el abuso de los servicios.
• La capacidad de revocar más fácilmente los derechos de acceso cuando sea necesario: una
consideración de seguridad importante
• Puede ser necesario para el cumplimiento normativo (por ejemplo, SOX, HIPAA, COBIT ).
Página 127
La gestión de acceso es el proceso que permite a los usuarios utilizar los servicios que
están documentados en el Catálogo de servicios . Comprende lo siguiente básico
conceptos:
• El acceso se refiere al nivel y alcance de la funcionalidad o los datos de un servicio.

que un usuario tiene derecho a utilizar.
• La identidad se refiere a la información sobre ellos que los distingue como
individuo y que verifica su estado dentro de la organización . Por
definición, la identidad de un usuario es única para ese usuario. (Esto está cubierto en
más detalles en el párrafo 4.5.7.1.)
• Los derechos (también llamados privilegios) se refieren a la configuración real mediante la cual un usuario
se proporciona acceso a un servicio o grupo de servicios. Derechos típicos, o
niveles de acceso, incluyen lectura, escritura, ejecución, cambio, eliminación.
• Servicios o grupos de servicios . La mayoría de los usuarios no utilizan un solo servicio y
los usuarios que realicen un conjunto similar de actividades utilizarán un conjunto similar de servicios.
En lugar de proporcionar acceso a cada servicio para cada usuario por separado, es
más eficiente para poder otorgar acceso a cada usuario o grupo de usuarios
a todo el conjunto de servicios que tienen derecho a utilizar al mismo tiempo.
(Esto se analiza con más detalle en el párrafo 4.5.7.2.)
• Los servicios de directorio se refieren a un tipo específico de herramienta que se utiliza para administrar
acceso y derechos. Estos se analizan en la sección 5.8.
4.5.5.1 Solicitar acceso
El acceso (o restricción) se puede solicitar usando uno de cualquier número de

mecanismos, que incluyen:
• Una solicitud estándar generada por el sistema de Recursos Humanos . Este es

generalmente se hace siempre que una persona es contratada, promovida, transferida o cuando
dejan la empresa
• Una solicitud de cambio
• Una solicitud de servicio enviada a través del sistema de cumplimiento de solicitudes
• Ejecutando un script u opción preautorizados (por ejemplo, descargando un
aplicación desde un servidor intermedio cuando sea necesario).
Las reglas para solicitar acceso normalmente se documentan como parte del Servicio.
Catálogo.
4.5.5.2 Verificación
La gestión de acceso necesita verificar cada solicitud de acceso a un servicio de TI

desde dos perspectivas:
Página 128
• Que el usuario que solicita el acceso es quien dice ser

• Que tienen un requisito legítimo para ese servicio.
La primera categoría generalmente la logra el usuario que proporciona su nombre de usuario y

contraseña. Dependiendo de las políticas de seguridad de la organización , el uso de la
El nombre de usuario y la contraseña generalmente se aceptan como prueba de que la persona es un
usuario legítimo . Sin embargo, para servicios más sensibles, puede ser necesario realizar una identificación adicional.
requerido (biométrico, uso de una clave de acceso electrónico o dispositivo de encriptación, etc.).
La segunda categoría requerirá alguna verificación independiente , además de la

solicitud del usuario. Por ejemplo:
• Notificación de Recursos Humanos de que la persona es un empleado nuevo

y requiere tanto un nombre de usuario como acceso a un conjunto estándar de servicios
• Notificación de Recursos Humanos de que el usuario ha sido promovido y
requiere el acceso a otros recursos s
• Autorización de un gerente apropiado (definido en el proceso )
• Presentación de una solicitud de servicio (con evidencia de respaldo) a través del
Servicio de mesa
• Envío de un RFC (con evidencia de apoyo) a través de Change
Gestión o ejecución de un cambio estándar predefinido
• Una política que establece que el usuario puede tener acceso a un servicio opcional si
lo necesitan.
Para nuevos servicios, el registro de cambios debe especificar qué usuarios o grupos de
los usuarios tendrán acceso al Servicio. La administración de acceso luego verificará
ver que todos los usuarios sigan siendo válidos y proporcionen acceso automáticamente según lo especificado
en el RFC.
4.5.5.3 Proporcionar derechos
Access Management no decide quién tiene acceso a qué servicios de TI .

Más bien, Access Management ejecuta las políticas y regulaciones definidas
durante la Estrategia de Servicio y el Diseño de Servicio . La gestión de acceso refuerza
decisiones para restringir o proporcionar acceso, en lugar de tomar la decisión.
Tan pronto como se haya verificado un usuario, Access Management proporcionará a ese usuario
con derechos de uso del servicio solicitado . En la mayoría de los casos, esto dará lugar a una solicitud.
a cada equipo o departamento involucrado en apoyar ese servicio para tomar la
acción necesaria. Si es posible, estas tareas deben automatizarse.
Cuantos más roles y grupos existan, es más probable que surja un conflicto de roles.
El conflicto de roles en este contexto se refiere a una situación en la que dos roles específicos o
grupos, si se asignan a un solo usuario, crearán problemas con la separación de tareas o
conflicto de intereses. Ejemplos de esto incluyen:
Página 129
• Un rol requiere acceso detallado, mientras que otro rol evita ese acceso
• Dos roles permiten a un usuario realizar dos tareas que no deben combinarse
(por ejemplo, un contratista puede registrar su hoja de tiempo para un proyecto y luego aprobar
todo pago por obra para el mismo proyecto).
El conflicto de roles se puede evitar mediante la creación cuidadosa de roles y grupos, pero más
a menudo son causados por políticas y decisiones tomadas fuera del Servicio
Operación , ya sea por la empresa o por diferentes equipos de proyecto que trabajan durante
Diseño de servicio. En cada caso, el conflicto debe documentarse y escalarse a
las partes interesadas deben resolver.
Siempre que se definan roles y grupos, es posible que se puedan definir

demasiado amplia o demasiado estrecha. Siempre habrá usuarios que necesiten algo
ligeramente diferente de los roles predefinidos. En estos casos, es posible utilizar
roles estándar y luego agregar o restar derechos específicos según sea necesario, similar al
concepto de líneas base y variantes en la gestión de la configuración (consulte Servicio
Publicación de transición ). Sin embargo, la decisión de hacer esto no está en manos de
miembros individuales del personal operativo . Cada excepción debe ser coordinada por
Gestión de acceso y homologado a través del proceso de origen.
La gestión de acceso debe realizar una revisión periódica de los roles y grupos.
que ha creado y gestiona para asegurar que sean adecuados para el
servicios que TI ofrece y respalda, y roles / grupos obsoletos o no deseados
debería ser removido.
4.5.5.4 Supervisión del estado de la identidad
A medida que los usuarios trabajan en la organización , sus roles cambian y también sus necesidades.
para acceder a los servicios. Ejemplos de cambios incluyen:
• Cambios de trabajo. En este caso, el usuario posiblemente necesite acceder a diferentes

o servicios adicionales.
• Promociones o degradaciones. El usuario probablemente utilizará el mismo conjunto de
servicios, pero necesitará acceso a diferentes niveles de funcionalidad o datos.
• Traslados. En esta situación, el usuario puede necesitar acceder exactamente a la misma
conjunto de servicios, pero en una región diferente con diferentes de trabajo de práctica s
y diferentes conjuntos de datos.
• Renuncia o muerte. El acceso debe eliminarse por completo para
evitar que el nombre de usuario se utilice como una laguna de seguridad .
• Jubilación. En muchas organizaciones, un empleado que se jubila aún puede
tener acceso a un conjunto limitado de servicios, incluidos los sistemas de beneficios o
sistemas que les permitan adquirir productos de la empresa a precio reducido.
• Acción disciplinaria. En algunos casos, la organización requerirá un
restricción temporal para evitar que el usuario acceda a algunos o todos los
servicios a los que normalmente tendrían acceso. Debería haber un
Página 130
función en el proceso y las herramientas para hacer esto, en lugar de tener que eliminar y
restablecer los derechos de acceso del usuario .
• Despidos. Donde se despide a un empleado o contratista, o donde
se emprenden acciones legales contra un cliente (por ejemplo, por incumplimiento de
pago por productos comprados en Internet), el acceso debe ser
revocado inmediatamente. Además, Gestión de acceso, trabajando juntos
con la Gestión de la Seguridad de la Información, debería tomar medidas activas para
prevenir y detectar acciones maliciosas contra la organización desde ese
usuario.
La gestión de acceso debe comprender y documentar el ciclo de vida típico del usuario.
para cada tipo de usuario y utilícelo para automatizar el proceso. Gestión de Acceso
Las herramientas deben proporcionar características que permitan mover a un usuario de un estado a otro.
otro, o de un grupo a otro, fácilmente y con una pista de auditoría .
4.5.5.5 Acceso a registro y seguimiento
La gestión de acceso no solo debe responder a las solicitudes. También es responsable

para asegurar que los derechos que han otorgado se estén utilizando adecuadamente.
En este sentido, el Monitoreo y Control de Acceso debe ser incluido en el monitoreo

actividades de todas las funciones de gestión técnica y de aplicaciones y todos los servicios
Procesos de operación .
Las excepciones deben ser manejadas por Incident Management , posiblemente usando Incident
Modelos diseñados específicamente para hacer frente al abuso de los derechos de acceso. Debería ser
señaló que la visibilidad de tales acciones debería restringirse. Haciendo esto
información disponible para todos los que tienen acceso al sistema de gestión de incidentes
expondrá vulnerabilidades.
La gestión de la seguridad de la información juega un papel vital en la detección de

acceder y compararlo con los derechos que le otorgó Access
Gestión . Esto requerirá la participación de la Gestión de acceso en la definición de
parámetros para su uso en herramientas de detección de intrusiones.
También es posible que se requiera que la Administración de acceso proporcione un registro de acceso para
Servicios específicos durante las investigaciones forenses. Si se sospecha que un usuario
infracciones de la política , uso inadecuado de los recursos o uso fraudulento de datos,
Es posible que se requiera que Access Management proporcione evidencia de fechas, horas y
incluso el contenido del acceso de ese usuario a Servicios específicos. Esto normalmente se proporciona
por el personal operativo de ese servicio , pero trabajando como parte del Acceso
Proceso de gestión .
4.5.5.6 Eliminación o restricción de derechos
Página 131
Así como la Gestión de acceso proporciona derechos para utilizar un Servicio, también
responsable de revocar esos derechos. Una vez más, esta no es una decisión que toma
por sí mismo. Más bien, ejecutará las decisiones y políticas tomadas durante el Servicio.
Estrategia y Diseño y también decisiones tomadas por los gerentes de la organización .
La eliminación del acceso generalmente se realiza en las siguientes circunstancias:
• Muerte
• Resignación
• Despido
• Cuando el usuario ha cambiado de roles y ya no requiere acceso al
Servicio
• Transfiera o viaje a un área donde se aplica un acceso regional diferente.
En otros casos, no es necesario eliminar el acceso, solo para proporcionar más

restricciones. Estos podrían incluir la reducción del nivel, el tiempo o la duración del acceso.
Las situaciones en las que se debe restringir el acceso incluyen:
• Cuando el usuario ha cambiado de roles o ha sido degradado y ya no

requiere el mismo nivel de acceso
• Cuando el usuario está siendo investigado, pero aún requiere acceso a los
servicios, como correo electrónico. En este caso, su correo electrónico puede estar sujeto a
exploración adicional (pero esto debería manejarse con mucho cuidado y
en total conformidad con la política de seguridad de la organización )
• Cuando un usuario está fuera de la organización en una asignación temporal y
no requerirá acceso a ese servicio durante algún tiempo.
La gestión de acceso se desencadena por una solicitud de que un usuario o usuarios accedan a un
servicio o grupo de servicios. Esto podría originarse en cualquiera de los siguientes:
• Un RFC. Esto se usa con más frecuencia para presentaciones de servicios a gran escala.
o actualizaciones donde los derechos de un número significativo de usuarios deben ser
actualizado como parte del proyecto .
• Una solicitud de servicio . Esto generalmente se inicia a través del Service Desk , o
directamente en el sistema de cumplimiento de solicitudes y ejecutado por el
Equipos técnicos o de gestión de aplicaciones .
• Una solicitud de la Dirección de Recursos Humanos correspondiente .
personal (que debe canalizarse a través del Service Desk ). Este es
generalmente generado como parte del proceso de contratación, promoción, reubicación
y terminación o jubilación.
• Una solicitud del gerente de un departamento , que podría estar realizando
un rol de recursos humanos , o quién podría haber tomado la decisión de comenzar a usar un servicio para
la primera vez.
Página 132
La Gestión de Acceso debe estar vinculada a los procesos de Recursos Humanos para
verificar la identidad del usuario y asegurarse de que tiene derecho a los servicios
siendo solicitado.
Gestión de la seguridad es una clave de controlador de administración de accesos, ya que

proporcionará las políticas y herramientas de seguridad y protección de datos necesarias para ejecutar
Gestión de Acceso.
La gestión del cambio juega un papel importante como medio para controlar el
solicitudes de acceso. Esto se debe a que cualquier solicitud de acceso a un servicio es una
cambio , aunque generalmente se procesa como un cambio o servicio estándar
Solicitar (posiblemente utilizando un modelo ) una vez que se hayan acordado los criterios de acceso
a través de SLM.
SLM mantiene los contratos de acceso a cada servicio . Esto incluirá el

Criterios sobre quién tiene derecho a acceder a cada servicio, cuál es el costo de ese acceso
será, si procede, y qué nivel de acceso se concederá a los diferentes tipos de
usuario (por ejemplo, gerentes o personal).
También existe una fuerte relación entre la Gestión de acceso y

Gestión de la configuración . El CMS se puede utilizar para el almacenamiento de datos y
interrogado para determinar los detalles de acceso actuales.
4.5.7.1 Identidad
La identidad de un usuario es la información sobre él que lo distingue como

individuo y que verifica su estado dentro de la organización . Por definicin, el
la identidad de un usuario es única para ese usuario. Dado que hay casos en los que dos usuarios
comparten una información común (por ejemplo, tienen el mismo nombre), la identidad es
generalmente se establece utilizando más de un dato, por ejemplo:
• Nombre
• Dirección
• Datos de contacto, por ejemplo, teléfono, dirección de correo electrónico, etc.
• Documentación física, por ejemplo, licencia de conducir, pasaporte, matrimonio.
certificado, etc.
• Números que se refieren a un documento o una entrada en una base de datos, p. Ej.
número de empleado, número de identificación fiscal, número de identidad gubernamental,
número de licencia, etc.
• Información biométrica, por ejemplo, huellas dactilares, imágenes de la retina, reconocimiento de voz
patrones, ADN, etc.
• Fecha de vencimiento (si es relevante).
Página 133
Se proporciona una identidad de usuario a cualquier persona con un requisito legítimo para acceder a TI.
servicios o información organizacional. Estos podrían incluir:
• Empleados
• Contratistas
• El personal del proveedor (por ejemplo , gerentes de cuentas , personal de apoyo, etc.)
• Clientes (especialmente cuando compran productos o servicios en el
Internet).
La mayoría de las organizaciones verifican la identidad de un usuario antes de unirse a la organización al

solicitando un subconjunto de la información anterior. Cuanto más segura sea la organización,
Cuantos más tipos de información se requieran y más a fondo sean
comprobado.
Muchas organizaciones se enfrentarán a la necesidad de otorgar derechos de acceso a

personal o contratistas / proveedores temporales u ocasionales . La administración de
El acceso a dicho personal a menudo resulta problemático: cerrar el acceso después de su uso es
a menudo tan difícil de gestionar, o más, que proporcionar acceso inicialmente. Bien-
Deben establecerse procedimientos definidos entre TI y RR.HH. que incluyan fallos
controles seguros que garantizan que los derechos de acceso se eliminen de inmediato, no son
ya está justificado o requerido.
Cuando a un usuario se le concede acceso a una aplicación , ya debería haber sido

establecido por la organización (generalmente el departamento de Recursos Humanos o Seguridad
Departamento) que el usuario es quien dice ser.
En este punto, toda esa información se archiva y el archivo se asocia con una empresa.
identidad, generalmente un número de empleado o contratista y una identidad que puede ser
utilizado para acceder a los recursos e información corporativos , generalmente la identidad de un usuario o
'nombre de usuario' y una contraseña asociada.
4.5.7.2 Usuarios, grupos, roles y grupos de servicios
Si bien cada usuario tiene una identidad individual y cada servicio de TI puede verse como
una entidad por derecho propio, a menudo es útil agruparlos para que puedan
manejarse más fácilmente. A veces, los términos " perfil de usuario " o "plantilla de usuario" o
' rol de usuario ' se utilizan para describir este tipo de agrupación.
La mayoría de las organizaciones tienen un conjunto estándar de servicios para todos los usuarios individuales,
independientemente de su puesto o trabajo (excluidos los clientes , que no tienen ningún
visibilidad de los servicios y procesos internos). Estos incluirán servicios como
mensajería, ofimática, soporte de escritorio, telefonía, etc. Los nuevos usuarios son
se le otorgan automáticamente los derechos para utilizar estos servicios.
Sin embargo, la mayoría de los usuarios también tienen algún rol especializado que realizan. Para
Por ejemplo, además de los servicios estándar, el usuario también realiza un Marketing
Página 134
Rol de gestión, que requiere que tengan acceso a algunos
herramientas y datos de marketing y modelos financieros .
Algunos grupos pueden tener requisitos únicos , como trabajadores de campo o desde casa
quién puede tener que marcar o usar conexiones de red privada virtual (VPN), con
implicaciones de seguridad que pueden tener que gestionarse de forma más estricta.
Para facilitar que Access Management proporcione los derechos adecuados,

utiliza un catálogo de todos los roles en la organización y qué servicios apoyan
cada rol. Access debe compilar y mantener este catálogo de roles.
Gestión junto con RR.HH. y, a menudo, se automatizará en el directorio.
Servicio herramientas s (ver sección 5.8).
Además de desempeñar diferentes roles, los usuarios también pueden pertenecer a diferentes grupos.
Por ejemplo, todos los contratistas deben registrar sus hojas de horas en un
Sistema de tarjeta de tiempo , que no es utilizado por los empleados. La gestión de acceso
Evaluar todos los roles que desempeña un usuario, así como los grupos a los que pertenece.
y asegurarse de que brinden derechos para utilizar todos los servicios asociados.
Nota: Todos los datos de los usuarios estarán sujetos a la legislación de protección de datos (este
existe en la mayoría de las ubicaciones geográficas de una forma u otra) por lo que debe manejarse
y protegido como parte de los procedimientos de seguridad de la organización.
4.5.8 Métricas
Métricas que se pueden utilizar para medir la eficiencia y eficacia de Access

La gestión incluye:
• Número de solicitudes de acceso ( solicitud de servicio , RFC, etc.)

• Casos de acceso concedidos, por servicio , usuario , departamento, etc.
• Instancias de acceso otorgadas por departamento o individuo que otorga derechos
• Número de incidentes que requieren un restablecimiento de los derechos de acceso
• Número de incidencias provocadas por una configuración de acceso incorrecta.
Las condiciones para una gestión de acceso exitosa incluyen:
• La capacidad de verificar la identidad de un usuario (que la persona es quien dice

son)
• La capacidad de verificar la identidad de la persona u organismo que aprueba
• La capacidad de verificar que un usuario califica para acceder a un servicio específico.
• La capacidad de vincular múltiples derechos de acceso a un usuario individual.
• La capacidad de determinar el estado del usuario en cualquier momento (por ejemplo, para
determinar si todavía son empleados de la organización cuando
iniciar sesión en un sistema )
Página 135
• La capacidad de administrar cambios en los requisitos de acceso de un usuario .

• La capacidad de restringir los derechos de acceso a usuarios no autorizados.
•
Una base de datos de todos los usuarios y los derechos que se les han otorgado.
Página 136
4.6 Actividades operativas de los procesos cubiertos en otros

fases del ciclo de vida
4.6.1 Gestión de cambios
La Gestión de cambios se trata principalmente en la publicación Transición del servicio ,

pero hay algunos aspectos de la gestión de cambios que la operación del servicio
el personal participará en el día a día. Éstos incluyen:
• Elevar y enviar RFC según sea necesario para abordar la Operación del servicio
cuestiones
• Participar en reuniones de CAB o CAB / EC para garantizar que el servicio
Se tienen en cuenta los riesgos operativos , los problemas y las opiniones.
• Implementar cambios según las indicaciones de Gestión de cambios donde
involucrar componentes o servicios de Operación de Servicio
• Retirar los cambios según las indicaciones de la Gestión de cambios cuando
involucrar componentes o servicios de Operación de Servicio
• Ayudar a definir y mantener los modelos de cambio relacionados con la operación del servicio.
componentes o servicios
• Recibir cambios en los horarios y asegurarse de que todo el personal de operaciones de servicio
están al tanto y preparados para todos los cambios relevantes
• Uso del proceso de gestión de cambios para el tipo operativo estándar
cambios.
4.6.2 Gestión de la configuración
La gestión de la configuración se trata principalmente en la transición del servicio.

publicación, pero hay algunos aspectos de la Gestión de la configuración que
El personal de operaciones de servicio participará en el día a día. Estos
incluir:
• Informar a Configuration Management de cualquier discrepancia encontrada entre

cualquier CI y el CMS
• Realizar las modificaciones necesarias para corregir las discrepancias, según
la autoridad de la Gestión de la Configuración , donde involucran a cualquier
Servicios o componentes de operación de servicio.
La responsabilidad de actualizar el CMS sigue siendo la Gestión de la configuración,

pero en algunos casos se le puede pedir al personal de operaciones, bajo la dirección de
Gestión de la configuración, para actualizar las relaciones , o incluso para agregar nuevos CI o
marcar los CI como 'eliminados' en el CMS, si estas actualizaciones están relacionadas con operaciones
actividades realmente realizadas por el personal de operaciones.
Página 137
4.6.3 Gestión de versiones y despliegues
La gestión de versiones y despliegues se cubre principalmente en el servicio

Publicación de transición, pero hay algunos aspectos de este proceso que Service
El personal de operaciones estará involucrado en el día a día. Estos pueden incluir:
• Acciones de implementación reales con respecto al despliegue de nuevas versiones ,
bajo
se la dirección
relacionan condelosRelease and Deployment
componentes o serviciosManagement, donde
de la operación ellos
del servicio
• Participación en las etapas de planificación de importantes lanzamientos nuevos para asesorar sobre
Problemas de operación del servicio
• El manejo físico de los IC desde / hacia el DML según sea necesario para cumplir con su
roles operativos - mientras se adhiere al lanzamiento y la implementación relevantes
Procedimientos de gestión , como asegurarse de que todos los elementos estén correctamente
reservado de ida y vuelta.
4.6.4 Gestión de capacidad
La gestión de la capacidad debe operar en tres niveles: Capacidad empresarial

Gestión , gestión de la capacidad del servicio y capacidad de los recursos
Administración.
• La gestión de la capacidad empresarial implica trabajar con la empresa para

planificar y anticipar tanto los problemas estratégicos a más largo plazo como a corto plazo
iniciativas tácticas que probablemente tengan un impacto en la capacidad de TI .
• La gestión de la capacidad del servicio se trata de comprender
características de cada uno de los servicios de TI , y luego las demandas que
diferentes tipos de usuarios o transacciones tienen en el subyacente
infraestructura, y cómo estos varían con el tiempo y podrían verse afectados por
cambio de negocio .
• La gestión de la capacidad de recursos implica comprender
características y capacidades de rendimiento y niveles de utilización actuales
de todos los componentes técnicos (CI) que componen la Infraestructura de TI ,
y predecir el impacto de cualquier cambio o tendencia.
Muchas de estas actividades son de naturaleza estratégica o de planificación a más largo plazo y son
cubierto en la Estrategia de servicio , Diseño de servicio y Transición de servicio
Publicaciones. Sin embargo, hay una serie de funciones operativas de gestión de la capacidad.
Actividades que deben realizarse de forma regular y continua como parte del Servicio.
Operación . Estos incluyen los siguientes.
4.6.4.1 Supervisión de la capacidad y el rendimiento
Todos los componentes de la infraestructura de TI deben ser monitoreados continuamente (en

en conjunto con Event Management ) para que cualquier problema potencial o tendencia
puede identificarse antes de que se produzcan fallos o degradación del rendimiento . Idealmente, tal
Página 138
el monitoreo debe ser automatizado y los umbrales deben establecerse para que la excepción
Las alertas se emiten a tiempo para permitir una acción adecuada de evitación o recuperación para
tomarse antes de que ocurra un impacto adverso.
Los componentes y elementos a monitorear variarán dependiendo de la

infraestructura en uso, pero normalmente incluirá:
• Utilización de la CPU (general y desglosada por uso del sistema / servicio )

• Utilización de la memoria
• Tasas de E / S (físicas y de búfer) y utilización de dispositivos
•
•
Longitud de la cola (máxima y media)
Utilización del almacén de archivos (discos, particiones, segmentos)
• Aplicaciones ( tasas de rendimiento , tasas de fallas)
• Bases de datos (utilización, bloqueos de registros , indexación, contención)
• Tasas de transacciones de red , tasas de error y reintento
• Tiempo de respuesta de la transacción
• Perfiles de duración de lote
• Tasas de visitas a sitios de Internet / intranet / páginas
• Tiempos de respuesta de Internet (externos e internos a los firewalls)
• Número de inicios de sesión del sistema / aplicación y usuarios simultáneos
• Número de nodos de red en uso y niveles de utilización.
Hay diferentes tipos de herramientas de monitoreo necesarias para recopilar e interpretar datos.
en cada nivel. Por ejemplo, algunas herramientas permitirán realizar negocios
transacciones a monitorear, mientras que otros monitorearán el comportamiento de CI.
La gestión de la capacidad debe configurar y calibrar los umbrales de alarma (donde

necesario junto con la gestión de eventos , ya que a menudo es la supervisión de eventos
herramientas que puedan utilizarse) para que se establezcan los niveles de alerta correctos y
el filtrado se establece como necesario para que solo se generen eventos significativos .
Sin dicho filtrado, es posible que las alertas de 'solo información' puedan ocultar más
alertas importantes que requieren atención inmediata. Además, es posible
fallas graves para causar 'tormentas de alerta' debido a volúmenes muy altos de alertas repetidas,
que de nuevo deben ser filtrados para que los mensajes más significativos no sean
oscurecido.
Puede ser apropiado utilizar capacidades de monitoreo externas de terceros para algunos
CI o componentes de la infraestructura de TI (por ejemplo, sitios / páginas clave de Internet).
La gestión de la capacidad debe participar para ayudar a especificar y seleccionar tales
capacidades de seguimiento y en la integración de los resultados o cualquier alerta con otros
monitoreo y manejo del sistema s.
La gestión de la capacidad debe trabajar con todos los grupos de apoyo apropiados para hacer
decisiones sobre dónde se enrutan las alarmas y sobre rutas de escalada y escalas de tiempo.
Las alertas deben registrarse en la mesa de servicio , así como en el soporte adecuado.
personal, para que los registros de incidentes apropiados se puedan generar de manera que un registro permanente
Página 139
existe el caso de - y personal del Centro de Servicio tiene una visión de lo bien que la ayuda
grupo (s) están lidiando con la falla y pueden intervenir si es necesario.
Capacidades de rendimiento declaradas por los fabricantes y nivel de servicio acordado

objetivo s, junto con el rendimiento histórico real monitoreado y los datos de capacidad,
debe utilizarse para establecer niveles de alerta. Puede que sea necesario que sea un proceso iterativo
Inicialmente, realizar algunos ajustes de prueba y error hasta que se alcancen los niveles correctos.
logrado.
Nota: Es posible que la gestión de la capacidad deba involucrarse en la capacidad

requisitos y capacidades de la gestión de servicios de TI . Si el
la organización tiene suficiente personal de Service Desk para manejar la tasa de incidentes;
si la estructura de CAB puede manejar la cantidad de cambios que se le solicita
revisar y aprobar; si las herramientas de soporte pueden manejar el volumen de datos
reunidos son cuestiones de gestión de la capacidad, que la gestión de la capacidad
Se le puede pedir al equipo que ayude a investigar y a responder.
4.6.4.2 Manejo de incidentes relacionados con la capacidad o el desempeño
Si se activa una alerta o se genera un incidente en el Service Desk, causado por un

Problema actual o en curso de Gestión de la capacidad o el rendimiento , Capacidad
La gerencia debe involucrarse para identificar la causa y encontrar una solución .
Trabajando junto con los grupos de soporte técnico apropiados , y junto con
Gestión de problemas , se deben realizar todas las investigaciones necesarias para detectar
exactamente qué salió mal y qué se necesita para corregir la situación.
Puede que sea necesario cambiar a un seguimiento más detallado durante la

fase de investigación para determinar la causa exacta. El monitoreo a menudo se establece en un
nivel de 'fondo' durante circunstancias normales debido a la gran cantidad de datos
que se pueden generar y para evitar colocar una carga demasiado alta en la TI
Infraestructura, pero cuando se investigan dificultades específicas más detalladamente
Es posible que sea necesario realizar un seguimiento para identificar la causa exacta.
Cuando se ha encontrado una solución, o una solución potencial, cualquier cambio necesario
para resolver el problema debe ser aprobado a través de la Gestión de Cambios formal antes
a la implementación. Si la falla está causando una interrupción grave y una emergencia
se necesita una resolución, se debe utilizar el proceso de cambio urgente . Es muy
importante que no se lleve a cabo ningún ' ajuste ' sin sumisión a través de Change
Gestión, ya que incluso los ajustes aparentemente pequeños a menudo pueden tener grandes
efectos acumulativos, a veces en toda la infraestructura de TI.
4.6.4.3 Tendencias de capacidad y desempeño
La gestión de la capacidad tiene un papel que desempeñar en la identificación de cualquier capacidad o

tendencias de rendimiento a medida que se vuelven perceptibles. Más detalles de acciones
Página 140
necesarios para abordar tales tendencias se incluyen en el Servicio Continuo

Publicación de mejoras .
4.6.4.4 Almacenamiento de datos de gestión de capacidad
Por lo general, se generan grandes cantidades de datos a través de la capacidad y el rendimiento.

seguimiento . El monitoreo de medidores y tablas de solo unos pocos Kbytes cada uno puede
crecido en archivos enormes si muchos componentes se monitorean a un tiempo relativamente corto
intervalos. Otro problema con el seguimiento a muy corto plazo es que no es
posible recopilar información significativa sin mirar durante un período más largo.
Por ejemplo, una sola instantánea de una CPU mostrará que el dispositivo está 'ocupado'
o 'inactivo', pero un resumen de, digamos, un período de 5 minutos mostrará el promedio
nivel de utilización durante ese período, que es una medida mucho más significativa de
si el dispositivo puede funcionar cómodamente o si el rendimiento potencial
problemáticas s probable que se produzcan.
En cualquier organización , es probable que las herramientas de seguimiento utilizadas varíen mucho:
con una combinación de herramientas específicas del sistema , muchas de las cuales forman parte del
sistema operativo y herramientas de supervisión especializadas que se utilizan. Con el fin de
coordinar los datos que se generan y permitir la retención de datos significativos
para fines de análisis y tendencias, alguna forma de repositorio central para mantener
Se necesitan estos datos resumidos: un sistema de información de gestión de la capacidad
(CMIS).
Se debe planificar y planificar el formato, la ubicación y el diseño de dicha base de datos.

implementado de antemano - consulte la publicación Service Design para obtener más detalles -
pero habrá algunos aspectos operativos que manejar, como la base de datos
limpieza y respaldo s.
4.6.4.5 Gestión de la demanda
Gestión de la demanda es el nombre que se le da a una serie de técnicas que pueden

se utiliza para modificar la demanda de un recurso o servicio en particular . Algunas técnicas para
La gestión de la demanda se puede planificar con antelación, y se tratan en
más detalles en la publicación Service Design. Sin embargo, hay otros aspectos
de Gestión de la Demanda que son de naturaleza más operativa, requiriendo
acción a término.
Si, por ejemplo, el desempeño de un servicio en particular es motivo de preocupación, y

Se necesitan restricciones a corto plazo sobre la concurrencia de usuarios para permitir el rendimiento.
Mejoras para un grupo restringido más pequeña, luego de Operación del Servicio de función s
tendrá que tomar medidas para implementar tales restricciones, generalmente acompañadas de
acción concurrente para implementar el cierre de sesión de los usuarios que han estado inactivos
durante un período de tiempo acordado para liberar recursos para otros.
4.6.4.6 Gestión de la carga de trabajo
Página 141
Puede haber ocasiones en las que sea necesaria la optimización de los recursos de infraestructura.
para mantener o mejorar el rendimiento o el rendimiento . Esto a menudo se puede hacer
a través de Workload Management, que es un término genérico para cubrir tales acciones
como:
• Reprogramar un servicio o carga de trabajo en particular para que se ejecute en un momento diferente de
día o día de la semana, etc. (generalmente fuera de las horas pico a las horas pico
ventanas), lo que a menudo significará tener que hacer ajustes en el trabajo-
software de programación.
• Traslado de un servicio o carga de trabajo de una ubicación o conjunto de CI a otro:
a menudo para equilibrar la utilización o el tráfico.
• Virtualización técnica: configuración y uso de sistemas de virtualización para
Permitir el movimiento del procesamiento alrededor de la infraestructura para brindar una mejor
rendimiento / resiliencia de forma dinámica.
• Limitar o mover la demanda de recursos a través de la gestión de la demanda.
técnicas (ver arriba y también la publicación Service Design).
Solo será posible administrar las cargas de trabajo de manera efectiva si se comprende bien
existe de qué cargas de trabajo se ejecutarán en qué momento y cuánto uso de recursos
cada carga de trabajo se coloca en la infraestructura de TI. Seguimiento y análisis diligentes
de las cargas de trabajo, por lo tanto, es necesario de forma continua y operativa.
4.6.4.7 Modelado y dimensionamiento de aplicaciones
El modelado y / o dimensionamiento de nuevos servicios y / o aplicaciones deben, cuando

apropiado, debe hacerse durante las fases de planificación y transición - consulte el Servicio
Publicaciones de Transición de Diseño y Servicio . Sin embargo, la operación de servicio
Las funciones tienen un papel que desempeñar en la evaluación de la precisión de las predicciones y
retroalimentando cualquier problema o discrepancia.
4.6.4.8 Planificación de la capacidad
Durante el Diseño del Servicio y la Transición del Servicio, los requisitos de capacidad de TI
servicio s se calculan. Se debe mantener un plan de capacidad con visión de futuro
y actualizado periódicamente, y la Operación del Servicio tendrá un papel que desempeñar en esto. Semejante
un plan de debe mirar hacia adelante hasta dos años o más, pero debe ser opinión ed
regularmente cada tres a 12 meses, dependiendo de la volatilidad y los recursos
disponible.
El plan debe estar vinculada a la organización ‘s ciclo de planificación financiera, de manera que
cualquier gasto necesario para actualizaciones, mejoras o adiciones a la infraestructura
pueden incluirse en las estimaciones presupuestarias y aprobarse por adelantado.
El plan debe predecir el futuro, pero también debe examinar e informar sobre
predicciones anteriores, en particular para dar cierta confianza en futuras predicciones.
Página 142
Cuando se hayan encontrado discrepancias, estas deben explicarse

y la acción correctiva futura descrita.
El plan de capacidad normalmente puede cubrir:
• Detalles actuales de rendimiento y utilización, con tendencias recientes para todos los
CI, incluidos
• Redes troncales
• LAN
• Mainframes (si aún se usan)
• Servidor de claves s
• Principales dispositivos de almacenamiento de datos
• Equipos de escritorio y portátiles seleccionados (representativos)
• Sitios web clave
• Bases de datos clave
• Clave de aplicación s
• Capacidad operativa : electricidad, espacio en el suelo, medio ambiente
capacidad (aire acondicionado), peso del suelo, generación y salida de calor,
oferta y demanda de electricidad y agua, etc.
• Medios magnéticos.
• Rendimiento y utilización estimados para todos estos elementos de configuración durante la planificación
período (por ejemplo, los próximos tres meses)

• Datos comparativos con estimaciones anteriores: para permitir la confianza en el futuro
estimaciones para ser juzgadas
• Informes sobre cualquier dificultad de capacidad específica encontrada en el pasado.
período, con detalles de recuperación y acciones preventivas tomadas para el futuro
• Detalles de las actualizaciones necesarias o adquisiciones necesarias y planificadas para
el futuro, con costes y plazos indicativos .
• Cualquier riesgo potencial de capacidad que sea probable, con sugerencias
contramedidas en caso de que surjan.
4.6.5 Gestión de la disponibilidad
Durante el diseño del servicio y la transición del servicio , los servicios de TI están diseñados para
disponibilidad y recuperación. La Operación del Servicio es responsable de hacer
Servicio de TI disponible para los usuarios especificados en el momento requerido y en el momento acordado.
niveles.
Durante la Operación del Servicio, los equipos de TI y los usuarios están en la mejor posición para
detectar si los servicios cumplen realmente los requisitos acordados y si el
el diseño de estos servicios es eficaz.
Lo que parece una buena idea durante la fase de diseño puede no ser
práctico u óptimo. La experiencia de los usuarios y funciones operativas s
Los convierte en un insumo principal para la mejora continua de los servicios existentes.
y el diseño.
Página 143
Sin embargo, existen varios desafíos para acceder a este

conocimiento:
• La mayoría de las experiencias de los equipos operativos y los usuarios son

informal o distribuido en múltiples fuentes.
• El proceso de recopilación y recopilación de estos datos debe formalizarse.
• Los usuarios y el personal operativo suelen estar completamente ocupados con sus
actividades y tareas y es muy difícil para ellos participar en actividades regulares
actividades de planificación y diseño. Un argumento que se hace a menudo aquí es que si
se mejora el diseño, los equipos operativos estarán menos ocupados resolviendo
problemas y, por lo tanto, tendrá más tiempo para participar en el diseño
ocupaciones. Sin embargo, la práctica muestra que tan pronto como se libera al personal,
a menudo se convierten en el objetivo de los ejercicios de reducción de la fuerza laboral.
Dicho esto, existen tres oportunidades clave para que el personal operativo sea
involucrados en la mejora de la disponibilidad, ya que estos generalmente se consideran parte de
su responsabilidad continua:
• Revisión de actividades de mantenimiento. El diseño del servicio definirá

programas y actividades de mantenimiento, que son necesarios para mantener la TI
servicios que funcionen al nivel requerido de rendimiento y disponibilidad.
Comparación regular de las actividades y tiempos de mantenimiento reales con el
Los planes destacarán las áreas potenciales de mejora. Una de las fuentes de
esta información es un examen de si Mantenimiento Servicio Objetivo s
se cumplieron y, si no, por qué no.
• Revisiones de problemas importantes. Los problemas pueden ser el resultado de cualquier
factores, uno de los cuales es un diseño deficiente. Por lo tanto, las revisiones de problemas pueden
incluir oportunidades para identificar mejoras en el diseño de servicios de TI,
que incluirá la disponibilidad y la mejora de la capacidad.
• Implicación en iniciativas específicas utilizando técnicas como Servicio
Análisis de fallas (SFA), Análisis de impacto de fallas de componentes (CFIA) o
Análisis de árbol de fallas (FTA) o como miembros de la observación técnica (TO)
actividades, ya sea como parte del seguimiento de problemas importantes o como parte de
un programa de mejora continua del servicio , en colaboración con
personal dedicado a la gestión de la disponibilidad . Esta gestión de disponibilidad
Las técnicas se explican con más detalle en la publicación Service Design .
Puede haber ocasiones en las que Operacional personal en sí necesita el tiempo de inactividad de
uno o más servicios que les permitan llevar a cabo su operación o mantenimiento
actividades, que pueden afectar la disponibilidad si no se programan adecuadamente y
administrado. En tales casos, deben ponerse en contacto con SLM y la gestión de disponibilidad.
personal - que negociará con la empresa / usuarios, a menudo utilizando el Service Desk para
desempeñar este papel , acordar y programar dichas actividades.
Página 144
4.6.6 Gestión del conocimiento
Es de vital importancia que todos los datos e información que puedan ser útiles para el futuro
Las actividades de operación del servicio se recopilan, almacenan y evalúan adecuadamente.
Los datos, métricas e información relevantes deben transmitirse a la dirección
cadena y a otras fases del ciclo de vida del servicio para que pueda alimentar la
conocimiento y la sabiduría capas de la organización ‘s Servicio de conocimiento
Sistema de Gestión , cuyas estructuras deben definirse en Servicio
Diseño de estrategia y servicio y refinado en la mejora continua del servicio (ver
otras publicaciones de ITIL de esta serie).
Repositorios clave de la operación del servicio, que se han mencionado con frecuencia
en otros lugares, son el CMS y el KEDB, pero esto debe ampliarse para incluir
toda la documentación de los equipos y departamentos de Operación del Servicio, como
manuales de operación , manuales de procedimientos , instrucciones de trabajo , etc.
4.6.7 Gestión financiera para servicios de TI
El personal de operación del servicio debe participar y respaldar la presupuestación general de TI

y sistema de contabilidad , y puede participar activamente en cualquier sistema de cobro.
que puede estar en su lugar.
Es necesaria una planificación adecuada para que los gastos de capital (Capex) y operativos
Las estimaciones presupuestarias de gastos (Opex) se pueden preparar y acordar a su debido tiempo.
para cumplir con los ciclos presupuestarios.
El Gerente de Operaciones del Servicio también debe participar en actividades regulares, al menos
mensualmente, revisión de los gastos con respecto a los presupuestos, como parte de la TI en curso
proceso de presupuestación y contabilidad . Cualquier discrepancia debe ser identificada y
ajustes necesarios realizados. Todos los gastos comprometidos deben pasar por
sistema de órdenes de compra de la organización para que los compromisos se puedan acumular y
Se deben realizar los controles adecuados en todos los bienes recibidos para que las facturas y
los pagos pueden ser autorizados correctamente, o las discrepancias investigadas y
rectificado.
Cabe señalar que algunas reducciones de costos propuestas por la empresa pueden
realmente aumentan los costos de TI, o al menos los costos unitarios . Por lo tanto, se debe tener cuidado
para garantizar que TI participe en la discusión de todas las medidas de ahorro de costos y
contribuir a las decisiones generales. La gestión financiera se trata en detalle en la
Publicación de estrategia de servicio.
4.6.8 Gestión de la continuidad del servicio de TI
Las funciones de operación del servicio son responsables de la prueba y ejecución de

planes de recuperación del sistema y del servicio según se determina en la Continuidad del servicio de TI
Página 145
Planes para la organización. Además, los gerentes de todas las operaciones del servicio
Las funciones deben estar en el equipo de Coordinación Central de Continuidad del Negocio.
Esto se discute en detalle en Estrategia de servicio y Diseño de servicio y no será

repetido aquí, excepto para indicar que es importante que Operación del servicio
Las funciones deben estar involucradas en las siguientes áreas:
• Evaluación de riesgos , utilizando su conocimiento de la infraestructura y las técnicas.

como la CFIA y el acceso a la información en el CMS para identificar
puntos de falla u otras situaciones de alto riesgo
• Ejecución de las medidas de gestión de riesgos que se acuerden, p. Ej.
implementación de contramedidas , o mayor resiliencia a
componentes de las infraestructuras, etc.
• Asistencia para redactar los planes de recuperación reales para los sistemas y servicios.
bajo su control
• Participación en la prueba de los planes (como la participación en pruebas fuera del sitio,
simulaciones, etc.) de forma continua bajo la dirección del Servicio de TI
Gerente de Continuidad (ITSCM)
• Mantenimiento continuo de los planes bajo el control de ITSCM y
Gestión del cambio
• Participación en campañas de formación y sensibilización para asegurar que sean
Capaz de ejecutar los planes y comprender su función en caso de desastre.
• El Service Desk desempeñará un papel clave en la comunicación con el personal,
clientes y usuarios durante un desastre real
Página 146
5 actividades de operación de servicios comunes

El capítulo 4 trata de los procesos necesarios para una operación eficaz del servicio y
El capítulo 6 se ocupará de los aspectos organizativos. Este capítulo se centra en un
número de actividades operativas que aseguran que la tecnología esté alineada con el
Objetivos generales de Servicio y Proceso s. Estas actividades a veces son
descritos como procesos, pero en realidad son conjuntos de técnicas especializadas
todas las actividades destinadas a garantizar que la tecnología necesaria para entregar y respaldar
los servicios funcionan de manera eficaz y eficiente.
Estas actividades suelen ser de naturaleza técnica, aunque la

la tecnología variará según el tipo de servicios que se presten. Esta
La publicación se centrará en las actividades necesarias para gestionar la TI.
Nota importante sobre la gestión de la tecnología
Es tentador divorciar el concepto de Gestión de servicios del

gestión de la infraestructura que se utiliza para prestar esos servicios.
En realidad, es imposible lograr servicios de calidad sin alinear y 'engranar'

todos los niveles de tecnología (y las personas que la gestionan) a los servicios que se
previsto. La gestión de servicios involucra personas, procesos y tecnología.
En otras palabras, las actividades comunes de Operación del Servicio no se refieren a la gestión
la tecnología en aras de tener un buen rendimiento tecnológico . Son
acerca de lograr un desempeño que integre el componente tecnológico con
las personas y los componentes del proceso para lograr los objetivos comerciales y de servicio .
Consulte la Figura 5.1 para ver ejemplos de cómo se gestiona la tecnología en la maduración.
Organizaciones.
Página 147
Figura 5.1 Alcanzar la madurez en la gestión tecnológica
La figura 5.1 ilustra los pasos necesarios para madurar desde un enfoque centrado en la tecnología.
organización a una organización que aprovecha la tecnología como parte de su negocio
estrategia. La figura 5.1 describe con más detalle el papel de los gerentes de tecnología en
organizaciones de diferente madurez . El diagrama no es completo, pero sí
proporcionar ejemplos de la forma en que se gestiona la tecnología en cada tipo de
organización. Los encabezados en negrita indican el papel principal que desempeña TI en la gestión
tecnología. El texto de las filas describe las características de una TI.
departamento en cada nivel.
El propósito de este diagrama en este capítulo es el siguiente:
• Este capítulo se centra en las actividades de gestión técnica , pero no

única forma de representarlos. Una organización menos madura tenderá a
ven estas actividades como fines en sí mismos, no como un medio para un fin. Un mas
La organización madura tenderá a subordinar estas actividades a los de nivel superior.
Objetivo de la gestión del servicio s. Por ejemplo, la gestión del servidor
El equipo pasará de un departamento aislado, centrado exclusivamente en
administrar servidores, a un equipo que trabaja en estrecha colaboración con otras tecnologías
Gerentes para encontrar formas de incrementar su valor para el negocio.
Página 148
• Hacer y reforzar el punto de que no existe una forma "correcta" de agrupar y

organizando los departamentos que realizan estos servicios. Algunos lectores
podría interpretar los títulos de este capítulo como nombres de departamentos,
Pero este no es el caso. El objetivo de este capítulo es identificar las características típicas
actividades técnicas involucradas en la Operación del Servicio . Aspectos organizativos
se discuten en el Capítulo 6.
• Las actividades de Operación del servicio descritas en el resto de este capítulo son
no es típico de ninguno de los niveles de madurez. Más bien, las actividades son
por lo general, todos están presentes de alguna forma en todos los niveles. Simplemente están organizados y
gestionado de forma diferente en cada nivel.
En algunos casos, un grupo dedicado puede manejar todo un proceso o actividad mientras está en
otros casos, los procesos o actividades pueden ser compartidos o divididos entre grupos.
Sin embargo, a modo de orientación general, las siguientes secciones enumeran los
actividades de los grupos funcionales con mayor probabilidad de estar involucrados en su operación .
Esto no significa que todas las organizaciones tengan que utilizar estas divisiones. Menor
Las organizaciones tenderán a asignar grupos de estas actividades (si son necesarias en
todos) a departamentos individuales, o incluso a individuos.
Finalmente, el propósito de este capítulo no es proporcionar un análisis detallado de todos los

ocupaciones. Son especializadas y hay una guía detallada disponible en el
proveedores de plataformas y otros marcos más técnicos; nuevas categorías serán
agregado continuamente a medida que la tecnología evoluciona. Este capítulo simplemente tiene como objetivo resaltar
la importancia y la naturaleza de la gestión de la tecnología para la gestión de servicios
en el contexto de TI.
Página 149
5.1 Seguimiento y control
La medición y control de los servicios se basa en un ciclo continuo de

seguimiento , presentación de informes y acción posterior. Este ciclo se analiza en detalle en
esta sección porque es fundamental para la entrega, el soporte y la mejora
de servicios.
También es importante tener en cuenta que, aunque este ciclo tiene lugar durante el Servicio
Operación, proporciona una base para establecer la estrategia , diseñar y probar los servicios.
y lograr una mejora significativa. También es la base de SLM
medición. Por lo tanto, aunque la operación de servicio realiza el monitoreo
funciones , no debe verse como una cuestión puramente operativa . Todas las fases del
El ciclo de vida del servicio debe garantizar que las medidas y los controles estén claramente definidos,
ejecutado y actuado.
5.1.1 Definiciones
El seguimiento se refiere a la actividad de observar una situación para detectar cambios que
suceden con el tiempo.
En el contexto de la Operación del Servicio , esto implica lo siguiente:
• Uso de herramientas para monitorear el estado de CI clave y actividades operativas clave

• Asegurarse de que se cumplan (o no se cumplan) las condiciones especificadas y, de no ser así, aumentar
una alerta para el grupo apropiado (por ejemplo, la disponibilidad de la red clave
dispositivos)
• Asegurar que el rendimiento o la utilización de un componente o sistema es
dentro de un rango específico (por ejemplo, espacio en disco o utilización de memoria)
• Para detectar tipos o niveles anormales de actividad en la infraestructura (p. Ej.
posibles amenazas a la seguridad )
• Para detectar cambios no autorizados (por ejemplo, introducción de software)
• Para garantizar el cumplimiento de las políticas de la organización (p. Ej., Inapropiadas
uso del correo electrónico)
• Para realizar un seguimiento de los resultados para el negocio y garantizar que cumplan con la calidad y
requisitos de rendimiento s
• Para rastrear cualquier información que se utilice para medir el rendimiento clave
Indicadores (KPI).
La presentación de informes se refiere al análisis, producción y distribución de la salida del
actividad de seguimiento .
En el contexto de la Operación del Servicio , esto implica lo siguiente:
• El uso de herramientas para recopilar la salida de la información de seguimiento que se puede

difundido a diversos grupos, funciones o procesos
• Interpretar el significado de esa información
Página 150
• Determinar dónde se utilizaría mejor esa información

• Asegurar que los tomadores de decisiones tengan acceso a la información que
les permite tomar decisiones
• Enrutar la información reportada a la persona, grupo o herramienta apropiada.
El control se refiere al proceso de gestionar la utilización o el comportamiento de un dispositivo,

sistema o servicio . Sin embargo, es importante señalar que simplemente manipular un
dispositivo no es lo mismo que controlarlo. El control requiere tres condiciones:
• La acción debe garantizar que el comportamiento se ajuste a un estándar definido o

norma
• Las condiciones que motivan la acción deben definirse, entenderse y
confirmado
• La acción debe estar definida, aprobada y apropiada para estos
condiciones.
En el contexto de la Operación del Servicio , el control implica lo siguiente:
• Usar herramientas para definir qué condiciones representan operaciones normales o

operaciones anormales
• Regular el rendimiento de dispositivos, sistemas o servicios.
• Medir la disponibilidad
• Iniciar una acción correctiva, que podría automatizarse (por ejemplo, reiniciar un dispositivo
remotamente o ejecutar un script), o manual (por ejemplo, notificar al personal de operaciones de la
estado ).
5.1.2 Monitorear lazos de control
El modelo más común para definir el control es Monitor Control Loop .

Aunque es un modelo simple, tiene muchas aplicaciones complejas dentro del Servicio de TI.
Gestión . Esta sección definirá los conceptos básicos del Monitor Control
El modelo de bucle y las secciones siguientes mostrarán la importancia de estos conceptos
son para el ciclo de vida de la gestión de servicios .
Página 151
Figura 5.2 Lazo de control del monitor
La figura 5.2 describe los principios básicos de control. Una sola actividad y su salida
se miden utilizando una norma predefinida, o estándar , para determinar si es
dentro de un rango aceptable de rendimiento o calidad . Si no es así, se toman medidas para
rectificar la situación o restablecer el rendimiento normal.
Normalmente, hay dos tipos de bucles de control de monitorización:
• Lazo abierto del sistema s están diseñados para realizar una determinada actividad
independientemente de las condiciones ambientales. Por ejemplo, una copia de seguridad puede ser
iniciado en un momento y frecuencia determinados, y se ejecutará independientemente de otros
condiciones.
• Los sistemas de circuito cerrado monitorean un entorno y responden a los cambios
en ese entorno. Por ejemplo, en el equilibrio de carga de la red, un monitor
evaluar el tráfico en un circuito. Si el tráfico de la red excede un cierto rango,
el sistema de control comenzará a enrutar el tráfico a través de un circuito de respaldo. los
El monitor continuará proporcionando retroalimentación al sistema de control que
Continuar regulando el flujo de tráfico de la red entre los dos circuitos.
Página 152
Para ayudar a aclarar la diferencia, resolviendo la gestión de la capacidad a través de

el aprovisionamiento es de bucle abierto; un equilibrador de carga que detecta congestión / falla y
redirige la capacidad es de circuito cerrado.
5.1.2.1 Lazo de control de monitor complejo
El bucle de control del monitor en la figura 5.2 es una buena base para definir cómo
La gestión de operaciones funciona, pero en el contexto de ITSM la situación está lejos
mas complejo. La figura 5.3 ilustra un proceso que consta de tres
ocupaciones. Cada uno tiene una entrada y una salida, y la salida se convierte en una entrada.
para la próxima actividad.
En este diagrama, cada actividad está controlada por su propio bucle de control de monitor, utilizando
un conjunto de normas para esa actividad específica. El proceso en su conjunto también tiene su propio
Monitor Control Loop, que abarca todas las actividades y garantiza que todas las normas
son apropiados y se están siguiendo.
Figura 5.3 Lazo de control de monitor complejo
En la Figura 5.3 hay un ciclo de retroalimentación doble. Un bucle se centra exclusivamente en

ejecutando un estándar definido , y el segundo evalúa el desempeño del
proceso y también los estándares mediante los cuales se ejecuta el proceso. Un ejemplo de
esto sería si el primer conjunto de bucles de retroalimentación en la parte inferior del diagrama
Página 153
representaron estaciones individuales en una línea de montaje y el bucle de nivel superior

representado Aseguramiento de la Calidad .
El Complex Monitor Control Loop es una buena herramienta de aprendizaje organizacional (como
definido por Chris Argyris, (1976) Increasing Leadership Effectiveness . Nueva York:
Wiley). El primer nivel de retroalimentación a nivel de actividad individual se refiere a
monitorear y responder a los datos (hechos únicos, códigos o piezas de información).
El segundo nivel tiene que ver con el seguimiento y la respuesta a la información (un
recopilación de una serie de hechos sobre los que se puede sacar una conclusión). Referirse a
la publicación Service Transition para una discusión completa sobre datos, información,
Conocimiento y sabiduría.
Todo esto es una teoría interesante, pero no explica cómo el bucle de control del monitor
El concepto se puede utilizar para operar servicios de TI . Y especialmente, ¿quién define el
¿norma? Según lo que se ha descrito hasta ahora, los bucles de control de monitor se pueden
utilizado para gestionar:
• La realización de actividades en un proceso o procedimiento . Cada actividad

y su salida relacionada puede potencialmente medirse para asegurar que el problema s
con el proceso se identifican antes de que el proceso en su conjunto sea
terminado. Por ejemplo, en la gestión de incidentes , la mesa de servicio
supervisa si un equipo técnico ha aceptado un incidente en un determinado
hora. De lo contrario, el incidente se agrava. Esto se hace mucho antes de que el objetivo
tiempo de resolución para ese incidente porque el objetivo de escalar ese
La actividad consiste en garantizar que el proceso en su conjunto se complete a tiempo.
• La efectividad de un proceso o procedimiento en su conjunto. En este caso el
El cuadro de ' actividad ' representa todo el proceso como una sola entidad. Por ejemplo,
La Gestión del Cambio medirá el éxito del proceso mediante
comprobar si un cambio se implementó a tiempo, según las especificaciones y
dentro del presupuesto .
• El rendimiento de un dispositivo. Por ejemplo, el cuadro de 'actividad' podría
representan el tiempo de respuesta de un servidor con una carga de trabajo determinada .
• El rendimiento de una serie de dispositivos. Por ejemplo, el usuario final
tiempo de respuesta de una aplicación en la red.
Definir cómo utilizar el concepto de lazos de control del monitor en servicio

Gestión , es necesario responder a las siguientes preguntas:
• ¿Cómo definimos lo que se debe monitorear?

• ¿Cuáles son los umbrales apropiados para cada uno de estos?
• ¿Cómo se realizará el seguimiento (manual o automatizado)?
• ¿Qué representa el funcionamiento normal ?
• ¿Cuáles son las dependencias para el funcionamiento normal?
• ¿Qué sucede antes de que obtengamos la entrada?
• ¿Con qué frecuencia debe realizarse la medición?
Página 154
• ¿Necesitamos realizar una medición activa para comprobar si el artículo es

dentro de la norma o esperamos hasta que se informe una excepción (pasivo
medición)?
• ¿Es la Gestión de Operaciones la única función que realiza el seguimiento?
• Si no es así, ¿cómo se relacionan las otras instancias de supervisión con las operaciones?
¿Administración?
• Si hay varios bucles, ¿qué procesos son responsables de cada bucle?
Las siguientes secciones ampliarán el concepto de bucles de control de monitor y

Demuestre cómo se responden estas preguntas.
5.1.2.2 Lazo de control del monitor ITSM
En ITSM, el complejo bucle de control del monitor se puede representar como se muestra en
Figura 5.4.
Figura 5.4 Lazo de control del monitor ITSM
Figura 5.4 se puede utilizar para ilustrar el control de de un proceso o de la componente s

utilizado para prestar un servicio . En este diagrama, la palabra 'actividad' implica que se refiere a
Página 155
un proceso. Para aplicarlo a un servicio, una 'actividad' también podría ser un 'CI'. Hay un
número de características significativas en la Figura 5.4:
• Cada actividad en un proceso de Gestión de servicios (o cada componente utilizado

para proporcionar un servicio ) se supervisa como parte de la Operación del servicio
Procesos. El equipo operativo o departamento responsable de cada
La actividad o componente aplicará el bucle de control del monitor como se define en el
proceso , y utilizando las normas que se definieron durante el Diseño del Servicio
Procesos. El rol del Monitoreo y Control Operacional es asegurar
que el proceso o servicio funciona exactamente como se especifica, por lo que
se preocupan principalmente por mantener el statu quo.
• Las normas y mecanismos de Seguimiento y Control se definen en Servicio
Diseño, pero se basan en los estándares y las arquitecturas definidas
durante la estrategia de servicio . Cualquier cambio en el servicio de la organización .
Estrategia, arquitectura, servicios de carteras o de nivel de servicio Requisito s
precipitará cambios en lo que se monitorea y cómo se controla.
• Los bucles de control del monitor se colocan dentro del contexto del
organización. Esto implica que la estrategia de servicio se ejecutará principalmente
por ejecutivos comerciales y de TI con el apoyo de la cuenta del proveedor
gerente s. El diseño del servicio actúa como puente entre la estrategia del servicio
y Operación del Servicio y por lo general involucrará a representantes de todos
grupos. Las actividades y controles generalmente serán ejecutados por personal de TI.
(a veces involucrando a los usuarios ) y con el apoyo de los gerentes de TI y el
vendedores. La mejora del servicio abarca todas las áreas, pero representa principalmente
los intereses de la empresa y sus usuarios.
• Note que el segundo nivel de monitoreo en este complejo Control de Monitoreo
El bucle lo realizan los procesos de CSI a través de la estrategia de servicio y
Diseño de servicio. Estas relaciones están representadas por los números
flechas en la Figura 5.4 de la siguiente manera:
• Flecha 1. En este caso, CSI ha reconocido que el servicio será
mejorado al hacer un cambio en la estrategia de servicio. Esto podría
ser el resultado de que la empresa necesita un cambio en el Servicio
Portafolio , o que la arquitectura no entrega lo que se
previsto.
• Flecha 2. En este caso, los requisitos de nivel de servicio deben ser
equilibrado. Puede ser que el servicio sea demasiado caro; o que el
la configuración de la infraestructura debe cambiarse para mejorar
desempeño ; o porque la Gerencia de Operaciones no puede
Mantener la calidad del servicio en la arquitectura actual.
• Flecha 3. En este caso, las normas especificadas en Diseño de servicios no son
siendo adherido. Esto podría deberse a que no son apropiados.
o ejecutable, o por falta de educación o falta de
comunicación. Las normas y el incumplimiento deben ser
investigado y se tomaron medidas para rectificar la situación.
Página 156
Service Transition proporciona un importante conjunto de controles y contrapesos en estos

Procesos. Lo hace de la siguiente manera:
• Para nuevos servicios, Service Transition asegurará que el técnico

las arquitecturas son apropiadas; y que el Desempeño Operacional
Se pueden ejecutar estándares. Esto, a su vez, garantizará que el Servicio
Los equipos o departamentos de operaciones pueden cumplir con el nivel de servicio
Requerimientos.
• Para los servicios existentes , Change Management gestionará cualquiera de los
cambios que se requieren como parte de un control (por ejemplo, sintonización ), así como cualquier
cambios representados por las flechas etiquetadas 1, 2 y 3. Aunque el Servicio
La transición no define los servicios de estrategia y diseño per se, proporciona
coordinación y garantía de que los servicios están funcionando y
Continúe trabajando, según lo planeado.
¿Por qué este bucle está cubierto por la operación del servicio ?
La figura 5.4 representa la supervisión y el control de todo el servicio de TI.

Gestión . Algunos lectores de la publicación Operación del servicio pueden sentir que
debería tratarse de forma más adecuada en la publicación Estrategia de servicio.
Sin embargo, el monitoreo y el control solo se pueden implementar de manera efectiva cuando el
el servicio está operativo . Esto significa que la calidad de todo el conjunto de servicios de TI
Los procesos de gestión dependen de cómo se supervisan y controlan en
Operación de servicio.
Las implicaciones de esto son las siguientes:
• El personal de operaciones de servicio no son las únicas personas interesadas en lo que

monitoreados y cómo se controlan.
• Si bien la Operación del Servicio es responsable del monitoreo y control de
servicios y componentes , actúan como administradores de un importante
parte del conjunto de lazos de control y supervisión de ITSM
• Si el personal de Operación del Servicio define y ejecuta Monitoreo y Control
procedimientos s de forma aislada, ninguno de los procesos de Gestión del Servicio o
Las funciones serán completamente efectivas. Esto se debe a que la operación de servicio
funciones no respaldarán las prioridades y los requisitos de información del
otros procesos, por ejemplo, intentar negociar un SLA cuando los únicos datos
están disponibles las tasas de intercambio de páginas en un servidor y la utilización detallada del ancho de banda
de una red.
5.1.2.3 Definición de lo que se debe monitorear
La definición de lo que necesita ser monitoreado se basa en comprender el

resultado deseado de un proceso, dispositivo o sistema . TI debería centrarse en el servicio
y su impacto en el negocio, en lugar de solo los componentes individuales de
Página 157
tecnología. La primera pregunta que debe hacerse es '¿Qué estamos tratando de

¿lograr?'.
5.1.2.4 Monitoreo y control interno y externo
Al principio, quedará claro que hay dos niveles de seguimiento:
• Monitoreo y control interno: la mayoría de los equipos o departamentos

preocupado por poder ejecutar de manera efectiva y eficiente las tareas
que les han sido asignados. Por lo tanto, controlarán los elementos
y actividades que están directamente bajo su control. Este tipo de seguimiento
y el control se centra en actividades que son autónomas dentro de ese equipo o
Departamento. Por ejemplo, Service Desk Manager supervisará el
volumen de llamadas para determinar cuántos miembros del personal deben estar disponibles para
contesta el telefono.
• Monitoreo y Control Externo: Aunque cada equipo o departamento
responsables de la gestión de su propia área, no actúan de forma independiente.
Todas las tareas que realizan o los dispositivos que administran tienen un impacto
sobre el éxito de la organización en su conjunto. Cada equipo o departamento
también controlará elementos y actividades en nombre de otros grupos,
procesos o funciones s. Por ejemplo, el equipo de administración del servidor
supervisar el rendimiento de la CPU en servidores clave y realizar la carga de trabajo
Equilibrio para que una aplicación crítica pueda mantenerse dentro del rendimiento.
los umbrales establecidos por la gestión de aplicaciones .
La distinción entre monitoreo interno y externo es importante. Si

La operación del servicio se enfoca solo en el monitoreo interno, tendrá muy bien
infraestructura gestionada, pero no hay forma de comprender o influir en la calidad de
servicios. Si se enfoca solo en el Monitoreo Externo, comprenderá cuán pobre es el
La calidad del servicio lo es, pero no tendrá idea de qué lo está causando o cómo cambiarlo.
En realidad, la mayoría de las organizaciones tienen una combinación de servicios internos y externos.
Monitoreo, pero en muchos casos estos no están vinculados. Por ejemplo, el servidor
El equipo de administración sabe exactamente qué tan bien se están desempeñando los servidores y el
Service Level Manager sabe exactamente cómo los usuarios perciben la calidad de
servicio proporcionado por los servidores. Sin embargo, ninguno de ellos sabe cómo vincular
estas métricas para definir qué nivel de rendimiento del servidor representa una buena calidad
servicio . Esto se vuelve aún más confuso cuando el rendimiento del servidor es
aceptable a mediados de mes, no es aceptable a fin de mes.
5.1.2.5 Definición de objetivos de seguimiento y control
Muchas organizaciones comienzan con la pregunta "¿Qué estamos gestionando?". Esta

invariablemente conducirá a un fuerte Sistema de Monitoreo Interno , con muy poca vinculación
al resultado o servicio real que requiere la empresa.
Página 158
La pregunta más apropiada es '¿Cuál es el resultado final de las actividades y

equipo que maneja mi equipo? '. Por lo tanto, el mejor lugar para comenzar, cuando
definir qué monitorear, es determinar el resultado requerido.
La definición de los objetivos de Monitoreo y Control idealmente debería comenzar con el

definición del Requisito de Nivel de Servicio s documento s (ver Diseño del Servicio
publicación). Estos especificarán cómo el cliente y el usuario medirán el
desempeño del servicio, y se utilizan como entrada en el diseño del servicio
Procesos. Durante el Diseño del Servicio, varios procesos determinarán cómo
el servicio será entregado y administrado. Por ejemplo, Gestión de la Capacidad voluntad
Determinar la forma más adecuada y rentable de ofrecer los niveles de
rendimiento requerido. La gestión de disponibilidad determinará cómo
La infraestructura se puede configurar para proporcionar la menor cantidad de puntos de falla .
Si existe alguna duda sobre la validez o integridad de los objetivos, el COBIT

El marco proporciona un conjunto completo de objetivos de alto nivel como una lista de verificación.
Se proporciona más información sobre COBIT en el Apéndice A de esta publicación.
El proceso de diseño del servicio ayudará a identificar los siguientes conjuntos de entradas para
definir normas y mecanismos de Monitoreo y Control Operacional :
• Trabajarán con clientes y usuarios para determinar cómo la salida de

se medirá el servicio. Esto incluirá mecanismos de medición,
frecuencia y muestreo. Esta parte del diseño del servicio se enfocará específicamente
sobre los Requisitos Funcionales.
• Identificarán los CI clave, cómo deben configurarse y qué nivel de
El rendimiento y la disponibilidad son necesarios para cumplir con los
Nivel de servicio s.
• Trabajarán con los desarrolladores y proveedores de los CI que componen
cada servicio para identificar cualquier restricción o limitación en esos componentes .
• Todos los equipos y departamentos de soporte y entrega deberán identificar qué
la información les ayudará a ejecutar su función de manera eficaz. Parte de
El diseño y desarrollo del servicio consistirá en instrumentar cada servicio para que
puede ser monitoreado para proporcionar esta información, o para que pueda generar
evento significativo s.
Todo esto significa que una parte muy importante de definir qué Operación del Servicio
monitorea y cómo ejerce el control es identificar a los interesados de cada
servicio .
Las partes interesadas pueden definirse como cualquier persona interesada en una entrega exitosa
y recepción de servicios de TI . Cada actor tendrá una perspectiva diferente de
lo que se necesita para entregar o recibir un servicio de TI. La operación del servicio deberá
comprender cada una de estas perspectivas para determinar exactamente qué necesidades
monitorear y qué hacer con la salida.
Página 159
Por lo tanto, la operación del servicio dependerá de SLM para definir exactamente quiénes son estos
son las partes interesadas y cómo contribuyen o utilizan el servicio. Esto se discute
más plenamente en el diseño del servicio y la mejora continua del servicio
Publicaciones.
Nota sobre los objetivos de seguimiento interno y externo
El resultado requerido podría ser interno o externo a la Operación del Servicio.

función s, aunque siempre debe recordarse que una acción interna
a menudo tienen un resultado externo. Por ejemplo, consolidar los servidores para hacerlos
más fácil de administrar puede resultar en un ahorro de costos , lo que afectará al SLM
ciclo de negociación y revisión , así como los procesos de Gestión Financiera .
5.1.2.6 Tipos de seguimiento
Hay muchos tipos diferentes de herramientas de monitoreo y diferentes situaciones en las que
cada uno será utilizado. Esta sección se centra en algunos de los diferentes tipos de
seguimiento que se puede realizar y cuándo sería oportuno.
Monitoreo activo versus pasivo
• Monitoreo activo se refiere a la 'interrogación' en curso de un dispositivo o

sistema para determinar su estado . Este tipo de monitoreo puede ser un recurso
intensivo y generalmente se reserva para monitorear proactivamente la disponibilidad de
dispositivos o sistemas críticos; o como paso de diagnóstico al intentar
resolver un incidente o diagnosticar un problema .
• El Monitoreo Pasivo es más común y se refiere a generar y
transmitir eventos a un 'dispositivo de escucha' o agente de monitoreo. Pasivo
El monitoreo depende de la definición exitosa de eventos e instrumentación
del sistema que se está supervisando (consulte la sección 4.1).
Reactivo versus proactivo
• El monitoreo reactivo está diseñado para solicitar o desencadenar una acción después de una
cierto tipo de evento o falla . Por ejemplo, el rendimiento del servidor
La degradación puede desencadenar un reinicio, o una falla del sistema generará una
incidente . El monitoreo reactivo no solo se usa para excepciones. También puede
ser utilizado como parte de los procedimientos de operaciones normales , por ejemplo, un trabajo por lotes
se completa con éxito, lo que solicita al sistema de programación que envíe
el siguiente trabajo por lotes.
• El monitoreo proactivo se utiliza para detectar patrones de eventos que indican
que un sistema o servicio puede estar a punto de fallar. El monitoreo proactivo es
Generalmente se utiliza en entornos más maduros donde estos patrones tienen
detectado previamente, a menudo varias veces. Herramientas de monitoreo proactivo
son, por tanto, un medio para automatizar la experiencia del personal de TI experimentado
Página 160
y a menudo se crean a través de la gestión proactiva de problemas

proceso (consulte la publicación Mejora continua del servicio).
Tenga en cuenta que el monitoreo reactivo y proactivo puede ser activo o pasivo,
según la Tabla 5.1:
Activo Pasivo
Reactivo Se utiliza para diagnosticar qué dispositivo está Detecta y correlaciona los registros de eventos con
causando la falla y bajo lo que determinar el significado del evento sy el
condiciones (por ejemplo, hacer ping a un dispositivoacción
o ejecutar
apropiada (por ejemplo, un usuario inicia sesión en tres
y rastrear una transacción de muestra veces con la contraseña incorrecta, que
a través de una serie de dispositivos) genera representa una excepción de seguridad
y se escala a través de Seguridad de la información
Requiere conocimiento de la Procedimientos de gestión s)
topografía de la infraestructura y la
mapeo de servicios a CI Requiere un conocimiento detallado de lo normal
operación de la infraestructura y servicios
Proactivo Usado para determinar el tiempo real Los registros de eventos se correlacionan a lo largo del tiempo con
estado de un dispositivo, sistema o servicio crear tendencias para un problema proactivo
- generalmente para componentes críticos o Administración.
después de la recuperación de un fallido
dispositivo para asegurarse de que esté completamenteLos patrones de eventos se definen y
recuperado (es decir, no va a causar programado en herramientas de correlación para el futuro
más incidentes) reconocimiento
Tabla 5.1 Monitoreo activo y pasivo reactivo y proactivo
Medición continua versus medición basada en excepciones
• La medición continua se enfoca en monitorear un sistema en tiempo real

para asegurar que cumple con una norma de desempeño (por ejemplo, una
el servidor de aplicaciones está disponible para el 99,9% de las horas de servicio acordadas ). los
La diferencia entre la medición continua y la monitorización activa es
que Active Monitoring no tiene que ser continuo. Sin embargo, como con
Monitoreo activo, esto requiere muchos recursos y generalmente se reserva para
componentes o servicios críticos. En la mayoría de los casos, el costo del adicional
El ancho de banda y la potencia del procesador superan el beneficio de la
medición. En estos casos, el seguimiento se basará normalmente en
muestreo y análisis estadístico (por ejemplo, se informa el rendimiento del sistema
cada 30 segundos y extrapolado para representar el rendimiento general). En
En estos casos, el método de medición deberá estar documentado y
acordado en los OLA para garantizar que sea adecuado para respaldar al Servicio
Requisitos de informes (consulte la publicación Mejora continua del servicio ).
• La medición basada en excepciones no mide el tiempo real
rendimiento de un servicio o sistema, pero detecta e informa contra
excepciones. Por ejemplo, se genera un evento si una transacción no
completa, o si se alcanza un umbral de rendimiento . Esto es más costoso
efectivo y más fácil de medir, pero podría resultar en cortes de servicio más prolongados .
Página 161
La medición basada en excepciones se utiliza para sistemas menos críticos o en

sistemas donde el costo es un problema importante. También se utiliza donde las herramientas de TI no están
capaz de determinar el estado o la calidad de un servicio (por ejemplo, si la calidad de impresión es
parte de la especificación del servicio , la única forma de medir esto es física
inspección, a menudo realizada por el usuario en lugar del personal de TI). Dónde
Se utiliza la medición basada en excepciones, es importante que tanto el OLA
y el SLA para ese servicio reflejan esto, ya que las interrupciones del servicio son más probables
que ocurra, y los usuarios a menudo deben informar la excepción.
Rendimiento versus salida
Existe una distinción importante entre los informes utilizados para rastrear el
Desempeño de los componentes, equipos o departamentos utilizados para brindar un servicio.
y los informes utilizados para demostrar el logro de la calidad del servicio
objetivo s.
Los gerentes de TI a menudo los confunden al informar a la empresa sobre el

desempeño de sus equipos o departamentos (por ejemplo, número de llamadas tomadas por
Service Desk Analyst), como si eso fuera lo mismo que la calidad del servicio (p. Ej.
Incidencias resueltas en el tiempo acordado).
El Servicio debe utilizar internamente la supervisión del rendimiento y las métricas .

Gestión para determinar si las personas, los procesos y la tecnología
funcionando correctamente y al estándar.
Los usuarios y los clientes prefieren ver informes relacionados con la calidad y
ejecución del servicio .
Aunque la Operación del Servicio se ocupa de ambos tipos de informes, el

La principal preocupación de esta publicación es la supervisión del rendimiento, mientras que
El monitoreo de la calidad del servicio (o monitoreo basado en resultados) se discutirá en
detalles en la publicación Mejora continua del servicio .
5.1.2.7 Monitoreo en entornos de prueba
Al igual que con cualquier infraestructura de TI , un entorno de prueba deberá definir cómo
uso de seguimiento y control . Estos controles se analizan con más detalle en el
Publicación de transición del servicio .
• Supervisión del entorno de prueba en sí: un entorno de prueba consta de

infraestructura, aplicaciones y procesos que deben gestionarse y
controlado como cualquier otro entorno. Es tentador pensar que el
El entorno de prueba no necesita un seguimiento y control rigurosos porque
no es un entorno vivo . Sin embargo, este argumento no es válido. Si una prueba
El medio ambiente no se supervisa y controla adecuadamente, existe el peligro de
Página 162
ejecutar las pruebas en equipos que se desvían de los estándares definidos en

Diseño de servicios .
• Monitoreo de los elementos que se están probando: Los resultados de las pruebas deben ser
rastreado y verificado con precisión. También es importante que cualquier seguimiento
Las herramientas que se han integrado en servicios nuevos o modificados deben probarse.
también.
5.1.2.8 Notificación y acción
“Un informe por sí solo crea conciencia; un informe con un plan de acción logra resultados ”.
Informes y dis función
La experiencia práctica ha demostrado que hay más informes en casos disfuncionales.

organizaciones que en organizaciones eficaces. Esto se debe a que los informes no
se utiliza para iniciar planes de acción predefinidos , sino más bien:
• para echar la culpa por un incidente

• para tratar de averiguar quién es el responsable de tomar una decisión
• como entrada para la creación de planes de acción para sucesos futuros.
En las organizaciones disfuncionales se producen muchos informes que nadie tiene

tiempo para mirar o consultar.
El seguimiento sin control es irrelevante e ineficaz. El seguimiento siempre debe

tener como objetivo garantizar que se cumplan los objetivos operativos y de servicio . Esta
significa que a menos que haya un propósito claro para monitorear un sistema o servicio,
no debe ser monitoreado.
Esto también significa que cuando se define el monitoreo, también debería

comportamiento. Por ejemplo, poder detectar que una aplicación importante ha fallado es
insuficiente. El equipo de gestión de aplicaciones correspondiente también debe tener
definió los pasos exactos que tomará cuando la aplicación falle.
Además, también debe reconocerse que puede ser necesario que las
diferentes personas, por ejemplo, un solo evento (como un error de aplicación ) puede
desencadenar la acción del equipo de gestión de aplicaciones (para restaurar el servicio), los usuarios
(para iniciar el procesamiento manual) y la gestión (para determinar cómo este evento
puede prevenirse en el futuro).
Las implicaciones de este principio se describen con más detalle en relación con Event
Gestión (ver sección 4.1).
5.1.2.9 Auditorías de operación del servicio
Página 163
Regulares de auditoría s deben realizarse en los de Operación del Servicio procesos y

actividades para asegurar:
• Se están realizando según lo previsto

• No hay elusión
• Todavía son aptos para su propósito , o para identificar cualquier cambio requerido o
Mejoras.
Los gerentes de operaciones del servicio pueden optar por realizar dichas auditorías ellos mismos, pero
idealmente, es preferible alguna forma de elemento independiente de las auditorías.
Es posible que se solicite al equipo o departamento de auditoría interna de TI de la organización que
involucrados o algunas organizaciones pueden optar por contratar a terceros
empresas de consultoría / auditoría / evaluación para que un experto totalmente independiente
se obtiene la vista.
Las auditorías de operación del servicio son parte de la medición continua que se lleva a cabo
como parte de la mejora continua del servicio y se analizan con más detalle en
esa publicación.
5.1.2.10 Medición, métricas y KPI
Esta sección se ha centrado principalmente en el seguimiento y control como base para

Operación de servicio. Otras secciones de la publicación han cubierto algunos
métricas que podrían usarse para medir la efectividad y eficiencia de un
proceso .
Aunque esta publicación no trata principalmente de medidas y métricas, es

Es importante que las organizaciones que utilizan estas pautas tengan una medición sólida
técnicas y métricas que apoyan los objetivos de su organización . Esta
La sección es un resumen de estos conceptos.
Medición
La medición se refiere a cualquier técnica que se utiliza para evaluar la extensión,

dimensión o capacidad de un artículo en relación con un estándar o unidad.
• El alcance se refiere al grado de cumplimiento o finalización (por ejemplo, todos

cambios autorizados formalmente por la autoridad competente)
• La dimensión se refiere al tamaño de un artículo, por ejemplo, el número de incidentes
resuelto por el Service Desk
• La capacidad se refiere a la capacidad total de un artículo, por ejemplo, el máximo
número de transacciones estándar que pueden ser procesadas por un servidor por
minuto.
Página 164
La medición sólo se vuelve significativa cuando es posible medir el

Salida o dimensiones reales de un sistema , función o proceso en comparación con un estándar.
o nivel deseado, por ejemplo, el servidor debe ser capaz de procesar un mínimo de 100
transacciones estándar por minuto. Esto debe definirse en Service Design,
y refinado con el tiempo a través de la mejora continua del servicio , pero el
la medición en sí tiene lugar durante la operación de servicio .
Métrica
Las métricas se refieren a la evaluación cuantitativa y periódica de un proceso , sistema o

función, junto con los procedimientos y herramientas que se utilizarán para hacer estos
evaluaciones y los procedimientos para interpretarlas.
Esta definición es importante porque no solo especifica lo que debe ser

medido, sino también cómo medirlo, cuál es el rango aceptable de rendimiento
será y qué acción deberá tomarse como resultado del desempeño normal o
una excepción. A partir de esto, está claro que cualquier métrica dada en la sección anterior de
Esta publicación es muy básica y deberá aplicarse y ampliarse.
dentro del contexto de cada organización antes de que pueda ser eficaz.
Indicadores clave de rendimiento
Un KPI se refiere a un nivel de desempeño específico y acordado que se utilizará para

medir la efectividad de una organización o proceso .
Los KPI son únicos para cada organización y deben estar relacionados con insumos específicos,
productos y actividades. No son genéricos ni universales y, por tanto, no han sido
incluido en esta publicación.
Otra razón para no incluirlos es el hecho de que se pueden usar métricas similares
para lograr KPI muy diferentes. Por ejemplo, una organización utilizó la métrica
'Porcentaje de Incidencias resueltas por el Service Desk ' para evaluar la
desempeño del Service Desk. Esto funcionó eficazmente durante unos dos años,
después de lo cual el gerente de TI comenzó a darse cuenta de que este KPI se estaba utilizando para
prevenir una gestión eficaz de problemas , es decir, si, después de dos años, el 80% de todos
los incidentes son bastante fáciles de resolver en 10 minutos en la primera llamada , ¿por qué
¿No encontramos una solución para ellos? En efecto, el KPI ahora se convirtió en un
medir la ineficacia de los equipos de gestión de problemas.
5.1.2.11 Interfaces con otras prácticas del ciclo de vida del servicio
Monitoreo operativo y mejora continua del servicio
Esta sección se ha centrado en el seguimiento y la presentación de informes operativos , pero

El monitoreo también constituye el punto de partida para la mejora continua del servicio . Esta
Página 165
se trata en la publicación Mejora continua del servicio, pero las diferencias clave
se describen aquí.
La calidad es el objetivo clave del seguimiento para la mejora continua del servicio.
(CSI). Por tanto, el seguimiento se centrará en la eficacia de un servicio , proceso,
herramienta, organización o CI. El énfasis no está en asegurar un servicio en tiempo real
rendimiento; más bien se trata de identificar dónde se pueden realizar mejoras a la
nivel de servicio existente o rendimiento de TI.
Por lo tanto, el monitoreo de CSI tenderá a enfocarse en detectar excepciones y

resolución s. Por ejemplo, CSI no está tan interesado en si un incidente fue
resuelto, pero si se resolvió dentro del tiempo acordado y si el futuro
los incidentes se pueden prevenir.
Sin embargo, CSI no solo está interesado en las excepciones. Si un SLA se cumple constantemente
Con el tiempo, CSI también estará interesado en determinar si ese nivel de
El rendimiento se puede mantener a un costo menor o si es necesario actualizarlo.
a un nivel de rendimiento aún mejor. Por lo tanto, CSI también puede necesitar acceso a
informes de rendimiento periódicos.
Sin embargo, dado que es poco probable que CSI necesite o pueda hacer frente a la vasta
cantidades de datos que son producidos por todas las actividades de monitoreo , lo más probable es que
centrarse en un subconjunto específico de seguimiento en un momento dado. Esto podría ser
determinado por los aportes de la empresa o las mejoras a la tecnología.
Esto tiene dos implicaciones principales:
• El seguimiento de CSI cambiará con el tiempo. Pueden estar interesados en

monitorear el servicio de correo electrónico una cuarta parte y luego pasar a buscar recursos humanos
sistemas en el próximo trimestre.
• Esto significa que Service Operation y CSI necesitan construir un proceso que
les ayudará a ponerse de acuerdo sobre qué áreas necesitan ser monitoreadas y para qué
objetivo.
Página 166
5.2 Operaciones de TI
5.2.1 Puente de operaciones / administración de consola
Estos proporcionan un punto de coordinación central para gestionar varias clases de

eventos , detección de incidentes, gestión de actividades operativas de rutina e informes
sobre el estado o desempeño de los componentes tecnológicos .
La observación y el monitoreo de la infraestructura de TI pueden ocurrir desde un

consola: a la que se enrutan todos los eventos del sistema . Históricamente, esto implicó la
Monitoreo de la consola de operaciones maestras de uno o más mainframes, pero
en estos días es más probable que implique la supervisión de una granja de servidores , almacenamiento
dispositivos, componentes de red, aplicaciones , bases de datos o cualquier otro CI,
incluyendo cualquier mainframe restante, desde una única ubicación, conocida como el
Puente de operaciones .
Hay dos teorías sobre cómo se llamó así al Puente de Operaciones. Uno es
que se asemeja al puente de una gran nave automatizada (como naves espaciales
visto comúnmente en películas de ciencia ficción). La otra teoría es que el
Operations Bridge representa un vínculo entre los equipos de operaciones de TI y el
Mesa de ayuda tradicional . En algunas organizaciones esto significa que las funciones de
El control operativo y la mesa de ayuda se fusionaron en la mesa de servicio ,
que realizaba ambos conjuntos de funciones en una única ubicación física.
Independientemente de su nombre, un Puente de operaciones reunirá todos los

puntos críticos de observación dentro de la infraestructura de TI para que puedan ser
monitoreado y administrado desde una ubicación centralizada con un mínimo esfuerzo. los
Es probable que los dispositivos monitoreados estén físicamente dispersos y se puedan ubicar
en instalaciones informáticas centralizadas o dispersas dentro de la comunidad de usuarios , o
ambos.
El Puente de operaciones combinará muchas actividades, que pueden incluir Consola

Gestión, gestión de eventos, gestión de red de primera línea, programación de trabajos
y soporte fuera del horario de atención (que cubre la mesa de servicio y / o la segunda línea
grupos de apoyo si no funcionan 24 horas al día, 7 días a la semana). En algunas organizaciones, el Servicio
Desk es parte del Puente de Operaciones.
La ubicación física y el diseño del Puente de la Operación deben ser cuidadosamente

diseñado para brindar la accesibilidad y visibilidad correctas de todas las pantallas relevantes y
dispositivos al personal autorizado. Sin embargo, esta se convertirá en un área muy sensible.
donde el acceso controlado y la seguridad estricta serán esenciales.
Es posible que las organizaciones más pequeñas no tengan un puente de operaciones físico, pero habrá
Ciertamente seguirá siendo la necesidad de la gestión de la consola, generalmente combinada con otros
rol técnico s. Por ejemplo, un solo equipo de personal técnico gestionará la
red, servidores y aplicaciones. Parte de su función será supervisar la
Página 167
consolas para esos sistemas, a menudo utilizando consolas virtuales para que puedan
realizar la actividad desde cualquier lugar. Sin embargo, cabe señalar que estos
Las consolas virtuales son herramientas poderosas y, si se utilizan en ubicaciones inseguras o sobre
conexiones no seguras, podrían representar una amenaza de seguridad significativa .
5.2.2 Programación de trabajos
Las operaciones de TI realizarán rutinas, consultas o informes estándar que se le deleguen como
parte de la prestación de servicios; o como parte de la limpieza de rutina delegada por
Equipos de gestión técnica y de aplicaciones .
La programación de trabajos implica definir e iniciar paquetes de software de programación de trabajos

para ejecutar trabajo por lotes y en tiempo real. Normalmente, esto implicará diario, semanal, mensual,
programas anuales y ad hoc para satisfacer las necesidades comerciales.
Además del diseño inicial , o rediseño periódico, de los horarios, existen

Es probable que se realicen enmiendas o ajustes frecuentes durante qué trabajo
las dependencias deben identificarse y adaptarse. También habrá un papel
para jugar en la definición de alertas e informes de excepción que se utilizarán para
monitorear / verificar horarios de trabajo. La gestión del cambio juega un papel importante
en la evaluación y validación de cambios importantes en los horarios, así como en la creación
Procedimientos de cambio estándar para cambios más rutinarios.
Los parámetros de tiempo de ejecución y / o los archivos deben recibirse (o acelerarse si se retrasa)
y entrada, y todos los registros de tiempo de ejecución deben verificarse e identificarse cualquier falla .
Si ocurren fallas, entonces se deberán iniciar las repeticiones, bajo la guía de

las unidades de negocio apropiadas , a menudo con diferentes parámetros o modificadas
versión de datos / archivo s. Esto requerirá comunicaciones cuidadosas para garantizar
se utilizan parámetros y archivos.
Muchas organizaciones se enfrentan a un aumento de los programas por lotes durante la noche que
pueden, si sobrepasan la ranura del lote durante la noche, impactar negativamente en el
servicios diurnos, por lo que están buscando formas de utilizar la capacidad máxima durante la noche y
rendimiento , junto con la gestión de la capacidad . Aquí es donde Workload
Las técnicas de manejo pueden ser útiles, como:
• Reprogramación del trabajo para evitar contención en dispositivos específicos o en

tiempos específicos y mejorar el rendimiento general
• Migración de cargas de trabajo a plataformas / entornos alternativos para ganar
rendimiento y / o rendimiento mejorados (las capacidades de virtualización
esto es mucho más alcanzable al permitir la migración dinámica y automatizada)
• Momento cuidadoso y 'intercalación' de trabajos para obtener el máximo aprovechamiento de
recursos disponibles s.
Anécdota
Página 168
Una gran organización , que se enfrentó a problemas de uso / desbordamiento de lotes ,

identificó que, debido a la naturaleza humana, donde la gente buscaba ser 'ordenada', todos
los trabajos se estaban iniciando en la hora o en intervalos de 15 minutos durante la hora (es decir,
n en punto, 15 minutos, 15 y media, 15 minutos, etc.).
Reprogramando el trabajo para que comenzara tan pronto como terminaran otros trabajos, y
escalonando los tiempos de inicio de otros trabajos, pudo obtener reducciones significativas
en disputa y lograr un procesamiento general mucho más rápido, lo que resolvió su
problemas sin necesidad de actualizaciones.
La programación de trabajos se ha convertido en una actividad muy sofisticada , que incluye cualquier número
de variables, como dependencias sensibles al tiempo, críticas y no críticas,
balanceo de carga de trabajo, el fracaso y la nueva presentación, etc. Como resultado, la mayoría de operación s
confiar en las herramientas de programación de trabajos que permiten a las operaciones de TI programar trabajos para el
uso óptimo de la tecnología para lograr los objetivos de nivel de servicio .
La última generación de herramientas de programación permite programar un solo conjunto de herramientas

y automatizar las actividades técnicas y las actividades del proceso de gestión de servicios
(como la programación de cambios). Si bien esta es una buena oportunidad para mejorar
eficiencia , también representa un mayor punto único de falla . Organizaciones que utilizan
Este tipo de herramienta, por lo tanto, todavía utiliza soluciones puntuales como agentes y también como respaldo.
en caso de que falle el conjunto de herramientas principal.
5.2.3 Copia de seguridad y restauración
La copia de seguridad y la restauración son esencialmente un componente de una buena continuidad del servicio de TI
Planificación. Como tal, el diseño del servicio debe garantizar que haya una copia de seguridad sólida
Las estrategias para cada servicio y la Transición del servicio deben asegurar que estos sean
debidamente probado.
Además, los requisitos reglamentarios especifican que ciertos tipos de organización

(como servicios financieros o empresas que cotizan en bolsa) deben tener una copia de seguridad formal y
Restaurar la estrategia en su lugar y que esta estrategia se ejecute y audite. los
los requisitos exactos variarán de un país a otro y según el sector industrial. Esta
debe determinarse durante el diseño del servicio e incorporarse al servicio
funcionalidad y documentación.
El único punto de realizar copias de seguridad es que es posible que deban restaurarse en algún momento.
punto. Por esta razón, no es tan importante definir cómo respaldar un sistema como
es definir qué componentes están en riesgo y cómo mitigar de manera efectiva ese
riesgo.
Hay varias herramientas disponibles para realizar copias de seguridad y restaurar, pero vale la pena
observando que las características de las tecnologías de almacenamiento utilizadas para los datos comerciales se están
utilizado para copia de seguridad / restauración (por ejemplo, instantáneas). Por tanto, hay un aumento
Página 169
grado de integración entre las actividades de copia de seguridad y restauración y las de

Almacenamiento y archivo (consulte la sección 5.6).
5.2.3.1 Copia de seguridad
Los datos de la organización deben estar protegidos y esto incluirá una copia de seguridad.
(copia) y almacenamiento de datos en ubicaciones remotas donde se pueden proteger, y
utilizado en caso de que sea necesario restaurarlo debido a pérdida, corrupción o implementación de TI
Plan de continuidad del servicio s.
Se debe acordar una estrategia general de respaldo con la empresa, que cubra:
• ¿Qué datos se deben respaldar y la frecuencia e intervalos que se deben

usado.
• Cuántas generaciones de datos deben conservarse; esto puede variar según el
tipo de datos que se respaldan, o qué tipo de archivo (por ejemplo, archivo de datos o
ejecutable de la aplicación ).
• El tipo de copia de seguridad (completa, parcial, incremental) y puntos de control que se utilizarán.
• Las ubicaciones que se utilizarán para el almacenamiento (que probablemente incluyan recuperación de desastres
sitios) y horarios de rotación.
• Métodos de transporte (por ejemplo, transferencia de archivos a través de la red,
transporte en soporte magnético).
• Pruebas / verificaciones que se realizarán, como lecturas de prueba , restauraciones de prueba , verificación
sumas, etc.
• Objetivo de punto de recuperación . Esto describe el punto al cual los datos serán
restaurado después de la recuperación de un servicio de TI . Esto puede implicar la pérdida de datos. Para
ejemplo, un objetivo de punto de recuperación de un día puede estar respaldado por
copias de seguridad diarias y se pueden perder hasta 24 horas de datos. Punto de recuperación
Los objetivos de cada servicio de TI deben negociarse, acordarse y
documentado en OLA, SLA y UC.
• Objetivo de tiempo de recuperación . Esto describe el tiempo máximo permitido para
recuperación de un servicio de TI tras una interrupción. El nivel de servicio a ser
proporcionados pueden ser inferiores a los objetivos de nivel de servicio normales . Tiempo de recuperación
Los objetivos de cada servicio de TI deben negociarse, acordarse y
documentado en OLA, SLA y UC.
• Cómo verificar que las copias de seguridad funcionarán si es necesario restaurarlas d. Incluso si
no se generan códigos de error , puede haber varias razones por las que el
la copia de seguridad no se puede restaurar. Una buena copia de seguridad de estrategia y operación de s
Los procedimientos minimizarán el riesgo de que esto suceda. Procedimiento de copia de seguridad s
debe incluir un paso de verificación para garantizar que las copias de seguridad estén completas
y que funcionarán si se necesita una restauración. Donde cualquier falla de respaldo s
se detectan, se deben iniciar acciones de recuperación .
También es necesario adquirir y gestionar los medios necesarios (discos, cintas,

CD, etc.) que se utilizarán para realizar copias de seguridad, de modo que no haya escasez de suministro.
Página 170
Cuando se utilicen dispositivos automatizados, la precarga de los medios requeridos

ser necesario de antemano. Al cargar y limpiar medios devueltos desde fuera del sitio
almacenamiento es importante que exista un procedimiento para verificar que estos son los
las correctas. Esto evitará que la copia de seguridad más reciente se sobrescriba con errores
datos, y luego no tener datos válidos para restaurar. Después de realizar copias de seguridad exitosas
tomado, el medio debe retirarse para su almacenamiento.
El inicio real de las copias de seguridad puede automatizarse o llevarse a cabo desde el
Puente de operaciones .
Algunas organizaciones pueden utilizar personal de operaciones para realizar

transporte y almacenamiento de copias de seguridad hacia / desde ubicaciones remotas, donde en
otros casos esto puede ser entregado a otros grupos como seguridad interna
personal o contratistas externos.
Si las copias de seguridad se están automatizando o realizando de forma remota, entonces Event Monitoring
Se deben considerar las capacidades para que cualquier falla se pueda detectar temprano y
rectificado antes de que causen problemas . En tales casos, las operaciones de TI tienen la función de
jugar en la definición de alertas y rutas de escalamiento .
En todos los casos, el personal de operaciones de TI debe estar capacitado en respaldo (y restauración)
Procedimientos, que deben estar bien documentados en las operaciones de TI de la organización .
Manual de Procedimientos. Cualquier requisito u objetivo específico debe ser referenciado en
OLA o UC en su caso, mientras que cualquier usuario o cliente requisito s o
La actividad debe especificarse en el SLA correspondiente.
5.2.3.2 Restaurar
Una restauración se puede iniciar desde varias fuentes, que van desde un evento que
indica corrupción de datos, a través de una solicitud de servicio de un usuario o cliente
registrado en el Service Desk . Puede ser necesaria una restauración en el caso de:
• Datos corruptos
• Datos perdidos
• Recuperación ante desastres / situación de continuidad del servicio de TI
• Datos históricos necesarios para la investigación forense.
Los pasos a seguir incluirán:
• Ubicación de los datos / medios apropiados

• Transporte o traslado de regreso al lugar de recuperación física.
• Acuerdo sobre el punto de recuperación del punto de control y la ubicación específica para
los datos recuperados (disco, directorio, carpeta, etc.)
• Restauración real del archivo / datos (copia y retroceso / avance
necesario para llegar al punto de control acordado
Página 171
• Comprobación para garantizar la finalización satisfactoria de la restauración , con más

acción de recuperación si es necesario hasta que se haya logrado el éxito.
• Aprobación del usuario / cliente .
5.2.4 Impresión y salida
Muchos servicios consisten en generar y entregar información en forma impresa o

formulario electrónico. Garantizar que la información correcta llegue a las personas adecuadas, con
integridad , requiere control y gestión formales .
Las instalaciones y servicios de impresión (física) y de salida (electrónica) deben estar formalmente
administrado porque:
• A menudo representan el resultado tangible de un servicio . La habilidad para

medir que esta salida ha llegado al destino apropiado es
por lo tanto, muy importante (por ejemplo, comprobar si los archivos con
los datos de la transacción han llegado a un banco a través de un servicio FTP)
• La salida física y electrónica a menudo contiene información sensible o confidencial.
información. Es vital que se apliquen los niveles adecuados de seguridad a
tanto la generación como la entrega de esta salida.
Muchas organizaciones tendrán requisitos centralizados de impresión masiva que TI

Las operaciones deben manejar.
Además de la carga física y recarga de papel y la operación y

cuidado de las impresoras, pueden ser necesarias otras actividades, como:
• Acuerdo y configuración de notificación previa de tiradas grandes y alertas para

Evitar la impresión excesiva por trabajos de impresión fraudulentos.
• Control físico de material de oficina de alto valor, como cheques de la empresa o
certificados, etc.
• Gestión del almacenamiento físico y electrónico necesario para generar
La salida. En muchos casos, se esperará que TI proporcione archivos para la
materiales impresos y electrónicos
• Control de todo el material impreso para cumplir con la legislación de protección de datos.
y regulación, por ejemplo, HIPAA (Portabilidad y responsabilidad del seguro médico
Act) en los EE. UU. O FSA (Financial Services Authority) en el Reino Unido.
Cuando los servicios de impresión y salida se entregan directamente a los usuarios , es importante
que la responsabilidad del mantenimiento de las impresoras o dispositivos de almacenamiento es claramente
definido. Por ejemplo, la mayoría de los usuarios asumen que la limpieza y el mantenimiento de
las impresoras deben ser realizadas por TI. Si este no es el caso, esto debe ser claramente
establecido en el SLA.
Página 172
5.3 Gestión de mainframe
Los mainframes todavía se utilizan ampliamente y tienen sistemas bien establecidos y maduros.
práctica s. Los mainframes forman el componente central de muchos servicios y su
Por lo tanto, el rendimiento establecerá una línea de base para el rendimiento del servicio y el usuario o
expectativas del cliente, aunque es posible que nunca sepan que están utilizando el
Marco principal.
Las formas en que se organizan los equipos de gestión de mainframe son bastante
diverso. En algunas organizaciones, Mainframe Management es una
equipo especializado que gestiona todos los aspectos desde las operaciones diarias hasta
Ingeniería de sistemas . En otras organizaciones, las actividades son realizadas por
varios equipos o departamentos, con ingeniería y soporte de tercer nivel
proporcionado por un equipo y las operaciones diarias se combinan con el resto de TI
Operaciones (y muy probablemente gestionadas a través del Puente de Operaciones ).
Por lo general, es probable que se lleven a cabo las siguientes actividades:
• Mantenimiento y soporte del sistema operativo de mainframe

• soporte de tercer nivel de las incidencias relacionadas con el mainframe / problemáticas s
• Redacción de guiones laborales
• Programación del sistema
• Soporte de interfaz a hardware (H / W); organizar el mantenimiento, acordar
ranuras, identificación de fallas de H / W , enlace con ingeniería de H / W.
• Suministro de información y asistencia a la Gestión de la Capacidad para ayudar
lograr una óptima rendimiento , la utilización y el rendimiento de la
Marco principal.
Página 173
5.4 Gestión y soporte del servidor
Los servidores se utilizan en la mayoría de las organizaciones para proporcionar

servicios de aplicaciones de alojamiento o bases de datos, ejecución de servicios cliente / servidor,
Gestión de almacenamiento, impresión y archivos. La gestión exitosa de los servidores es
por lo tanto, es esencial para una operación de servicio exitosa .
Los procedimientos y actividades que debe realizar el (los) equipo (s) servidor
o departamento (s): es posible que se necesiten equipos separados donde diferentes tipos de servidores
se utilizan (UNIX, Wintel, etc.) - incluyen:
• Soporte del sistema operativo: Soporte y mantenimiento de los

sistema (s) operativo (s) y software de utilidad relacionado (por ejemplo, software de conmutación por error)
incluida la gestión de parches y la participación en la definición de copias de seguridad y
restaurar políticas.
• Gestión de licencias para todos los CI del servidor, especialmente los sistemas operativos,
utilidades y cualquier software de aplicación no administrado por la Aplicación
Equipos de gestión.
• Soporte de tercer nivel: soporte de tercer nivel para todos los servidores y / o servidores
incidentes relacionados con el sistema operativo, incluido el diagnóstico y la restauración
ocupaciones. Esto también incluirá el enlace con el soporte de hardware de terceros.
contratistas y / o fabricantes según sea necesario para escalar relacionados con el hardware
incidentes.
• Asesoramiento en adquisiciones: Asesoramiento y orientación al negocio sobre la
selección, dimensionamiento, adquisición y uso de servidores y utilidad relacionada
software para satisfacer las necesidades comerciales.
• Seguridad del sistema : Control y mantenimiento de los controles de acceso y
permisos dentro de los entornos de servidor relevantes , así como
sistema apropiado y medidas de seguridad física. Éstos incluyen
identificación y aplicación de parches de seguridad, Gestión de acceso
(ver sección 4.5) y detección de intrusos .
• Definición y gestión de servidores virtuales. Esto implica que cualquier
servidor que ha sido diseñado y construido alrededor de un estándar común puede
ser utilizado para procesar cargas de trabajo de una variedad de aplicaciones o usuarios .
Se requerirá que la administración del servidor establezca estos estándares y luego
asegurarse de que las cargas de trabajo estén equilibradas y distribuidas de forma adecuada. Ellos
también son responsables de poder rastrear qué carga de trabajo se está
procesado por qué servidor para que puedan hacer frente a las incidencias
efectivamente.
• Capacidad y desempeño: Brindar información y asistencia a
Gestión de la capacidad para ayudar a lograr un rendimiento , una utilización y una
rendimiento de los servidores disponibles. Esto se discute con más detalle en
Diseño de servicio , pero incluye orientación, instalación y
operación de software de virtualización para lograr una buena relación calidad-precio mediante
obteniendo los más altos niveles de rendimiento y utilización de la
número mínimo de servidores.
Página 174
• Otras actividades de rutina incluyen:

o Definición de compilaciones estándar para servidores como parte del aprovisionamiento
proceso . Esto se trata con más detalle en Diseño de servicios y
Transición de servicio
o Construir e instalar nuevos servidores como parte del mantenimiento continuo
o para la prestación de nuevos servicios. Esto se discute con más detalle.
en transición de servicio
o Configurar y administrar clusters, que tienen como objetivo construir
redundancia , mejorando el rendimiento del servicio y haciendo que el
infraestructura más fácil de administrar.
• Mantenimiento continuo. Por lo general, esto consiste en reemplazar servidores o
'cuchillas' en un programa continuo para garantizar que el equipo se reemplace antes
falla o se vuelve obsoleto. Esto da como resultado servidores que no solo están completamente
funcional, pero también capaz de soportar servicios en evolución
• Desmantelamiento y eliminación de equipos de servidor antiguos. Esto es a menudo
hecho en conjunto con las políticas ambientales de la organización para
disposición.
Página 175
5.5 Gestión de la red
Como la mayoría de los servicios de TI dependen de la conectividad, la gestión de la red será

esencial para prestar servicios y también para permitir que el personal de operaciones de servicio acceda
y gestionar los componentes clave del servicio .
La administración de la red tendrá la responsabilidad general de todos los

propias redes de área local (LAN), redes de área metropolitana (MAN) y amplia
Redes de área (WAN), y también será responsable de comunicarse con terceros.
proveedor de red s.
Su función incluirá las siguientes actividades:
• Planificación inicial e instalación de nuevas redes / componentes de red;

mantenimiento y actualizaciones de la infraestructura de red física. Este es
realizado a través del Diseño del Servicio y la Transición del Servicio.
• Soporte de tercer nivel para todas las actividades relacionadas con la red, incluida la investigación
de problemas de red (por ejemplo, hacer ping o rastrear la ruta y / o el uso de la red
herramientas de software de gestión, aunque debe tenerse en cuenta que hacer ping a un
servidor no significa necesariamente que el servicio esté disponible!) y enlace
con terceros según sea necesario. Esto también incluye la instalación y el uso
de herramientas 'sniffer', que analizan el tráfico de la red, para ayudar en incidentes y
resolución de problemas .
• Mantenimiento y soporte del sistema operativo de red y middleware.
software que incluye administración de parches, actualizaciones, etc.
• Monitoreo del tráfico de la red para identificar fallas o detectar posibles
problemas de rendimiento o cuellos de botella.
• Reconfigurar o reencaminar el tráfico para lograr un mejor rendimiento o
Equilibrio de la masa: definición de reglas para el equilibrado / enrutamiento dinámico.
• Seguridad de la red (en relación con la seguridad de la información de la organización
Management) incluida la gestión de firewall, derechos de acceso , contraseña
protección, etc.
• Asignar y administrar direcciones IP, sistemas de nombres de dominio (DNS -
que convierten el nombre de un servicio en su dirección IP asociada) y
Sistemas de protocolo de configuración dinámica de host (DHCP), que permiten
acceso y uso del DNS.
• Gestión de proveedores de servicios de Internet (ISP).
• Implementar, monitorear y mantener sistemas de detección de intrusiones en
en nombre de la Gestión de Seguridad de la Información . Ellos también serán responsables
para garantizar que no haya denegación de servicio a los usuarios legítimos del
la red.
• Actualizar la gestión de la configuración según sea necesario mediante la documentación de los elementos de configuración ,
estado , relaciones , etc.
Página 176
La administración de red también es a menudo responsable, a menudo junto con el escritorio.

Soporte, para problemas de conectividad remota como marcación, devolución de llamada y VPN
facilidades proporcionadas a trabajadores a domicilio, trabajadores remotos o proveedores .
Algunos equipos o departamentos de administración de redes también tendrán la responsabilidad

para voz / telefonía, incluida la provisión y soporte para centrales, líneas,
ACD, paquetes de software estadístico, etc. y para Voice over Internet Protocol
(VoIP) y de supervisión remota (RMON) sistema de s.
Al mismo tiempo, muchas organizaciones ven VoIP y telefonía como servicios especializados.
áreas y cuentan con equipos dedicados a la gestión de esta tecnología. Sus actividades
ser similar a los descritos anteriormente.
Nota sobre la gestión de VoIP como servicio
Muchas organizaciones han experimentado problemas de rendimiento y disponibilidad .

con sus soluciones de VoIP, a pesar de que parece haber más de
ancho de banda adecuado disponible. Esto da como resultado llamadas interrumpidas y sonido deficiente
calidad . Esto suele deberse a variaciones en la utilización del ancho de banda durante la
llamada , que a menudo es el resultado de la utilización de la red por otros usuarios,
aplicaciones u otra actividad web . Esto ha llevado a la diferenciación entre
medir el ancho de banda disponible para iniciar una llamada (ancho de banda de acceso al servicio -
o SAB) y la cantidad de ancho de banda que debe estar disponible continuamente durante
la llamada (Ancho de banda de utilización del servicio - o SUB). Se debe tener cuidado en
diferenciar entre estos al diseñar, gestionar o medir VoIP
servicios.
Página 177
5.6 Almacenamiento y archivo
Muchos servicios requieren el almacenamiento de datos durante un tiempo específico y también para ese
los datos estarán disponibles fuera de línea durante un período determinado después de que ya no se utilicen. Este es
a menudo debido a requisitos reglamentarios o legislativos , pero también porque la historia y
Los datos de auditoría son invaluables para una variedad de propósitos, incluidos marketing, productos
desarrollo , investigaciones forenses, etc.
Un equipo o departamento separado pueden ser necesarios para gestionar las organizaciones ‘s
tecnología de almacenamiento de datos como:
• Dispositivos de almacenamiento, como discos, controladores, cintas, etc.

• Almacenamiento conectado a la red (NAS), que es un almacenamiento conectado a una red.
y accesible por varios clientes s
• Redes de área de almacenamiento (SAN) diseñadas para conectar almacenamiento de computadora
dispositivos como controladores de matriz de discos y bibliotecas de cintas. Además de
dispositivos de almacenamiento, una SAN también requerirá la gestión de varios
componentes de red , como concentradores, cables, etc.
• Almacenamiento adjunto directo (DAS), que es un dispositivo de almacenamiento conectado directamente
a un servidor
• Almacenamiento direccionable de contenido (CAS), que es el almacenamiento que se basa en
recuperar información en función de su contenido en lugar de su ubicación. El foco
en este tipo de sistema es comprender la naturaleza de los datos y
información almacenada, en lugar de proporcionar ubicaciones de almacenamiento específicas.
Independientemente del tipo de sistemas de almacenamiento que se utilicen, Almacenamiento y

El archivo también requerirá la gestión de los componentes de la infraestructura.
como las políticas relacionadas con dónde se almacenan los datos, por cuánto tiempo, en qué forma y
quién puede acceder a él. Las responsabilidades específicas incluirán:
• Definición de políticas de almacenamiento de datos y procedimiento s

• Convenciones de nomenclatura de almacenamiento de archivos, jerarquía y decisiones de ubicación
• Diseño, dimensionamiento, selección, adquisición, configuración y operación de todos
infraestructura de almacenamiento de datos
• Mantenimiento y soporte para todas las utilidades y almacenamiento de datos de middleware
software
• Enlace con el (los) equipo (s) de gestión del ciclo de vida de la información o el gobierno
equipos para garantizar el cumplimiento de la libertad de información, protección de datos
y regulaciones de gobierno de TI
• Participación en la definición y acuerdo de la política de archivo .
• Limpieza de todas las instalaciones de almacenamiento de datos
• Archivar datos de acuerdo con las reglas y horarios definidos durante el Servicio
Diseño. Los equipos o departamentos de almacenamiento también proporcionarán información sobre
definición de estas normas y proporcionará informes sobre su eficacia como
entrada en el diseño futuro
Página 178
• Recuperación de datos archivados según sea necesario (por ejemplo, para fines de auditoría, para fines forenses).
evidencia, o para cumplir con cualquier otro requisito comercial)
• Soporte de tercera línea para incidentes relacionados con el almacenamiento y el archivo.
Página 179
5.7 Administración de la base de datos
La administración de la base de datos debe trabajar en estrecha colaboración con la administración de aplicaciones clave
equipos o departamentos - y en algunas organizaciones las funciones pueden ser
combinados o vinculados bajo una única estructura de gestión. Opciones organizativas
incluir:
• La administración de la base de datos que realiza cada aplicación

Equipos de gestión para todas las aplicaciones bajo su control.
• Un departamento dedicado, que gestiona todas las bases de datos, independientemente del tipo.
o aplicación
• Varios departamentos, cada uno gestionando un tipo de base de datos, independientemente de
de qué aplicación forman parte.
La administración de la base de datos trabaja para garantizar un rendimiento , seguridad y

funcionalidad de las bases de datos que administran. Los administradores de bases de datos normalmente
tener las siguientes responsabilidades:
• Creación y mantenimiento de estándares y políticas de bases de datos .

• Diseño , creación y prueba de bases de datos iniciales
• Gestión de la disponibilidad y el rendimiento de la base de datos ; resiliencia ,
dimensionamiento, capacidad volumétrica, etc.
• La resiliencia puede requerir la replicación de la base de datos, que sería la
responsabilidad de la administración de la base de datos
• Administración continua de los objetos de la base de datos: índices, tablas, vistas,
restricciones, instantáneas de secuencias y procedimientos almacenados ; bloqueos de página - a
lograr una utilización óptima
• La definición de desencadenantes que generarán eventos , que a su vez alertarán
administradores de bases de datos de posibles problemas de rendimiento o integridad con
la base de datos
• Realizar el mantenimiento de la base de datos: las tareas de rutina que garantizan que
las bases de datos funcionan de forma óptima y segura, por ejemplo , sintonización ,
indexación, etc.
• Seguimiento del uso; volúmenes de transacciones , tiempos de respuesta s, simultaneidad
niveles, etc.
• Generación de informes. Estos podrían ser informes basados en los datos del
base de datos, o informes relacionados con el desempeño e integridad de la
base de datos
• Identificación, notificación y gestión de problemas de seguridad de la base de datos;
pistas de auditoría y análisis forense
• Asistencia en el diseño de la estrategia de almacenamiento, archivo y copia de seguridad de la base de datos
• Asistencia en el diseño de alertas de bases de datos y gestión de eventos.
• Provisión de soporte de tercer nivel para todos los incidentes relacionados con la base de datos.
Página 180
5.8 Gestión de servicios de directorio
Un servicio de directorio es una aplicación de software especializada que gestiona

información sobre los recursos disponibles en una red y qué usuarios tienen
el acceso a los. Es la base para proporcionar acceso a esos recursos y para garantizar
que se detecte y evite el acceso no autorizado (consulte la sección 4.5 para obtener información detallada
información sobre Gestión de Accesos ).
Servicios de directorio ve cada recurso como un objeto del servidor de directorio y

le asigna un nombre. Cada nombre está vinculado a la dirección de red del recurso, por lo que
que los usuarios no tienen que memorizar direcciones confusas y complejas.
Los servicios de directorio se basan en el estándar X.500 de OSI y se utilizan comúnmente

protocolos como Directory Access Protocol (DAP) o Lightweight Directory
Protocolo de acceso (LDAP). LDAP se utiliza para admitir las credenciales de usuario para la aplicación.
inicio de sesión y, a menudo, incluye datos de usuarios / clientes internos y externos que
especialmente bueno para el registro de llamadas de extranet . Dado que LDAP es una herramienta operativa crítica ,
y generalmente se mantiene actualizado, también es una buena fuente de datos y verificación para
el CMS.
La administración de servicios de directorio se refiere al proceso que se utiliza para administrar

Directorio de Servicios. Sus actividades incluyen:
• Trabajar como parte del diseño del servicio y la transición del servicio para garantizar que
los nuevos servicios son accesibles y controlados cuando se implementan
• Ubicar recursos en una red (si aún no se han definido
durante el diseño del servicio)
• Hacer un seguimiento del estado de esos recursos y brindar la capacidad de administrar
esos recursos de forma remota
• La gestión de los derechos de específica de usuario s o grupos de usuarios para el acceso
recursos en una red
• Definir y mantener las convenciones de nomenclatura que se utilizarán para los recursos en
una red
• Garantizar la coherencia de los nombres y el control de acceso en diferentes redes.
en la organización
• Vincular diferentes servicios de directorio en toda la organización para formar un
Servicio de directorio distribuido, es decir, los usuarios solo verán un conjunto lógico de
recursos de la red. Esto se denomina Distribución de servicios de directorio.
• Supervisión de eventos en los servicios de directorio, como fallidos
intenta acceder a un recurso y tomar la acción apropiada cuando
requerido
• Mantener y actualizar las herramientas utilizadas para administrar los servicios de directorio.
Página 181
5.9 Soporte de escritorio
Dado que la mayoría de los usuarios acceden a los servicios de TI mediante computadoras de escritorio o portátiles, es clave
que estos sean compatibles para garantizar los niveles acordados de disponibilidad y
prestación de servicios.
Desktop Support tendrá la responsabilidad general de todos los

hardware, software y periféricos de computadoras de escritorio y portátiles. Específico
las responsabilidades incluirán:
• Políticas y procedimientos de escritorio , por ejemplo, políticas de licencia, uso de

computadoras portátiles o de escritorio para fines personales, bloqueo de USB, etc.
• Diseñar y acordar imágenes de escritorio estándar
• Mantenimiento del servicio de escritorio, incluida la implementación de versiones , actualizaciones,
parches y correcciones urgentes (junto con la Gestión de versiones (consulte
Publicación de transición del servicio para obtener más detalles)
• Diseño e implementación de archivado de escritorio / reconstrucción de la política (incluyendo
política relativa a cookies, favoritos, plantillas, datos personales, etc.)
• Soporte de tercer nivel para incidentes relacionados con el escritorio, incluidas las visitas al lado del escritorio
donde sea necesario
• Soporte para problemas de conectividad (junto con la administración de redes)
a trabajadores a domicilio, personal móvil, etc.
• Control de configuración y auditoría de todo el equipo de escritorio (en conjunto
con Gestión de la Configuración y Auditoría de TI).
Página 182
5.10 Gestión de middleware
Middleware es software que conecta o integra componentes de software a través de

aplicaciones y sistemas distribuidos o dispares . Middleware habilita
transferencia efectiva de datos entre aplicaciones y, por lo tanto, es clave para los servicios
que dependen de múltiples aplicaciones o fuentes de datos.
Actualmente se utiliza una variedad de tecnologías para respaldar programa a programa

comunicación, como intermediarios de solicitud de objetos, middleware orientado a mensajes,
llamadas a procedimientos remotos y servicios web punto a punto. Las nuevas tecnologías son
emergente todo el tiempo, por ejemplo, Enterprise Service Bus (ESB), que permite
programas, sistemas y servicios para comunicarse entre sí independientemente de
la arquitectura y el origen de las aplicaciones. Esto se utiliza especialmente en el
contexto de implementación de arquitecturas orientadas a servicios (SOA).
La gestión de middleware se puede realizar como parte de una aplicación

Función de gestión (donde se dedica a una aplicación específica) o como parte de
una función de Gestión Técnica (donde se ve como una extensión de la
Sistema operativo de una plataforma específica).
La funcionalidad proporcionada por el middleware incluye:
• Proporcionar mecanismos de transferencia de datos de diversas aplicaciones o datos.

fuentes
• Envío de trabajo a otra solicitud o procedimiento para su procesamiento.
• Transmitir datos o información a otros sistemas, como la obtención de datos.
para publicación en sitios web (por ejemplo, publicación de información sobre el estado del incidente )
• La liberación de los módulos de software actualizados a través distribuidas entorno s
• Recopilación y distribución de mensajes e instrucciones del sistema, para
ejemplo Eventos o scripts operativos que deben ejecutarse en forma remota
dispositivos
• Configuración de multidifusión con redes. La multidifusión es la entrega de información a un
grupo de destinos simultáneamente utilizando la ruta de entrega más eficiente
• Administrar tamaños de cola.
La gestión de middleware es el conjunto de actividades que se utilizan para gestionar

middleware. Éstos incluyen:
• Trabajar como parte del diseño y la transición del servicio para garantizar que el
se eligen las soluciones de middleware adecuadas y que pueden realizar
de manera óptima cuando se implementan
• Asegurar el correcto funcionamiento del middleware mediante la monitorización y
control
• Detectar y resolver incidentes relacionados con middleware
• Mantenimiento y actualización de middleware, incluida la concesión de licencias y la instalación
nueva versión s
Página 183
• Definir y mantener información sobre cómo se vinculan las aplicaciones .

a través de Middleware. Esto debería ser parte del CMS (ver Servicio
Publicación de transición ).
Página 184
5.11 Gestión de Internet / Web
Muchas organizaciones realizan gran parte de sus negocios a través de Internet y están
por lo tanto, depende en gran medida de la disponibilidad y el rendimiento de sus
sitios web. En tales casos, un equipo o departamento de soporte de Internet / Web independiente
será deseable y justificado.
Las responsabilidades de dicho equipo o departamento incluyen intranet y

Internet y es probable que incluyan:
• Definición de arquitecturas para Internet y servicios web.

• La especificación de estándares para el desarrollo y gestión de web-
aplicaciones basadas en contenido, sitios web y páginas web. Esto normalmente será
realizado durante el diseño del servicio
• Diseño, testeo, implementación y mantenimiento de sitios web. Esta voluntad
incluir la arquitectura de los sitios web y el mapeo del contenido para ser
Hecho disponible
• En muchas organizaciones, la gestión web incluirá la edición de contenido.
para ser publicado en la web
• Mantenimiento de todas las aplicaciones de gestión y desarrollo web
• Enlace y asesoramiento a equipos de contenido web dentro del negocio. Contenido
puede residir en aplicaciones o dispositivos de almacenamiento, lo que implica una estrecha relación
con Gestión de aplicaciones y otros equipos de Gestión técnica
• Enlace y gestión de proveedores de ISP, hosts, terceros
organizaciones de monitorización o virtualización, etc. En muchas organizaciones, el
Los ISP se gestionan como parte de la gestión de redes.
• Soporte de tercer nivel para incidentes relacionados con Internet / web
• Soporte para interfaces con sistemas heredados y back-end . Esto a menudo
significa trabajar con miembros del desarrollo de aplicaciones y
Equipos de gestión para garantizar el acceso seguro y la coherencia de
funcionalidad
• Seguimiento y gestión del rendimiento del sitio web e incluye:
pruebas de latidos del corazón, simulación de la experiencia del usuario , evaluación comparativa , bajo demanda
equilibrio de carga, virtualización
• Disponibilidad , resiliencia y seguridad del sitio web . Esto formará parte del
Gestión general de la seguridad de la información de la organización.
Página 185
5.12 Gestión de instalaciones y centros de datos

La gestión de instalaciones se refiere a la gestión del entorno físico de

Operaciones de TI , generalmente ubicadas en centros de datos o salas de computación. Este es un vasto
y área compleja y esta publicación proporcionará una descripción general de su función clave y
ocupaciones. En el Apéndice E se incluye una descripción más detallada.
En muchos aspectos, la gestión de instalaciones podría verse como una función en sí misma.
derecho. Sin embargo, debido a que esta publicación se centra en dónde se encuentran las operaciones de TI
alojado, cubrirá la gestión de instalaciones específicamente en lo que se refiere a la
gestión de centros de datos y como un subconjunto de la gestión de operaciones de TI
función.
Los principales componentes de la Gestión de Instalaciones son los siguientes:
• Gestión de edificios , que se refiere al mantenimiento y conservación de

los edificios que albergan al personal de TI y al centro de datos. Actividades tipicas
incluyen limpieza, eliminación de residuos, gestión de aparcamientos y control de acceso
• Alojamiento de equipos , que garantiza que se cumplan todos los requisitos especiales .
proporcionó el alojamiento físico de los equipos y los equipos que apoyan
ellos
• Power Management , que se refiere a la gestión del abastecimiento y
utilización de fuentes de energía que se utilizan para mantener la instalación funcional.
Esta definición de administración de energía tiene varias implicaciones, que
se analizan en el Apéndice E. Tenga en cuenta que la información sobre el uso de energía
es importante para planificar la capacidad tanto de nuevos servicios como de nuevos
edificios
• Sistemas de alerta y acondicionamiento ambiental , que incluyen
especificación , mantenimiento y monitoreo de sistemas tales como humo
sistemas de detección y extinción de incendios, agua, calefacción y refrigeración, etc.
• La seguridad se preocupa por el cumplimiento de toda la legislación, las normas y
políticas relativas a la seguridad de los empleados
• El control de acceso físico se refiere a garantizar que la instalación esté
accedido por personal autorizado y que cualquier acceso no autorizado es
detectado y gestionado. Esto se analiza con más detalle en el Apéndice F
• Envío y recepción se refiere a la gestión de todos los equipos,
muebles, correo, etc. que salga o ingrese al edificio. Asegura que solo
elementos apropiados están entrando o saliendo del edificio y que están
enrutado a la fiesta correcta
• Implicación en la Gestión de Contratos de los distintos proveedores y
proveedores de servicios involucrados en la instalación
• El mantenimiento se refiere al mantenimiento regular y programado de la instalación, así como
la detección y resolución de problemas con la instalación.
Nota importante sobre los centros de datos
Página 186
Los centros de datos son generalmente instalaciones especializadas y, aunque utilizan y se benefician
de disciplinas genéricas de Gestión de Instalaciones, necesitan adaptarlas. Para
ejemplo de diseño, calefacción y acondicionamiento, planificación de energía y muchos otros
todos los aspectos se gestionan de forma única en los centros de datos.
Esto significa que, aunque los centros de datos pueden ser instalaciones propiedad de un
organización , se gestionan mejor bajo la autoridad de Operaciones de TI ,
aunque puede haber una línea jerárquica funcional entre TI y el departamento
que gestiona otras instalaciones de la organización.
5.12.1 Estrategias del centro de datos
Administrar un centro de datos es mucho más que albergar un espacio abierto donde los técnicos
Los grupos instalan y gestionan equipos, utilizando sus propios enfoques y
procedimiento s. Requiere un conjunto integrado de procesos y procedimientos que involucran
todos los grupos de TI en cada etapa del ciclo de vida de ITSM . Las operaciones del centro de datos son
gobernado por decisiones estratégicas y de diseño para la gestión y el control y están
ejecutado por operadores. Esto requiere que se implementen una serie de factores clave:
• Automatización de centros de datos. Especializados automatización del sistema s que reducen

la necesidad de operadores manuales y que monitorean y rastrean el estado de
la instalación y todas las operaciones de TI en todo momento
• Gestión basada en políticas , donde las reglas de automatización y recursos
La asignación se gestiona mediante políticas, en lugar de tener que pasar por
procedimientos de cambio complejos cada vez que el procesamiento se mueve de una
recurso a otro
• Servicios en tiempo real las 24 horas del día, los 7 días de la semana
• Estandarización de equipos. Esto proporciona una mayor facilidad de
gestión, niveles más consistentes de desempeño y un medio de
proporcionando múltiples servicios a través de tecnología similar. Estandarización también
reduce la variedad de conocimientos técnicos necesarios para gestionar equipos
en el Data Center y para brindar servicios
• SOA , donde los componentes del servicio se pueden reutilizar, intercambiar y
reemplazado muy rápidamente y sin impacto en el negocio. Esto lo hará
posible que el centro de datos sea altamente receptivo en el cambio de reuniones
demandas comerciales sin tener que pasar por largos e involucrados
ingeniería y re-arquitectura
• Virtualización. Esto significa que los servicios de TI se prestan utilizando un
equipo cambiante, orientado a satisfacer la demanda actual. Por ejemplo,
una aplicación puede ejecutarse en un dispositivo dedicado junto con su base de datos
durante tiempos de alta demanda, pero se cambió a un dispositivo compartido con su base de datos
en un dispositivo remoto durante las horas pico, todo automatizado y automático.
Esto significará ahorros de costos aún mayores, ya que cualquier equipo puede ser
utilizado en cualquier momento, sin ninguna intervención humana, excepto para realizar
mantenimiento y reemplazo de equipos defectuosos. La infraestructura de TI es más
resistente ya que cualquier componente está respaldado por cualquier número de similares
Página 187
componentes, cualquiera de los cuales podría hacerse cargo de la carga de trabajo de un componente fallido
automáticamente.
Los equipos y sistemas de supervisión , control y gestión remotos

ser esencial para gestionar un entorno virtualizado , ya que muchos servicios
no estar vinculado a ningún equipo específico.
• Unificados del sistema de gestión de s se han vuelto más importantes como los servicios
se ejecutan en múltiples ubicaciones y tecnologías. Hoy es importante
Definir qué acciones deben tomarse y qué sistemas realizarán esas acciones.
acción. Esto significa invertir en soluciones que permitan a la infraestructura
gerentes para simplemente especificar qué resultado se requiere, y permitir que el
sistema de gestión para calcular la mejor combinación de herramientas y
acciones para lograr el resultado.
Página 188
5.13 Gestión de la seguridad de la información y operación del servicio
La gestión de la seguridad de la información como proceso está cubierta en el servicio ITIL.

Publicación de diseño . La gestión de la seguridad de la información tiene la responsabilidad general
para establecer políticas, estándares y procedimientos para asegurar la protección de la
organización ‘s activo s, datos, información y servicios de TI s. Equipos de operación de servicio
desempeñar un papel en la ejecución de estas políticas, estándares y procedimientos y funcionará
estrechamente con los equipos o departamentos responsables de la seguridad de la información
Administración.
Los equipos de operaciones de servicio no pueden apropiarse de la seguridad de la información
Gestión, ya que esto representaría un conflicto. Tiene que haber segregación
de roles entre los grupos que definen y gestionan el proceso y los grupos
ejecutar actividades específicas como parte de la operación en curso . Esto ayudará a proteger
contra violaciones a las medidas de seguridad , ya que ninguna persona debería haber
control sobre dos o más fases de una transacción u operación. Información
La Gerencia de Seguridad debe asignar responsabilidades para asegurar una verificación cruzada de
deberes.
A continuación, se describe el papel de los equipos de Operaciones de servicio.
5.13.1 Vigilancia y denuncia
Esto implicará que el personal de la Operación realice actividades policiales específicas, como la
comprobación de diarios del sistema, registros, alertas de eventos / supervisión , etc., detección de intrusiones
y / o informes de brechas de seguridad reales o potenciales. Esto se hace en
junto con la Gestión de Seguridad de la Información para proporcionar una verificación y
sistema de equilibrio para garantizar la detección y gestión eficaces de la seguridad
cuestiones.
El personal de operaciones de servicio suele ser el primero en detectar eventos de seguridad y está en el mejor
posición para poder cerrar y / o eliminar el acceso a comprometidos
sistemas.
Se necesitará especial atención en el caso de organizaciones de terceros que

requieren acceso físico a la organización. El personal de operación del servicio puede ser
necesario para acompañar a los visitantes a áreas sensibles y / o controlar su acceso.
También pueden tener un papel que desempeñar en el control del acceso a la red a terceros,
tales como mantenedores de hardware que marcan con fines de diagnóstico, etc.
5.13.2 Asistencia técnica
Es posible que deba proporcionarse algún soporte técnico al personal de seguridad de TI para ayudar
investigar incidentes de seguridad y ayudar en la producción de informes o en la recopilación
pruebas forenses para su uso en acciones disciplinarias o enjuiciamientos penales.
Página 189
También puede ser necesario el asesoramiento y la asistencia técnica con respecto a la seguridad potencial.
mejoras (por ejemplo, configuración de firewalls apropiados o controles de acceso / contraseña).
El uso de información de gestión de eventos, incidentes , problemas y configuración.

se puede confiar en él para proporcionar cronologías precisas de las cuestiones relacionadas con la seguridad.
investigaciones.
5.13.3 Control de seguridad operacional
Por razones operativas , el personal técnico a menudo necesitará tener acceso privilegiado
a áreas técnicas clave (por ejemplo , contraseñas del sistema raíz , acceso físico a datos
Centros o salas de comunicaciones, etc.). Por tanto, es fundamental que
Se mantienen controles y pistas de auditoría de todas esas actividades privilegiadas para disuadir y
detectar cualquier evento de seguridad s.
Los controles físicos deben estar en su lugar para todas las áreas seguras con registro de entrada y salida de todas
personal. Cuando el personal de terceros o los visitantes necesiten acceso, puede ser Operación del servicio
personal que es responsable de escoltar y gestionar el movimiento de tales
personal.
En el caso de acceso a sistemas privilegiados, esto debe restringirse solo a aquellos

personas cuya necesidad de acceder al sistema ha sido verificada y retirada
inmediatamente cuando esa necesidad ya no exista. Se debe mantener una pista de auditoría de
quién ha tenido acceso y cuándo, y de todas las actividades realizadas utilizando esos
niveles de acceso.
5.13.4 Detección e investigación de antecedentes
Todo el personal de operaciones de servicio debe ser examinado y examinado a un nivel de seguridad.
apropiado para la organización en cuestión.
Los proveedores y los contratistas externos también deben ser examinados y examinados, tanto
las organizaciones y el personal específico involucrado. Muchas organizaciones tienen
Comenzó a usar verificaciones de antecedentes de la policía o agencias gubernamentales, especialmente cuando
los contratistas trabajarán con sistemas clasificados. Donde sea necesario,
Se deben acordar acuerdos de confidencialidad y no divulgación apropiados .
5.13.5 Formación y sensibilización
Todo el personal de Operación del Servicio debe recibir capacitación y capacitación periódica y continua.
conocimiento de la política y los procedimientos de seguridad de la organización . Esto debería
incluir detalles de las medidas disciplinarias vigentes. Además, cualquier seguridad
Los requisitos deben especificarse en el contrato de trabajo del empleado.
Página 190
5.13.6 Políticas y procedimientos documentados
Los procedimientos documentados de la operación del servicio deben incluir toda la información relevante
relacionados con cuestiones de seguridad: extraído de la seguridad general de la organización
documento de política s. Se debe considerar el uso de manuales para
ayudar a hacer llegar los mensajes de seguridad a todo el personal pertinente.
Página 191
5.14 Mejora de las actividades operativas
Todo el personal de operaciones de servicio debe estar constantemente buscando áreas en las que
Se pueden realizar mejoras en los procesos para brindar una mayor calidad de servicio de TI y / o
realizado de una manera más rentable. Esto puede incluir algunos de los siguientes
ocupaciones.
5.14.1 Automatización de tareas manuales
Cualquier tarea que deba llevarse a cabo manualmente, especialmente aquellas que deben
repetirse con regularidad, es probable que consuman más tiempo, sean costosos y generen errores
propensos que los que se pueden sistematizar y automatizar. Todas las tareas deben ser
examinado para la automatización potencial para reducir el esfuerzo y los costos y para minimizar
posibles errores.
Se debe hacer un juicio sobre los costos de la automatización y los probables beneficios.
eso ocurrirá.
5.14.2 Revisión de actividades o procedimientos improvisados
Debido a la naturaleza pragmática de la operación del servicio , a veces puede surgir

que se introducen actividades o procesos improvisados para abordar a corto plazo
conveniencias operativas . Existe el peligro de que tales prácticas puedan continuar.
y convertirse en la "norma", lo que conduce a ineficiencias continuas. Donde cualquier improvisación
deben introducirse actividades o procedimientos , es importante que estos sean
revisado tan pronto como se supere la conveniencia inmediata - y ya sea
prescindido o reemplazado por procesos eficientes acordados a largo plazo.
5.14.3 Auditorías operativas
Se deben realizar auditorías periódicas de todos los procesos de operación del servicio para garantizar
que están funcionando satisfactoriamente.
5.14.4 Uso de la gestión de incidentes y problemas
Problema y Gestión de Incidencias proporcionan una rica fuente de operativa

oportunidades de mejora. Estos procesos se analizan en detalle en el Capítulo 4.
de esta publicación.
5.14.5 Comunicación
No hace falta decir que una buena comunicación sobre el cambio

Los requisitos , la tecnología y los procesos darán como resultado una mejora en el Servicio.
Operación. Sin embargo, a menudo se descuida la comunicación. Operación de servicio
Página 192
La mejora depende de la comunicación formal y regular entre equipos.

responsable del diseño , soporte y operación de los servicios.
5.14.6 Educación y formación
Los equipos de operaciones de servicio deben comprender la importancia de lo que hacen en un

Diariamente. Se requiere educación para asegurar que el personal entienda qué negocios
las funciones o los servicios están respaldados por sus actividades. Esto alentará a una mayor
cuidado y atención a los detalles y también ayudará a los equipos de operación de servicio a mejorar
identificar las prioridades comerciales.
Los programas de capacitación deben garantizar que todo el personal tenga las habilidades adecuadas para
la tecnología o las aplicaciones que están administrando. La formación siempre debe ser
proporcionado cuando se introduce nueva tecnología, o cuando la tecnología existente es
cambió.
Página 193
6 Organización para la operación del servicio
6.1 Funciones
Una función es un concepto lógico que se refiere a las personas y medidas automatizadas
que ejecutan un proceso definido , una actividad o una combinación de procesos o
ocupaciones. En organizaciones más grandes, una función puede ser dividida y realizada por
varios departamentos, equipos y grupos, o puede estar incorporado dentro de un solo
unidad organizacional.
Figura 6.1 Funciones de operación del servicio
Página 194
Las funciones de Operación del Servicio que se muestran en la Figura 6.1 son necesarias para administrar la
Entorno operativo de TI de 'estado estable' . Estas son funciones lógicas y no
necesariamente tiene que ser realizado por una estructura organizativa equivalente. Esta
significa que la gestión técnica y de aplicaciones se puede organizar en cualquier
combinación y en cualquier número de departamentos. Las agrupaciones de segundo nivel en
La Figura 6.1 son ejemplos de grupos típicos de actividades realizadas por técnicos
Gestión (ver Capítulo 5) y no son una estructura organizativa sugerida .
La siguiente es una descripción general de las funciones de Operación del servicio en la Figura 6.1:
• El Service Desk es el punto de contacto principal para los usuarios cuando hay un
interrupción del servicio , para solicitudes de servicio o incluso para algunas categorías de
Solicitud de cambio . El Service Desk proporciona un punto de comunicación.
a los usuarios y un punto de coordinación para varios grupos de TI y
Procesos. Para permitirles realizar estas acciones de manera eficaz,
La mesa de servicio suele estar separada de las demás operaciones de servicio.
funciones. En algunos casos, por ejemplo, cuando se ofrece soporte técnico detallado
a los usuarios en la primera llamada , puede ser necesario para aplicaciones técnicas o
El personal de gestión estará en el Service Desk. Esto no significa que el
Service Desk pasa a formar parte de la función de Gestión técnica. De hecho,
mientras están en el Service Desk, dejan de ser parte del
Funciones de Gestión Técnica o Gestión de Aplicaciones y convertirse
parte de la Mesa de Servicio, aunque solo sea temporalmente.
• Gestión técnica proporciona conocimientos técnicos detallados y recursos s
necesarios para respaldar el funcionamiento continuo de la infraestructura de TI . Técnico
La administración también juega un papel importante en el diseño , prueba y lanzamiento.
y mejora de los servicios de TI . En organizaciones pequeñas, es posible
administrar esta experiencia en un solo departamento, pero las organizaciones más grandes son
normalmente se divide en varios departamentos técnicamente especializados (ver
más adelante en este capítulo). En muchas organizaciones, la Gerencia Técnica
Los departamentos también son responsables del funcionamiento diario de un subconjunto de
Esa infraestructura. La figura 6.1 muestra que, aunque forman parte de un
Departamento de Dirección Técnica, el personal que realiza estas actividades es
lógicamente parte de la función de gestión de operaciones de TI.
• La Gestión de Operaciones de TI es la función responsable de la
actividades operativas necesarias para gestionar la infraestructura de TI. Esto esta hecho
de acuerdo con los Estándares de Desempeño definidos durante el Diseño del Servicio . En
algunas organizaciones es un departamento único y centralizado, mientras que en otras
Algunas actividades y el personal están centralizados y algunos son proporcionados por
Departamentos distribuidos o especializados. Esto se ilustra en la Figura 6.1 por
la superposición de la gestión técnica y de aplicaciones
funciones. La gestión de operaciones de TI tiene dos funciones que son únicas
y que son generalmente estructuras organizativas formales. Estos son:
• Control de operaciones de TI , que generalmente está integrado por turnos de
operadores y que garantiza que las tareas operativas de rutina se
llevado a cabo. El control de operaciones de TI también proporcionará
Página 195
actividades de seguimiento y control , por lo general utilizando una operación

Centro de operaciones de puente o red.
• La gestión de instalaciones se refiere a la gestión de la TI física.
entorno , normalmente centros de datos o salas de informática. En muchos
La gestión técnica y de aplicaciones de las organizaciones
ubicado con Operaciones de TI en grandes Centros de Datos. En algunos
organizaciones muchos componentes físicos de la infraestructura de TI
han sido subcontratados y la Gestión de Instalaciones puede incluir el
gestión del contrato de subcontratación s.
• Administración de aplicaciones es responsable de la gestión de aplicaciones s
a lo largo de su ciclo de vida . La función de gestión de aplicaciones admite
y mantiene aplicaciones operativas y también juega un papel importante en
el diseño , testeo y mejora de aplicaciones que forman parte de TI
servicio s. La gestión de aplicaciones generalmente se divide en departamentos
basado en el portafolio de aplicaciones de la organización (vea los ejemplos en
Figura 6.1), lo que permite una especialización más fácil y un apoyo más enfocado.
En muchas organizaciones, los departamentos de gestión de aplicaciones tienen personal
que realizan operaciones diarias para esas aplicaciones. Como con Technical
Gerencia , este personal lógicamente forma parte de las Operaciones de TI.
Función de gestión .
Nota especial sobre la gestión de la seguridad de la información
Aunque la mayoría estaría de acuerdo en que la gestión de la seguridad de la información es una función ,
es altamente especializado y abarca varias fases del ciclo de vida. Tambien es
responsable de la supervisión de muchas actividades dentro de todas las operaciones de servicio
funciones. Para obtener una descripción más detallada de la gestión de la seguridad de la información,
Consulte la publicación de Diseño de servicios y la sección 5.13 de este
publicación.
6.1.1 Funciones y actividades
El capítulo 5 de esta publicación presentó una serie de operaciones de servicio comunes

ocupaciones. Debido al carácter técnico y especialización de estas actividades, la
Los equipos, grupos o departamentos que los realizan a menudo reciben nombres que
corresponden a las actividades particulares. Por ejemplo, la gestión de red podría
ser realizado por un 'Departamento de Gestión de Red'. Esto, sin embargo, no es
significa una regla. Hay una serie de opciones disponibles en el mapeo de actividades a un
equipo o departamento, por ejemplo:
• Una actividad podría ser realizada por varios equipos o departamentos, por ejemplo, si
una organización tiene cinco departamentos principales de soporte de aplicaciones, cada uno
admitiendo un conjunto diferente de aplicaciones, cada uno de estos departamentos podría
realizar la administración de la base de datos para 'sus' aplicaciones
Página 196
• Un departamento podría realizar varias actividades, por ejemplo, la Red.

El Departamento de Gestión podría ser responsable de la gestión de la red,
Administración de servicios de directorio y administración de servidores
• Una actividad puede ser realizada por grupos, por ejemplo, la Administración de seguridad puede
ser realizado por cualquier persona con la responsabilidad de gestionar un
aplicación, servidor, middleware o escritorio.
Estas decisiones organizativas están influenciadas por una serie de factores, como:
• El tamaño y la ubicación de la organización. Más pequeño, menos distribuido

Las organizaciones tenderán a combinar estas funciones, mientras que las grandes
Las organizaciones descentralizadas pueden tener varios equipos o departamentos.
realizar la misma actividad (por ejemplo, por región).
• La complejidad de la tecnología utilizada en la organización . Cuanto mayor sea el
número de tecnologías diferentes utilizadas, es más probable que haya
varios equipos diferentes, cada uno haciendo algo similar, pero en un diferente
contexto (por ejemplo, UNIX Server Management y Windows Server
Administración).
• La disponibilidad de habilidades. Donde las habilidades técnicas son escasas, es común que
organizaciones para utilizar generalistas para realizar múltiples grupos de actividades -
aunque, en algunos casos, las consideraciones de seguridad lo hacen muy difícil.
Por ejemplo, una organización que trabaja en proyectos clasificados o secretos puede
tener que contratar recursos costosos y especializados , incluso cuando eso signifique
reubicarlos o contratarlos a través de proveedores autorizados en seguridad .
• La cultura de la organización. Algunas organizaciones prefieren trabajar en
entornos altamente especializados , mientras que otros tienden a preferir la flexibilidad
del personal generalista.
• La situación financiera de la organización determinará cuántas personas,
con qué tipo de habilidad se pueden emplear y cómo se organizarán.
Como resultado de estos factores, es imposible que esta publicación prescriba una
estructura organizativa adecuada que se adapte a cada situación, sin embargo, el
Las siguientes secciones enumeran las actividades requeridas bajo los grupos funcionales más
probablemente esté involucrado en su operación . Tenga en cuenta que esto no significa que
todas las organizaciones deben utilizar estas divisiones. Las organizaciones más pequeñas tenderán a
combinar estas actividades en departamentos individuales, o incluso en individuos, si son
incluso necesario en absoluto.
Nota especial sobre subcontratación
Es probable que estas consideraciones organizativas sean más relevantes para la TI interna
Organizaciones. La situación se vuelve aún más compleja cuando algunos o todos los
se subcontrata una actividad o función particular . Primeras oportunidades de subcontratación
han sido la Mesa de Servicio y Operaciones de Red. Esto se cubrirá en
más detalles en la Guía complementaria de ITIL , pero algunos de los puntos clave para
recuerda son:
Página 197
• Independientemente de quién esté realizando la actividad , la empresa que contrate el

El subcontratista sigue siendo responsable de garantizar que se realice a un
estándar que apoyará la entrega de servicios a sus clientes y
usuario s.
• Outsourcing para resolver los problemas de una organización o como alternativa a
Los buenos procesos de Gestión de servicios rara vez funcionan. Los mejores resultados son
obtenido si están en su lugar antes de la subcontratación.
• La subcontratación funciona mejor cuando hay una participación activa de ambos
Organizaciones. Si el personal y los gerentes de la organización del cliente
desconectarse, es poco probable que el subcontratista tenga éxito, simplemente porque
nadie entiende la organización mejor que las personas que trabajan
allí.
• El subcontratista no debe determinar sus productos o cómo se
Medido. Estos se determinan al comprender el negocio
los requisitos de los usuarios y clientes y garantizar que se puedan cumplir
por las capacidades del subcontratista.
• Aunque los servicios del subcontratista se convierten en una parte integral del
organización , siguen siendo una organización de terceros, con un conjunto diferente de
objetivos , políticas y prácticas comerciales s. Los estándares de seguridad deben ser
y ambas partes deben comprender claramente sus respectivos roles y
contribuciones.
Página 198
6.2 Mesa de servicio
Un Service Desk es una unidad funcional compuesta por un número dedicado de personal
Responsable de lidiar con una variedad de eventos de servicio , a menudo realizados por teléfono.
llamadas, interfaz web o eventos de infraestructura informados automáticamente.
El Service Desk es una parte de vital importancia del departamento de TI de una organización.
y debe ser el único punto de contacto para los usuarios de TI en el día a día.
y se encargará de todos los incidentes y solicitudes de servicio , por lo general utilizando especialistas
herramientas de software para registrar y gestionar todos estos eventos.
El valor de un Service Desk eficaz no debe subestimarse: una buena

Service Desk a menudo puede compensar las deficiencias en otros lugares de la TI.
organización; pero una mesa de servicio deficiente (o la falta de una mesa de servicio) puede dar una
¡mala impresión de una organización de TI por lo demás muy eficaz!
Por lo tanto, es muy importante que el calibre correcto del personal utilizado en el Servicio
Escritorio y que los gerentes de TI hagan todo lo posible para que el escritorio sea un lugar atractivo para
trabajar para mejorar la retención del personal.
La naturaleza, el tipo, el tamaño y la ubicación exactos de un Service Desk variarán, según

según el tipo de negocio, el número de usuarios, la geografía, la complejidad de las llamadas,
alcance de los servicios y muchos otros factores.
De acuerdo con los requisitos del cliente y del negocio , el personal senior de la organización de TI
los gerentes deben decidir la naturaleza exacta de su Service Desk requerido (y
si debe ser interno o subcontratado a un tercero ) como parte de su
Estrategia de ITSM (consulte la publicación Estrategia de servicio ) y luego la planificación posterior
debe hacerse para prepararse y luego implementar el Service Desk apropiado
función (ya sea al implementar una nueva función, o más probablemente en estos días
al realizar las modificaciones necesarias a una función existente, consulte Servicio
Publicaciones de Transición de Diseño y Servicio ).
6.2.1 Justificación y rol del Service Desk
Hoy en día se necesita muy poca justificación para un Service Desk, ya que muchas organizaciones
se han convencido de que este es, con mucho, el mejor enfoque para tratar con
problemas de soporte de TI de línea. Uno solo necesita hacer la pregunta '¿Cuál es la alternativa?'
para presentar un caso convincente para el concepto de Service Desk. Donde mas lejos
se necesita una justificación, se deben considerar los siguientes beneficios:
• Mejor servicio al cliente, percepción y satisfacción

• Mayor accesibilidad a través de un único punto de contacto, comunicación.
e información
Página 199
• Mejor calidad y respuesta más rápida de las solicitudes de clientes o usuarios

• Mejora del trabajo en equipo y la comunicación.
• Enfoque mejorado y un enfoque proactivo para la prestación de servicios
• Un impacto empresarial negativo reducido
• Infraestructura y control mejor administrados
• Uso mejorado de los recursos de soporte de TI y mayor productividad de
personal de negocios
• Información de gestión más significativa para el apoyo a la toma de decisiones
• Es una práctica común que el Service Desk proporcione puestos de 'nivel de entrada'
para el personal de ITSM. Trabajar en la mesa de servicio es una excelente base para
cualquier persona que desee seguir una carrera en Gestión de servicios . Sin embargo,
esto también podría presentar desafíos para las personas que no entienden la
negocio o tecnología. Los usuarios que llamen al Service Desk deberían poder
hablar con alguien que pueda atender sus necesidades y el servicio de atención al cliente
Los analistas no deberían agotarse en menos de un año debido a
estrés. Se debe tener cuidado de seleccionar personas adecuadamente capacitadas con
una buena comprensión del negocio y para proporcionar la formación adecuada -
evitando así la reducción de los niveles de apoyo debido a la falta de conocimiento
en la primera línea.
6.2.2 Objetivos de la mesa de servicio
El objetivo principal del Service Desk es restaurar el ' servicio normal ' al
usuarios lo más rápido posible. En este contexto, la ' restauración del servicio ' se entiende en el
sentido más amplio posible. Si bien esto podría implicar la reparación de una falla técnica , podría
igualmente implica el cumplimiento de una solicitud de servicio o la respuesta a una consulta, cualquier cosa que sea
necesario para permitir que los usuarios vuelvan a trabajar satisfactoriamente.
Las responsabilidades específicas incluirán:
• Registrar todos los detalles relevantes de la solicitud de servicio / incidente , asignar

códigos de categorización y priorización
• Proporcionar investigación y diagnóstico de primera línea
• Resolviendo aquellos incidentes / solicitudes de servicio que puedan
• Escalar incidentes / solicitudes de servicio que no pueden resolver dentro
escalas de tiempo acordadas
• Mantener a los usuarios informados sobre el progreso
• Cerrar todas las incidencias resueltas, solicitudes y otras llamadas
• Realización de encuestas / devoluciones de llamadas de satisfacción del cliente / usuario según lo acordado
• Comunicación con los usuarios: manteniéndolos informados del progreso del incidente .
notificándoles de cambios inminentes o cortes acordados, etc.
• Actualización del CMS bajo la dirección y aprobación de Configuración
Gestión si así se acuerda.
Página 200
Nota: estas actividades se explican y se establecen en contexto con el incidente más completo.
Proceso de Gestión y Cumplimiento de Solicitudes en las secciones 4.2 y 4.3
respectivamente.
6.2.3 Estructura organizativa de la mesa de servicio
Hay muchas formas de estructurar los Service Desk y ubicarlos, y la

La solución correcta variará para diferentes organizaciones. Las opciones principales son
se detalla a continuación, pero en realidad una organización puede necesitar implementar una estructura
que combina varias de estas opciones para satisfacer plenamente el negocio
necesidades:
6.2.3.1 Mesa de servicio local
Aquí es donde un escritorio se ubica dentro o físicamente cerca del usuario

comunidad a la que sirve. Esto a menudo ayuda a la comunicación y proporciona una
presencia, que a algunos usuarios les gusta, pero que a menudo puede ser ineficaz y costoso para
recurso ya que el personal está ocupado esperando para hacer frente a incidentes cuando el volumen y
La tasa de llegada de llamadas puede no justificar esto.
Sin embargo, puede haber algunas razones válidas para mantener un escritorio local, incluso
donde los volúmenes de llamadas por sí solos no justifican esto. Las razones pueden incluir:
• Diferencias lingüísticas y culturales o políticas

• Diferentes zonas horarias
• Grupos de usuarios especializados
• La existencia de servicios personalizados o especializados que requieran especialista
conocimiento
• VIP / criticidad de estado de los usuarios.
Página 201
Figura 6.2 Mesa de servicio local
6.2.3.2 Mesa de servicio centralizada
Es posible reducir el número de Service Desk fusionándolos en un

ubicación única (o en un número menor de ubicaciones) atrayendo al personal a
una o más estructuras de Service Desk centralizadas. Esto puede ser más eficiente y
rentable, permitiendo que menos personal en general se ocupe de un mayor volumen de llamadas,
y también puede conducir a niveles más altos de habilidad a través de una gran familiarización a través de más
ocurrencia frecuente de eventos s. Puede que sea necesario mantener alguna forma
de 'presencia local' para manejar los requisitos de apoyo físico , pero dicho personal puede ser
controlado y desplegado desde el escritorio central.
Página 202
Figura 6.3 Mesa de servicio centralizada
6.2.3.3 Mesa de servicio virtual
Mediante el uso de tecnología, en particular Internet, y el uso de

herramientas de soporte, es posible dar la impresión de un Servicio único y centralizado
Escritorio cuando en realidad el personal puede estar disperso o ubicado en cualquier número o tipo.
de ubicaciones geográficas o estructurales. Esto trae la opción de 'hogar
trabajo ', grupo de apoyo secundario , deslocalización o subcontratación , o cualquier
combinación necesaria para satisfacer la demanda de los usuarios . Sin embargo, es importante tener en cuenta
que se necesitan salvaguardias en todas estas circunstancias para garantizar la coherencia
y uniformidad en la calidad del servicio y en términos culturales.
Página 203
Figura 6.4 Mesa de servicio virtual
6.2.3.4 Sigue al sol
Algunas organizaciones globales o internacionales pueden desear combinar dos o más de

sus Service Desk s geográficamente dispersos para proporcionar un seguimiento del sol las 24 horas
servicio . Por ejemplo, un Service Desk en Asia-Pacífico puede manejar llamadas durante su
horario de oficina estándar y al final de este período puede transferir la responsabilidad
para cualquier incidente abierto a un escritorio con base en Europa. Ese escritorio se encargará de estos
llamadas junto con sus propios incidentes durante su día estándar y luego entregárselos a un
Escritorio con sede en EE. UU., Que finalmente devuelve la responsabilidad a Asia-Pacífico
escritorio para completar el ciclo.
Esto puede brindar cobertura las 24 horas a un costo relativamente bajo , ya que ningún escritorio tiene que funcionar.
más de un solo turno . Sin embargo, las mismas salvaguardias de los procesos comunes,
herramientas, base de datos compartida de información y cultura deben ser abordados para este
enfoque para proceder - y procesos de escalada y traspaso bien controlados
Se necesitan.
6.2.3.5 Grupos de Service Desk especializados
Página 204
Para algunas organizaciones, puede resultar beneficioso crear 'grupos de especialistas' dentro de
la estructura general de Service Desk, de modo que los incidentes relacionados con una TI en particular
El servicio se puede enrutar directamente (normalmente a través de la selección de telefonía o un servicio basado en la web).
interfaz) al grupo de especialistas. Esto puede permitir una resolución más rápida de estos
incidencias, a través de una mayor familiaridad y formación especializada.
La selección se haría usando un script como 'Si su llamada es sobre

el Servicio X, presione 1 ahora; de lo contrario, mantenga presionado para una Mesa de Servicio
analista'.
Es necesario tener cuidado para no complicar demasiado la selección, por lo que los grupos de especialistas deben
solo se considerará para un número muy reducido de servicios clave cuando existan,
y donde las tarifas de llamadas sobre ese servicio justifiquen un grupo de especialistas separado.
6.2.3.6 Medio ambiente
El entorno donde se ubicará el Service Desk debe ser cuidadosamente

elegido. Siempre que sea posible, se deben proporcionar las siguientes instalaciones:
• Un lugar donde toda la función se pueda colocar con suficiente

luz natural y espacio en general, para permitir un escritorio y almacenamiento adecuados
espacio y espacio para moverse si es necesario
Anécdota
Una empresa descubrió que existía una cultura de 'ellos y nosotros' entre los
Service Desk y los demás equipos de soporte. Los equipos de tercera línea a menudo creían
ellos mismos para ser mejores que el Service Desk. Ocultar la mesa de servicio en
una habitación aislada ayudó a reforzar esta cultura. La empresa descubrió que
Se anima a crear una oficina de planta abierta con el Service Desk en el medio
trabajar más de cerca y ayudar a romper estas barreras
• Un ambiente tranquilo con un control acústico adecuado para que un teléfono

la conversación no es interrumpida por otro
• Entorno agradable y mobiliario confortable para aligerar el ambiente.
(el Service Desk puede ser un lugar muy estresante para trabajar, por lo que cada
ayuda!)
• Una sala de descanso separada y un área de refrigerios cercana para que el personal pueda tomar
pausas breves según corresponda cuando sea necesario sin estar ausente demasiado
largo.
6.2.3.7 Nota sobre la creación de un único punto de contacto
Independientemente de la combinación de opciones elegidas para cumplir con los requisitos generales de una organización
Estructura de la mesa de servicio, los usuarios individuales no deben tener dudas sobre a quién
póngase en contacto si necesitan ayuda. Un solo número de teléfono (o un solo número
Página 205
para cada grupo si se eligen escritorios separados) deben proporcionarse y

publicitado, así como una única dirección de correo electrónico y una única mesa de servicio web
pagina de contacto.
Ideas que pueden utilizarse con éxito para ayudar a publicitar el teléfono de la mesa de servicio.
número y dirección de correo electrónico, y ponerlos a disposición cuando los usuarios
es probable que los necesite, son:
• Incluyendo el número de teléfono de la mesa de servicio en las etiquetas de CI de hardware,

adjunto a los componentes sobre los que es probable que el usuario esté llamando
• Impresión de los datos de contacto del Service Desk en los teléfonos
• Para PC y portátiles, utilizando un fondo o escritorio personalizado con el
Los datos de contacto de la mesa de servicio, junto con la información leída del
sistema que se necesitará al llamar (como la dirección IP, la compilación del sistema operativo
número, etc.) en una esquina
• Imprimir el número de Service Desk en 'regalos' (bolígrafos, lápices, tazas,
alfombrillas de ratón, etc.)
• Colocar estos detalles de manera prominente en los sitios de Internet / intranet de Service Desk
• Incluirlos en cualquier tarjeta telefónica o tarjeta de encuesta de satisfacción que quede con
usuarios cuando ha sido necesaria una visita al escritorio
• Repetir los detalles de toda la correspondencia enviada a los usuarios (juntos
con números de referencia de llamada )
• Colocar los datos en tablones de anuncios o ubicaciones físicas en las que se encuentran los usuarios.
que pueda visitar con regularidad (entradas, comedores, zonas de refrigerio, etc.).
6.2.4 Dotación de personal de la mesa de servicio
Las cuestiones involucradas y los criterios para establecer la dotación de personal adecuada
El modelo y los niveles se analizan en esta sección. Detalles sobre la mesa de servicio típica
Las funciones y responsabilidades se pueden encontrar en el párrafo 6.6.1 a continuación. Incluyen
el administrador de la mesa de servicio, el supervisor, los analistas y, en algunas organizaciones,
Estos roles se complementan con usuarios comerciales (' Superusuarios ') que brindan
soporte de primera línea.
6.2.4.1 Niveles de personal
Una organización debe asegurarse de que la cantidad correcta de personal esté disponible en cualquier
tiempo para que coincida con la demanda que la empresa pone sobre el escritorio.
Las tarifas de las llamadas pueden ser muy volátiles y, a menudo, en el mismo día, la tarifa de llegada puede ir
de muy alto a muy bajo y viceversa. Una organización que planea un nuevo escritorio.
debe intentar predecir la tasa de llegada de llamadas y el perfil, y al personal
respectivamente. Análisis estadístico de las tasas de llegada de llamadas con el apoyo actual
Los arreglos deben ser tomados y luego monitoreados y ajustados de cerca como
necesario.
Página 206
Muchas organizaciones encontrarán que las tasas de llamadas alcanzan su punto máximo durante el inicio del día de oficina.
y luego se caen rápidamente, tal vez con otro estallido en la primera parte del
tarde: obviamente, esto varía según el negocio de la organización , pero
es un patrón que ocurre a menudo en muchas organizaciones. En tales circunstancias
puede ser posible utilizar personal a tiempo parcial, trabajadores a domicilio, personal de apoyo de segunda línea
o terceros para cubrir los picos.
Los siguientes factores deben tenerse en cuenta al decidir los niveles de personal:
• Expectativas de servicio al cliente

• Requisitos comerciales , como presupuesto , tiempo de respuesta a las llamadas , etc.
• Tamaño, antigüedad relativa, diseño y complejidad de la infraestructura de TI y
Catálogo de servicios: por ejemplo, el número y tipo de incidentes, el
grado de implementación de software personalizado versus estándar disponible, etc.
• El número de clientes y usuarios a los que dar soporte y factores asociados.
tal como:
• Número de clientes y usuarios que hablan un idioma diferente
• Nivel de habilidad
• Tipos de incidentes y solicitudes de servicio (y tipos de RFC si corresponde):
• Duración del tiempo requerido para los tipos de llamadas (por ejemplo, consultas simples,
consultas de aplicaciones especializadas , hardware, etc.)
• Se requiere experiencia local o externa
• El volumen y tipos de incidentes y solicitudes de servicio.
• El período de cobertura de soporte requerido, basado en:
• Horas cubiertas
• Fuera de las horas de soporte requisito s
• Zonas horarias a cubrir
• Ubicaciones que recibirán soporte (especialmente si el personal de Service Desk también
realizar soporte en el escritorio)
• Tiempo de viaje entre ubicaciones
• Patrón de carga de trabajo de las solicitudes (por ejemplo, diario, fin de mes, etc.)
• Los objetivos de nivel de servicio establecidos (niveles de respuesta, etc.)
• El tipo de respuesta requerida:
• Teléfono
• Correo electrónico / fax / buzón de voz / video
• Asistencia física
• Acceso / control en línea
• El nivel de formación requerido
• Las tecnologías de soporte disponibles (por ejemplo, sistemas telefónicos , soporte remoto
herramientas, etc.)
• Los niveles de habilidades existentes del personal
• Los procesos y procedimientos en uso.
Todos estos elementos deben considerarse cuidadosamente antes de tomar cualquier decisión sobre
Niveles de empleo. Esto también debe reflejarse en los niveles de documentación.
requerido. Recuerde que cuanto mejor sea el servicio , más lo utilizará la empresa.
Página 207
Hay varias herramientas disponibles para ayudar a determinar la cantidad adecuada de personal
para el Service Desk. Estas herramientas de modelado de cargas de trabajo dependen de información detallada
'conocimiento local' de la organización , como volúmenes y patrones de llamadas , servicio
y perfiles de usuario , etc.
6.2.4.2 Niveles de habilidad
Una organización debe decidir el nivel y la gama de habilidades que requiere de su

Personal de la mesa de servicio, y luego asegúrese de que estas habilidades estén disponibles en el
tiempos apropiados.
Es posible una variedad de opciones de habilidades, comenzando solo por un servicio de 'registro de llamadas' :
donde el personal solo necesita habilidades técnicas muy básicas, hasta un nivel 'técnico'
Mesa de servicio donde se utiliza al personal más capacitado técnicamente de la organización. En
En el caso del primero, habrá una alta tasa de manejo pero baja resolución , mientras que
en el último caso, esto se revertirá.
La decisión sobre el nivel de habilidades requerido a menudo se basará en la resolución del objetivo.
veces (acordado con la empresa y capturado en los objetivos de nivel de servicio ), el
complejidad de los sistemas soportados y 'lo que la empresa está dispuesta a pagar'.
Hay una fuerte correlación entre los objetivos de respuesta y resolución y de coste s
- en términos generales, cuanto más cortos sean los tiempos objetivo, mayor será el costo porque
se requieren más recursos .
Si bien puede haber casos en los que la dependencia o la criticidad del negocio
escritorio altamente calificado técnicamente un imperativo, el óptimo y más rentable
El enfoque es generalmente tener una primera línea de soporte de 'registro de llamadas' a través del Servicio
Escritorio, con escalado rápido y efectivo a servicios de segunda y tercera línea más capacitados.
grupos de resolución de línea donde se puede concentrar personal calificado y más
utilizado eficazmente (consulte Gestión de incidentes , sección 4.2, para obtener más detalles y
orientación sobre estructuras de apoyo de un extremo a otro). Sin embargo, este punto de partida básico
puede mejorarse con el tiempo proporcionando al personal de primera línea una
base de conocimientos, scripts de diagnóstico y herramientas de apoyo integradas (incluida una
CMS), así como la formación continua y la sensibilización, para que la resolución de primera línea
las tarifas se pueden aumentar gradualmente.
Esto también se puede lograr ubicando personal de segundo nivel en el Service Desk,
creando efectivamente una estructura de dos niveles. Esto tiene las ventajas de hacer segundas
personal de nivel disponible para ayudar a lidiar con los períodos pico de llamadas y para capacitar a más jóvenes
personal, y a menudo aumentará la tasa de resolución en la primera llamada. Sin embargo,
El personal de segunda línea a menudo tiene deberes fuera de la mesa de servicio, lo que resulta en
las listas deben gestionarse o los puestos de personal de segunda línea se duplican. En
Además, tener que lidiar con llamadas de rutina puede ser desmotivador para más
personal experimentado. Otro posible inconveniente es que el Service Desk se convierte en
Página 208
realmente bueno para resolver llamadas, mientras que el personal de segunda línea debe centrarse en
eliminando la causa raíz en su lugar.
Otro factor a considerar al decidir sobre los requisitos de habilidades para el Servicio
El personal de escritorio es el nivel de personalización o especialización del soporte.
servicios. Los servicios estandarizados requieren conocimientos menos específicos para proporcionar
atención al cliente de calidad . Cuanto más especializado sea el servicio, más probable
Se requerirán conocimientos especializados en la primera convocatoria.
Tenga en cuenta que las tasas de resolución de primera línea se pueden reducir mediante problemas efectivos.
Gestión , que reducirá una serie de incidentes repetitivos más simples. En
tales casos, aunque las tasas de resolución parecen estar disminuyendo, el
la calidad del servicio habrá mejorado con la eliminación completa de muchos incidentes.
Si bien esto es bueno, si el personal de Service Desk recibe incentivos o bonificaciones por primera vez
resolución de llamadas, podría resultar desastroso para la moral y la eficacia del proceso ,
a menos que se revise el umbral de bonificación .
Las mejoras en los tiempos / tasas de resolución no deben dejarse al azar, sino que deben
en su lugar, ser parte de un Programa de mejora del servicio en curso (consulte el
Publicación de mejora continua del servicio para obtener detalles más completos).
Una vez que se han identificado los niveles de habilidad requeridos, hay una tarea en curso para
Asegurarse de que la Mesa de Servicio se opere de tal manera que el personal necesario
obtener y mantener las habilidades necesarias, y que el personal con el equilibrio correcto
de las habilidades están en servicio en los momentos apropiados para que se mantenga la coherencia.
Esto implicará un programa continuo de formación y sensibilización que debería

cubrir:
• Habilidades interpersonales, como habilidades telefónicas, habilidades de comunicación, habilidades

formación en escucha y atención al cliente .
• Conciencia empresarial: conocimiento específico del negocio de la organización .
áreas, conductores , estructura, prioridades, etc.
• Conocimiento del servicio de todos los servicios de TI clave de la organización para los que
se está proporcionando apoyo
• Conciencia técnica (y una formación técnica más profunda para los
nivel, dependiendo de la tasa de resolución buscada)
• Dependiendo del nivel de apoyo brindado, algunas habilidades de diagnóstico (p. Ej.
Kepner y Tregoe)
• Herramientas y técnicas de soporte
• Capacitaciones y tutoriales de sensibilización en nuevos sistemas y tecnologías, previas a la
su introducción
• Procesos y procedimientos (más particularmente Incidente, Cambio y
Gestión de la configuración , pero una descripción general de todos los procesos de ITSM y
procedimientos)
Página 209
• Habilidades de mecanografía para garantizar una entrada rápida y precisa del incidente o servicio.
Pedir detalles.
Para que un programa de este tipo sea eficaz, los requisitos y niveles de habilidades deben ser
evaluado periódicamente y se mantienen registros de capacitación .
Se debe mantener una formulación cuidadosa de las rotaciones de personal o los horarios para
que se establezca un equilibrio constante entre la experiencia del personal y los niveles de habilidad adecuados
presente durante todos los períodos operativos críticos . No es suficiente tener solo el
número adecuado de personal de servicio: también debe estar disponible la combinación correcta de habilidades.
6.2.4.3 Entrenamiento
Es vital que todo el personal de la mesa de servicio esté debidamente capacitado antes de ser llamado.
al personal del Service Desk. Un programa de inducción formal debe ser
realizado por todo el personal nuevo, cuyo contenido exacto variará dependiendo de
los niveles de habilidad existentes y la experiencia del nuevo recluta, pero es probable que incluyan
muchas de las habilidades requeridas como se describe arriba.
Siempre que sea posible, un programa de sensibilización empresarial , que incluya breves períodos de
la adscripción en áreas comerciales clave, debe proporcionarse para el personal nuevo que
aún no tienen este nivel de conciencia empresarial.
Al comenzar en la mesa de servicio , el personal nuevo debe inicialmente 'seguir'

personal experimentado: siéntese con ellos y escuche las llamadas, antes de comenzar a tomar
se llama a sí mismo con un mentor que escucha y es capaz de intervenir y proporcionar
apoyo donde sea necesario. El mentor debe revisar inicialmente cada llamada con el
aprendiz después de que concluya para aprender las lecciones. La frecuencia de tales revisiones.
debe reducirse gradualmente a medida que aumenta la experiencia y la confianza, pero el mentor
debe estar disponible para brindar apoyo continuo incluso cuando el aprendiz haya
llegó a la etapa de ir en solitario.
Es posible que los mentores necesiten recibir capacitación sobre cómo ser mentores. Experiencia en Service Desk y
las habilidades técnicas no son el único requisito para la tutoría. Conocimiento efectivo
transferir habilidades y la capacidad de enseñar sin ser condescendiente o amenazador
son igualmente importantes.
Será necesario un programa para mantener los conocimientos del personal de la mesa de servicio al día.
fecha - y darles a conocer los nuevos desarrollos , servicios y
tecnologías. El momento de tales eventos es crítico para no impactar en el
deberes normales. Muchos Service Desk consideran que es mejor organizar 'tutoriales' breves
durante los períodos tranquilos cuando es menos probable que se necesite personal para el manejo de llamadas.
Nota: También se debe invertir en el desarrollo profesional de

Personal de Service Desk. Asesoramiento interno y seguimiento de segundo y tercer nivel
El personal de apoyo es un buen comienzo, pero los mejores Service Desk se benefician de un
Página 210
programa formalizado de desarrollo del personal. Compromiso organizacional con
El desarrollo profesional ayuda a inculcar un sentido de logro y oportunidad.
al personal. Esto a menudo conduce a la innovación en el funcionamiento de la mesa de servicio (como
servicios especializados) que a su vez impulsan la eficiencia operativa en todos los niveles
de apoyo. Ayuda a desarrollar habilidades que se pueden utilizar en su función actual , así como
inicia el entrenamiento para un nuevo rol. Si bien es importante desarrollar su núcleo
competencias en su puesto actual, teniendo una trayectoria profesional clara y reconociendo
Los requisitos futuros y las necesidades de desarrollo también son importantes.
6.2.4.4 Retención del personal
Es muy importante que todos los gerentes de TI reconozcan la importancia del Servicio
Escritorio y el personal que trabaja en él, y preste especial atención. Cualquier significativo
La pérdida de personal puede ser perjudicial y dar lugar a una incoherencia en el servicio , por lo que los esfuerzos
debe hacerse para que el Service Desk sea un lugar atractivo para trabajar.
Las formas en que se puede hacer esto incluyen el reconocimiento adecuado del rol con recompensa.
paquetes que reconocen esto, ejercicios de formación de equipos, rotación del personal a otros
actividades ( proyectos , apoyo de segunda línea, etc.).
El Service Desk se puede utilizar a menudo como un trampolín hacia otros

roles técnicos o de supervisión / gerencia. Si se hace esto, es necesario tener cuidado para
Asegúrese de que se lleve a cabo una planificación adecuada de la sucesión para que el escritorio no
perder toda su experiencia clave en cualquier área a la vez. Además, buena documentación
y el entrenamiento cruzado puede mitigar este riesgo .
6.2.4.5 Superusuarios
Muchas organizaciones encuentran útil nombrar o designar una serie de ' Super
Usuarios en toda la comunidad de usuarios , para actuar como puntos de enlace con TI en general
y el Service Desk en particular.
Los superusuarios pueden recibir formación y conciencia adicionales y utilizarlos como

Conducto para el flujo de comunicaciones en ambas direcciones. Se les puede pedir que filtren
solicitudes y problemas planteados por la comunidad de usuarios (en algunos casos, incluso
en cuanto a tener incidentes o solicitudes planteadas por el superusuario), esto puede ayudar
prevenir ' tormentas de incidentes ' cuando falla un servicio o componente clave , lo que afecta a muchos
usuarios.
También se pueden utilizar para enviar información en cascada desde el Service Desk hacia afuera.
en toda su comunidad de usuarios local, lo que puede resultar muy útil para difundir
detalles del servicio a todos los usuarios muy rápidamente.
Es importante tener en cuenta que los superusuarios deben registrar todas las llamadas con las que se ocupan,
y no solo los que le transmiten a TI. Esto significará acceso y capacitación
sobre cómo utilizar las herramientas de registro de incidentes. Esto ayudará a medir la actividad de
Página 211
el Superusuario y también para asegurarse de que no se abuse de su posición. Además,

se asegurará de que el valioso historial con respecto a incidentes y calidad del servicio no se
perdió.
También es posible que los superusuarios participen en:
• Capacitación del personal para los usuarios de su área

• Brindar soporte para incidentes menores o simple cumplimiento de solicitudes
• Participación con nuevas versiones y lanzamientos .
Los superusuarios no necesariamente brindan soporte para toda la TI. En muchos

casos, un superusuario solo proporcionará soporte para una aplicación , módulo o
área de la unidad de negocio . Como usuario empresarial, el superusuario a menudo tiene conocimientos
conocimiento de cómo se ejecutan los procesos comerciales clave y cómo funcionan los servicios en
práctica . Este es un conocimiento muy útil para compartir con el Service Desk , para que
puede proporcionar servicios de mayor calidad en el futuro.
Cabe señalar que se necesita un compromiso firme por parte de los posibles superusuarios,
y específicamente su gestión, que tendrán tiempo e interés para
desempeñar este papel antes de que comience la selección y la formación.
Un superusuario, a la vez que una valiosa interfaz para la empresa y la mesa de servicio,
debe recibir la formación adecuada, la responsabilidad y las expectativas. Los superusuarios pueden
ser vulnerable al uso indebido si su función, responsabilidades y el proceso que rige
estos no se comunican claramente a los usuarios. Es imperativo que un Super
El usuario no es visto como un reemplazo o un medio para eludir el Servicio.
Escritorio.
6.2.5 Métricas de la mesa de servicio
Deben establecerse métricas para que el desempeño de la mesa de servicio pueda ser
evaluado a intervalos regulares. Esto es importante para evaluar la salud, madurez ,
eficiencia , eficacia y cualquier oportunidad para mejorar Service Desk
operaciones.
Las métricas para el desempeño de la mesa de servicio deben ser realistas y elegidas cuidadosamente. Es
común para seleccionar aquellas métricas que están fácilmente disponibles y que pueden parecer
ser una posible indicación de desempeño; sin embargo, esto puede resultar engañoso. Para
Por ejemplo, el número total de llamadas recibidas por Service Desk no es en sí mismo un
indicación de buen o mal desempeño y, de hecho, puede ser causado por
eventos completamente fuera del control de la mesa de servicio, por ejemplo, un
período particularmente ocupado para la organización , o el lanzamiento de una nueva versión de un
importante sistema corporativo .
Un aumento en el número de llamadas al Service Desk puede indicar menos confiabilidad

servicios durante ese período de tiempo, pero también puede indicar un aumento de usuarios
Página 212
confianza en un Service Desk que está madurando, lo que resulta en una mayor probabilidad de que
los usuarios buscarán ayuda en lugar de tratar de arreglárselas solos. Para que este tipo de métrica
Ser confiable para llegar a cualquier conclusión, comparación adicional de períodos anteriores.
para cualquier mejora de Service Desk implementada desde la última medición
línea de base , o cambios en la confiabilidad del servicio , problemas , etc. para aislar la verdadera causa
porque el aumento es necesario.
Por lo tanto, se necesitan más análisis y métricas más detalladas y deben ser
examinado durante un período de tiempo. Estos incluirán las estadísticas de manejo de llamadas.
mencionado anteriormente en telefonía, y adicionalmente:
• La tasa de resolución de primera línea : el porcentaje de llamadas resueltas en la primera línea,

sin necesidad de escalar a otros grupos de apoyo . Esta es la figura
a menudo citado por las organizaciones como la medida principal del Servicio
Rendimiento de escritorios, y se utiliza para fines de comparación con el
rendimiento de otros escritorios, pero es necesario tener cuidado al realizar cualquier
comparaciones. Para una mayor precisión y comparaciones más válidas, esto puede
ser desglosado de la siguiente manera:
• El porcentaje de llamadas resueltas durante el primer contacto con el
Service Desk , es decir, mientras el usuario todavía está en el teléfono para informar
la llamada
• El porcentaje de llamadas resueltas por el personal de Service Desk
ellos mismos sin tener que buscar un apoyo más profundo de otros
grupos. Nota: algunos escritorios optarán por coubicar o incorporar más
personal de segunda línea técnicamente capacitado con la mesa de servicio (ver
Gestión de incidentes para más detalles). En tales casos es
importante al hacer comparaciones para también separar (i) La
porcentaje resuelto solo por el personal de la Mesa de Servicio; y (ii) La
porcentaje resuelto por el personal de la recepción Servicio de primera línea y de segunda
personal de apoyo de línea combinado.
• Tiempo promedio para resolver un incidente (cuando se resuelve en la primera línea)
• Tiempo promedio para escalar un incidente (donde la resolución de primera línea no es
posible)
• Costo promedio de Service Desk por manejar un incidente. Dos métricas deben ser
considerado aquí:
• Costo total del Service Desk dividido por el número de llamadas. Esta
proporcionará una cifra promedio que es útil como índice y para
propósitos de planificación , pero no representa con precisión el relativo
costos de diferentes tipos de llamadas
• Calculando el porcentaje de tiempo de duración de la llamada en el escritorio
total y calculando un costo por minuto (costos totales para el período
dividido por los minutos de duración total de la llamada ') esto se puede usar para calcular
el costo de las llamadas individuales y dar una cifra más precisa.
Al evaluar los tipos de incidentes con duración de la llamada, un método más refinado
surge una imagen del costo por llamada por tipos y da una indicación de cuál
Página 213
Los tipos de incidentes tienden a costar más para resolver y los posibles objetivos para
Mejoras.
• Porcentaje de actualizaciones de clientes o usuarios realizadas dentro de los tiempos objetivo, como
definido en los objetivos de SLA
• Tiempo promedio para revisar y cerrar una llamada resuelta
• El número de llamadas desglosadas por hora del día y día de la semana,
combinado con la métrica de tiempo de llamada promedio, es fundamental para determinar el
número de personal necesario.
Más detalles generales sobre las métricas y cómo deben usarse para avanzar
La calidad del servicio se incluye en la publicación Mejora continua del servicio .
6.2.5.1 Encuestas de satisfacción de clientes / usuarios
Además de rastrear las medidas 'duras' del desempeño de la mesa de servicio (a través de
las métricas descritas anteriormente), también es importante evaluar las medidas 'blandas' -
como qué tan bien sienten los clientes y los usuarios que se han respondido sus llamadas,
si sienten que el operador de la mesa de servicio fue cortés y profesional,
si infundieron confianza en el usuario.
Este tipo de medida se obtiene mejor de los propios usuarios. Esto puede ser
realizado como parte de una encuesta más amplia de satisfacción del cliente / usuario que cubre toda la TI o puede
estar dirigido específicamente a los problemas de la mesa de servicio únicamente.
Una forma eficaz de lograr esto último es mediante una encuesta telefónica de devolución de llamada,
donde un operador o supervisor de la mesa de servicio independiente llama a un pequeño
porcentaje de usuarios poco después de que se haya resuelto su incidente, para preguntar al
preguntas específicas necesarias.
Se debe tener cuidado de mantener el número de preguntas al mínimo (de cinco a seis
como máximo) para que los usuarios tengan tiempo de cooperar. También encuesta
Las preguntas deben diseñarse de modo que el usuario o cliente sepa qué área o
Las preguntas sobre el tema tratan y a qué incidente o servicio se refieren.
El Service Desk debe actuar sobre los bajos niveles de satisfacción y los comentarios recibidos.
Para permitir comparaciones adecuadas, el mismo porcentaje de llamadas debe ser

seleccionados en cada período y deben llevarse a cabo con rigor a pesar de cualquier
otras presiones de tiempo.
Página 214
Las encuestas son un área compleja y especializada que requiere un buen conocimiento de
estadísticas y técnicas de encuestas. Esta publicación no intentará proporcionar una
descripción general de todos estos, pero un resumen de algunos de los más utilizados
técnicas y herramientas se enumeran en la Tabla 6.1.
Técnica / Herramienta Ventajas Desventajas
Encuesta posterior a la llamada • Alta tasa de respuesta • La gente puede sentir

ya que la persona que llama es presionado para tomar
Se pide a las personas que llaman que permanezcan ya en el telefono la encuesta, lo que resulta en
en el teléfono después de la llamada • Se encuesta a la persona que llama un servicio negativo
y luego pidió que calificara el inmediatamente después de la • experiencia
servicio que se les brindó llama así su experiencia Se ve al topógrafo
es reciente como parte del Servicio
Escritorio que está siendo inspeccionado,
que puede desanimar
respuestas abiertas
Teléfono saliente • Tasa de respuesta más alta • Este método podría ser
encuesta ya que la persona que llama es visto como intrusivo, si el
entrevistado directamente llamada interrumpe al usuario o
Clientes y usuarios que • Categorías específicas de cliente de su
he usado previamente el el usuario o cliente puede trabaja
Se contacta con la mesa de servicio ser objetivo de • La encuesta es
algún tiempo después de su retroalimentación (por ejemplo, personas realizado algún tiempo
experiencia con el Servicio quien solicitó un después del usuario o
Escritorio servicio específico, o el cliente usó el
la gente experimentó un Service Desk, por lo que su
interrupción de un la percepción puede tener
servicio particular) cambió
Entrevistas personales • El entrevistador puede • Las entrevistas son de tiempo

para observar no verbal consumiendo tanto para el
Los clientes y usuarios son señales así como entrevistador y el
entrevistado personalmente por escuchando lo que el demandado
la persona que realiza la encuesta. usuario o cliente es • Usuarios y clientes
Esto es especialmente efectivo dicho podría convertir el
para clientes o usuarios que • Usuarios y clientes entrevistas en
utilizar la mesa de servicio sentir un mayor grado de sesiones de quejas ·
extensamente o que han tenido atención personalizada y
una experiencia muy negativa una sensación de que su
las respuestas están siendo
tomado en serio ·
Entrevistas grupales • Un mayor número de • La gente puede no

usuarios y clientes expresarse
Los clientes y usuarios son puede ser entrevistado libremente delante de su
entrevistados en pequeños grupos. • Las preguntas son más compañeros o gerentes
Esto es bueno para reunir genérico y por lo tanto • Las opiniones de la gente pueden
impresiones generales y para mas consistente ser cambiado fácilmente por
Página 215
determinar si hay entre entrevistas · otros en el grupo

una necesidad de cambiar ciertos durante la entrevista ·
aspectos del Service Desk ,
por ejemplo , horas de servicio o
localización
•
Encuestas postales / por correo electrónico Específico o todos • Las encuestas postales son
los clientes o usuarios pueden trabajo intensivo para
Los cuestionarios de la encuesta son ser objetivo proceso
enviado por correo a un conjunto de destino•de Las encuestas postales pueden ser • El porcentaje de
clientes y usuarios. Ellos anónimo, permitiendo personas respondiendo a
se les pide que devuelvan sus personas para expresar las encuestas postales tienden a
respuestas por correo electrónico ellos mismos más libremente ser pequeño
• •
Las encuestas por correo electrónico no son Mala interpretación de un
anónimo, pero puede ser la pregunta podría afectar
creado usando
formularios automatizados que el resultado ·
hazlo conveniente y
fácil para el usuario
responder y aumentar el
probabilidad de que sea
completado ·
Encuestas online • La audiencia potencial El porcentaje de encuestados

de estas encuestas es no se puede predecir
Se publican los cuestionarios realmente largo
en un sitio web y los usuarios y • Los encuestados pueden
se anima al cliente a través de completar la
correo electrónico o enlaces de un cuestionario en su
sitio popular para participar propio tiempo
la encuesta • Los enlaces en populares
los sitios web son buenos
recordatorios sin
ser intrusivo
Tabla 6.1 Técnicas y herramientas de encuesta
6.2.6 Subcontratación de la mesa de servicio
La decisión de subcontratar es un tema estratégico para los altos directivos, y es

se tratan en detalle en las publicaciones de Estrategia de servicio y Diseño de servicio .
Muchas de las pautas de esta sección no son exclusivas del Service Desk y pueden
aplicarse a cualquier función , área de soporte o servicio que se esté subcontratando (o subcontratando)
encargado).
Independientemente de las razones o el alcance del contrato de subcontratación , es vital

que la organización retiene la responsabilidad de las actividades y servicios prestados
por el Service Desk. La organización es en última instancia responsable de los resultados s
de la decisión y, por lo tanto, debe determinar qué servicio el subcontratista
proporciona, no al revés.
Página 216
Si se elige la ruta de subcontratación, hay algunas salvaguardas que son necesarias para
Asegurar que el Service Desk subcontratado trabaje de manera efectiva y eficiente con el
otros equipos y departamentos de TI de la organización y que de extremo a extremo de servicio
Se mantiene el control de gestión (esto es particularmente importante para las organizaciones
buscar la certificación ISO / IEC 20000 ya que el control de gestión general debe ser
demostrado). Algunas de estas salvaguardias se describen a continuación.
6.2.6.1 Herramientas y procesos comunes
El Service Desk no es responsable de todos los procesos y

procedimiento s que inicia. Por ejemplo, una solicitud de servicio es recibida por el
Service Desk, pero la solicitud es cumplida por el equipo operativo de TI interno .
Si se subcontrata el Service Desk, se debe tener cuidado de que las herramientas

coherente con los que todavía se utilizan en la organización del cliente. La subcontratación es
a menudo visto como una oportunidad para reemplazar herramientas obsoletas o inadecuadas, solo para encontrar
que existen graves problemas de integración entre la nueva herramienta y el legado
herramientas y procesos.
Por esta razón, es importante asegurarse de que estos problemas sean correctamente
investigado y los requisitos del cliente están adecuadamente delimitados y
especificado antes del contrato de subcontratación. Las herramientas de Service Desk no solo deben
Apoyar al Service Desk subcontratado, pero deben apoyar al cliente.
los procesos de la organización y los requisitos comerciales también.
Idealmente, el escritorio subcontratado debería utilizar las mismas herramientas y procesos (o, como
mínimo, herramientas y procesos de interfaz) para permitir un flujo de proceso suave entre
el Service Desk y los grupos de apoyo de segunda y tercera línea.
Además, el Service Desk subcontratado debe tener acceso a:
• Toda la información y los registros de incidentes

• Registro de problemas e información
• Datos de error conocidos
• Cambiar horario
• Fuentes de conocimiento interno (especialmente técnicos o expertos en aplicaciones )
• SKMS
• CMS
• Alertas de herramientas de monitoreo .
A menudo es un desafío integrar procesos y herramientas en un entorno menos maduro.

organización con los de una organización más madura. Un común pero incorrecto
la suposición es que la madurez de una organización resultará de alguna manera en
mayor madurez en el otro. Participación activa para asegurar la alineación de procesos
y herramientas es esencial para una transición fluida y una gestión continua de
Página 217
servicios entre las organizaciones internas y externas. De hecho, si esto no es

abordado directamente, podría resultar en el incumplimiento del contrato .
A menudo también se asume incorrectamente que la prueba de la calidad de la gestión del servicio
y la madurez en un socio externo externo se puede garantizar indicando
requisitos en el proceso de adquisición para la ' conformidad con ITIL ' y / o
' Certificación ISO / IEC 20000 '. Estas declaraciones pueden indicar que un potencial
proveedor utiliza el marco ITIL en su prestación de servicios a los clientes, o que
han logrado la certificación estándar para sus prácticas internas , pero es
igualmente importante tener la tecnología habilitadora en su lugar y ser utilizada para
demuestra la capacidad de un proveedor de servicios para administrar servicios e interactuar con
prácticas internas armoniosamente. No existe un estándar de cumplimiento que garantice
Esto y, por lo tanto, los esfuerzos de adquisición deben incluir consultas específicas para satisfacer este
requisito. Puede encontrar más información sobre la adquisición de proveedores externos en
la publicación Service Design .
6.2.6.2 Objetivos de SLA
Los objetivos de SLA para tiempos generales de resolución y manejo de incidentes deben ser
acordado con los clientes y entre todos los equipos y departamentos, y
Los objetivos de OLA / UC deben coordinarse y acordarse con apoyo individual
group s para que respalden y respalden los objetivos de SLA.
Se pueden ver ejemplos de estos en la sección de métricas anterior (consulte la sección

6.2.5).
6.2.6.3 Buenas comunicaciones
Las líneas de comunicación entre el Service Desk subcontratado y el otro

los grupos de apoyo deben trabajar de manera muy eficaz. Esto puede ser asistido por algunos o todos
de los siguientes pasos:
• Cerrar la coubicación física

• Reuniones periódicas de enlace / revisión
• Tutoriales de formación cruzada entre los equipos y departamentos
• Arreglos de ' asociación ' cuando se utiliza personal de ambas organizaciones
conjuntamente para atender el escritorio
• Los planes de comunicación y los objetivos de desempeño se documentan en un
de manera consistente en OLA y UC.
En los casos en los que el Service Desk se encuentra en alta mar , no todas estas medidas
será posible. Sin embargo, la necesidad de formación y comunicación del
El personal de la mesa de servicio sigue siendo fundamental, incluso más en los casos en que hay
diferencias lingüísticas y culturales.
Página 218
Esto se tratará con más detalle en las publicaciones complementarias de ITIL, pero, como
regla, las empresas de subcontratación que ofrecen soluciones de Service Desk en el extranjero deben
tenga en cuenta lo siguiente:
• El programa de formación se centra en la comprensión cultural del cliente.

mercado
• Habilidades lingüísticas, especialmente la comprensión del uso idiomático de la
idioma en el mercado de clientes. Esto no es para que el personal de Service Desk
suenan como nativos del país del cliente (ese tipo de falta de sinceridad es muy
detectados rápidamente por los clientes), sino para facilitar una mejor comprensión de los
cliente y para apreciar mejor sus prioridades
• Visitas periódicas de representantes de la organización del cliente para proporcionar
capacitación y retroalimentación apropiada directamente al Service Desk
gerencia y personal
• Capacitación en el uso de las herramientas y métodos de las organizaciones de clientes
trabaja. Esto es especialmente eficaz si se presentan materiales de formación similares.
por los mismos instructores que los utilizados por la organización del cliente.
6.2.6.4 Propiedad de los datos
La propiedad clara de los datos recopilados por el Service Desk subcontratado debe ser
establecido. Propiedad de todos los datos relativos a usuarios, clientes, CI afectados,
servicios, incidencias, solicitudes de servicio , cambios, etc.deben permanecer con el
organización que está subcontratando la actividad , pero ambas organizaciones requerirán
acceso a ella.
Datos que se relacionan específicamente con el desempeño de los empleados de la subcontratación.

empresa seguirá siendo propiedad de esa empresa, que a menudo es legalmente
impidió compartir los datos con la organización del cliente. Esto también puede
ser cierto para otros datos que se utilizan exclusivamente para la gestión interna de la
Service Desk, como personal, actividades de optimización, costo de Service Desk
información, etc.
Todos los requisitos de informes y los problemas relacionados con la propiedad de los datos deben ser
especificado en el contrato subyacente con la empresa que proporciona el
servicio de subcontratación.
Página 219
6.3 Gestión técnica
La Gestión Técnica se refiere a los grupos, departamentos o equipos que brindan

experiencia técnica y gestión general de la infraestructura de TI .
6.3.1 Rol de gestión técnica
La Gestión Técnica juega un doble papel :
• Es el custodio de los conocimientos técnicos y la experiencia relacionados con

gestionar la infraestructura de TI. En este rol, la Gerencia Técnica
asegura que los conocimientos necesarios para diseñar , probar , gestionar y mejorar
Los servicios de TI se identifican, desarrollan y perfeccionan.
• Proporciona los recursos reales para respaldar el ciclo de vida de ITSM . En este papel
La Gerencia Técnica asegura que los recursos estén efectivamente capacitados y
implementado para diseñar , construir , hacer la transición, operar y mejorar la tecnología
necesarios para prestar y dar soporte a los servicios de TI .
Al desempeñar estos dos roles , la Gerencia Técnica puede asegurar que el

organización tiene acceso al tipo y nivel adecuados de recursos humanos para
gestionar la tecnología y, por tanto, cumplir con los objetivos empresariales . Definiendo el
Los requisitos para estos roles comienzan en Estrategia de servicio y se expanden en
Diseño de Servicio , validado en Transición de Servicio y refinado en Servicio Continuo
Mejora (ver otras publicaciones de ITIL en esta serie).
Parte de esta función también es garantizar un equilibrio entre el nivel de habilidad, la utilización y
el costo de estos recursos. Por ejemplo, contratar un recurso de alto nivel en el
extremo superior de la escala salarial y luego solo usar esa habilidad durante el 10% del tiempo es
no efectivo. Una mejor estrategia de Gestión Técnica sería identificar el
veces que se necesita la habilidad y luego contratar a un contratista solo para esas tareas.
Otra estrategia en las organizaciones más grandes es aprovechar al personal especializado de

grupos 'centrales' para que los especialistas puedan ser bien utilizados y proporcionar una economía de
escalar a la organización y minimizar la necesidad de contratar contratistas.
Las habilidades especializadas deben identificarse entre los recursos de la organización de TI,
luego aprovechado para necesidades específicas a medida que surgen, análoga a una táctica especial
unidad, cuyos miembros también realizan deberes regulares pero que están asignados a tareas
necesitando sus habilidades especializadas. Este tipo de utilización de recursos es particularmente
útil tanto para los equipos de proyecto como para la resolución de problemas .
Un papel adicional, pero muy importante que desempeña la Dirección Técnica, es

proporcionar orientación a las operaciones de TI sobre la mejor manera de llevar a cabo la
gestión operativa de la tecnología. Este papel se lleva a cabo en parte durante el
Proceso de diseño de servicios , pero también es parte de la comunicación diaria con TI.
Gestión de operaciones, ya que buscan lograr estabilidad y óptimas
rendimiento .
Página 220
Los objetivos, actividades y estructuras que permiten a la Dirección Técnica

desempeñar estas funciones de manera eficaz se analizan a continuación.
6.3.2 Objetivos de la gestión técnica
Los objetivos de la Gestión Técnica son ayudar a planificar, implementar y

Mantener una infraestructura técnica estable para respaldar el negocio de la organización.
proceso es a través de:
• Topología técnica bien diseñada, altamente resistente y rentable

• El uso de habilidades técnicas adecuadas para mantener la técnica
infraestructura en óptimas condiciones
• Uso rápido de habilidades técnicas para diagnosticar y resolver rápidamente cualquier problema técnico.
fallas que ocurren.
6.3.3 Actividades genéricas de gestión técnica
La Dirección Técnica está involucrada en dos tipos de actividad :
• Las actividades que son genéricas para la Gestión Técnica funcionan como un
en su conjunto se analizan en esta sección, ya que permiten la gestión técnica
como una función para ejecutar su papel.
• Un conjunto de actividades y procesos discretos que son realizados por los tres
Las funciones de Gestión técnica, de aplicaciones y de operaciones de TI son
cubierto en el Capítulo 5.
Las actividades genéricas de gestión técnica se destacan de la siguiente manera:
• Identificar el conocimiento y la experiencia necesarios para gestionar y operar

la infraestructura de TI y para brindar servicios de TI . Este proceso comienza durante
la fase de estrategia de servicio , se amplía en detalle en el diseño del servicio y se
ejecutado en Operación de servicio . Continua evaluación y actualización de
estas habilidades se realizan durante la mejora continua del servicio .
• Documentación de las habilidades que existen en la organización , así como aquellas
habilidades que necesitan ser desarrolladas. Esto incluirá el desarrollo de habilidades.
Inventarios y realización de Análisis de Necesidades de Formación.
• Iniciar programas de formación para desarrollar y perfeccionar las habilidades en el
recursos técnicos apropiados y mantenimiento de registros de capacitación para todos
recursos técnicos.
• Diseño e impartición de formación para usuarios , Service Desk y otros
grupos. Aunque los requisitos de formación deben definirse en el diseño del servicio,
se ejecutan en Operación de servicio. Donde Gestión Técnica
no imparte formación, es responsable de identificar las organizaciones que
puede proporcionarlo.
Página 221
• Reclutar o contratar recursos con habilidades que no se pueden desarrollar

internamente, o donde no hay suficientes personas para realizar las tareas requeridas.
Actividades de Gestión Técnica.
• Adquirir habilidades para actividades específicas donde las habilidades requeridas no son
disponible internamente o en el mercado abierto, o donde sea más rentable
para hacerlo.
• Definición de estándares utilizados en el diseño de nuevas arquitecturas y
participación en la definición de arquitecturas tecnológicas durante el Servicio
Fases de estrategia y diseño.
• Investigación y desarrollo de soluciones que puedan ayudar a expandir el Servicio.
Portafolio o que se puede utilizar para simplificar o automatizar las operaciones de TI ,
reduzca los costos o aumente los niveles de servicio de TI.
• Implicación en el diseño y construcción de nuevos servicios. Técnico
La dirección contribuirá al diseño de la Arquitectura Técnica
y Estándares de desempeño para servicios de TI. Además, también será
responsable de especificar las actividades operativas necesarias para gestionar la
Infraestructura de TI de forma continua.
• Participación en los proyectos , no solo durante el Diseño y el Servicio
Transición, sino también para la mejora continua del servicio u operacional
proyectos, como actualizaciones del sistema operativo, consolidación de servidores
proyectos o mudanzas físicas.
• La disponibilidad y la gestión de la capacidad dependen de
Gestión de servicios de TI de ingeniería para cumplir con los niveles de servicio
requerido por la empresa. Esto significa que el modelado y la carga de trabajo
Los pronósticos a menudo se realizan con recursos de Gestión Técnica.
• Asistencia en la evaluación de riesgos , identificación de servicios y sistemas críticos
dependencias y definir e implementar contramedidas .
• Diseñar y realizar pruebas de funcionalidad, rendimiento y
capacidad de gestión de los servicios de TI.
• Gestión de proveedores. Numerosos departamentos o grupos de Gestión Técnica
son los únicos que saben exactamente qué se requiere de un proveedor y cómo
para medirlos y gestionarlos. Por esta razón, muchas organizaciones confían
en los departamentos de Gestión Técnica para gestionar los contratos con los proveedores
de IC específicos. Si este es el caso, es importante asegurarse de que estos
Las relaciones se gestionan como parte del proceso SLM .
• Definición y gestión de estándares y herramientas de Gestión de Eventos .
La Gerencia Técnica también monitoreará y responderá a muchas categorías
del evento s.
• Los departamentos o grupos de Gestión Técnica son parte integral de la
desempeño de la Gestión de Incidentes . Reciben incidencias a través
Escalada funcional y proporcionar soporte de segundo y nivel superior. Ellos
también participan en el mantenimiento de categorías y la definición de la escalada
procedimientos que se ejecutan en Gestión de incidentes.
• La Gestión Técnica como función proporciona los recursos que ejecutan
el proceso de Gestión de Problemas . Es su experiencia técnica y
conocimiento que se utiliza para diagnosticar y resolver problemas . También es su
Página 222
relación con los proveedores que se utiliza para escalar y dar seguimiento a
equipos de soporte de proveedores.
• Los recursos de gestión técnica participarán en la definición de codificación.
sistemas que se utilizan en la gestión de incidentes y problemas (p. ej.
Categorías).
• Los recursos de gestión técnica se utilizan para apoyar el problema
Gestión en la validación y mantenimiento de la KEDB.
• La gestión del cambio se basa en el conocimiento técnico y la experiencia para
evaluar los cambios, y muchos cambios serán construidos por Technical
Administración.
• Las versiones se implementan con frecuencia mediante Technical Management
recursos.
• La Gerencia Técnica proporcionará información y operativamente
mantener, el sistema de Gestión de la Configuración y sus datos. Esto será
realizado en cooperación con Gestión de aplicaciones para garantizar que el
Los atributos y relaciones de CI correctos se crean a partir de la implementación de
servicios y el mantenimiento continuo durante la vida de los CI.
• La Gerencia Técnica está involucrada en la Mejora Continua del Servicio
procesos, particularmente en la identificación de oportunidades de mejora y
luego en ayudar a evaluar soluciones alternativas.
• Como custodio del conocimiento técnico y la experiencia, Technical
La administración garantiza que toda la documentación operativa y del sistema esté actualizada
hasta la fecha y correctamente utilizado. Esto incluye asegurarse de que toda la gestión,
Los manuales de administración y de usuario están actualizados y completos y
el personal técnico está familiarizado con su contenido.
• Actualizar y mantener los datos utilizados para informar sobre aspectos técnicos y de servicio.
capacidades, por ejemplo , gestión de capacidad y rendimiento , disponibilidad
Gestión, gestión de problemas, etc.
• Ayudar a la gestión financiera de TI a identificar el costo de la tecnología y
Recursos humanos de TI utilizados para administrar los servicios de TI .
• Participación en la definición de las actividades operativas realizadas como parte de TI
Jefe de operaciones. Muchos departamentos de gestión técnica,
grupos o equipos también realizan las actividades operativas como parte de un
organización ‘s Gestión de Operaciones de TI función.
6.3.4 Organización de gestión técnica
La gestión técnica no suele estar a cargo de un solo departamento o grupo.

Se necesitarán uno o más equipos o departamentos de soporte técnico para proporcionar
gestión técnica y soporte a la Infraestructura de TI . En todos menos en
organizaciones más pequeñas, donde un solo equipo o departamento combinado puede
será suficiente, se necesitarán equipos o departamentos separados para cada tipo de
infraestructura que se está utilizando.
La Gestión de Operaciones de TI consta de una serie de áreas tecnológicas. Cada uno de

estos requieren un conjunto específico de habilidades para administrarlo y operarlo . Algunas habilidades
Página 223
están relacionados y pueden ser realizados por generalistas, mientras que otros son específicos de un
componente , sistema o plataforma.
El criterio principal de la estructura organizativa de la Gestión Técnica es el de

especialización o división del trabajo. El principio es que las personas se agrupan
de acuerdo con sus habilidades técnicas, y que estas habilidades están determinadas por
la tecnología que necesita ser gestionada.
Las secciones 6.6 y 6.7 cubren los aspectos organizativos de la gestión técnica.
en detalle, pero esta lista proporciona algunos ejemplos de gestión técnica típica
equipos o departamentos:
• Equipo o departamento de mainframe: si uno o más tipos de mainframe todavía

siendo utilizado por la organización
• Equipo o departamento de servidores : a menudo se vuelve a dividir por tipos de tecnología (p. Ej.
Servidor Unix, servidor Wintel)
• Equipo o departamento de almacenamiento, responsable de la gestión de todos los datos.
dispositivos de almacenamiento y medios
• Equipo o departamento de soporte de red, que se ocupa de la organización
internos WAN / LAN y la gestión de cualquier red externa proveedor s
• Equipo o departamento de escritorio, responsable de todo el escritorio instalado
equipo
• Equipo o departamento de base de datos, responsable de la creación, mantenimiento
y soporte de las bases de datos de la organización
• Equipo o departamento de middleware , responsable de la integración, pruebas
y mantenimiento de todo el middleware en uso en la organización
• El equipo o departamento de Directory Service , responsable de mantener
acceso y derechos a elementos de servicio en la infraestructura
• Equipo o departamento de Internet o Web, responsable de gestionar la
disponibilidad y seguridad de acceso a servidores y contenido por externos
clientes , usuarios y socios
• Equipo o departamento de mensajería, responsable de los servicios de correo electrónico
• Equipo o departamento de telefonía basada en IP (por ejemplo, VoIP).
6.3.5 Diseño técnico y mantenimiento y soporte técnico
La Dirección Técnica está formada por arquitectos y diseñadores técnicos especializados.

(que participan principalmente durante el diseño del servicio ) y mantenimiento especializado
y personal de apoyo (que participa principalmente durante la operación del servicio ).
En esta publicación, se los considera parte de la misma función , pero muchos

las organizaciones los ven como dos equipos separados o incluso departamentos. los
El problema de este enfoque es que un buen diseño necesita la participación de las personas que
son necesarios para gestionar la solución, y un buen funcionamiento requiere participación
de las personas que diseñaron la solución.
Página 224
Los problemas que deben superarse son similares a los que se enfrentan en la gestión
el ciclo de vida de la aplicación (consulte la sección 6.5 para una discusión más detallada). los
La solución incluirá los siguientes elementos:
• El personal de apoyo debe participar durante el diseño o la arquitectura de un

solución. El personal de diseño debe participar en el establecimiento de los objetivos de mantenimiento .
y resolución de problemas de soporte.
• Un cambio en la forma en que se mide tanto al personal de Diseño como al de Soporte. Diseñadores
debe realizarse en parte responsable de los defectos de diseño que crean operativa
cortes. El personal de apoyo debe ser responsable en parte de la contribución a
la arquitectura técnica.
6.3.6 Métricas de gestión técnica
Las métricas para la gestión técnica dependerán en gran medida de qué tecnología se
administrado, pero algunas métricas genéricas incluyen:
• Medición de productos acordados. Estos podrían incluir:

• Contribución a la consecución de servicios a la empresa. Aunque
muchos de los equipos de Gestión Técnica no estarán en directo
contacto con el negocio, la tecnología que manejan impacta en el
negocio. Las métricas deben reflejar tanto los incidentes negativos
su equipo) y positivo ( rendimiento y disponibilidad del sistema )
contribuciones
• Tasas de transacción y disponibilidad para transacciones comerciales críticas
• Capacitación de Service Desk
• Grabación de la resolución de problemas en el KEDB
• Medidas de usuario de la calidad de los resultados según se define en los SLA
• Instalación y configuración de componentes bajo su control .
• Métricas de proceso . Los equipos de gestión técnica ejecutan muchos servicios
Actividades del proceso de gestión . Su capacidad para hacerlo se medirá como
parte de las métricas del proceso cuando corresponda (consulte la sección sobre cada
proceso para más detalles). Ejemplos incluyen:
• Tiempo de respuesta a eventos y tasas de finalización de eventos
• Tiempos de resolución de incidentes para soporte de segunda y tercera línea
• Estadísticas de resolución de problemas
•
•
Número de escaladas y motivo de esas escaladas
Número de cambios implementados y retirados
• Número de cambios no autorizados detectados
• Número de lanzamientos implementados, totales y exitosos
• Problemas de seguridad detectados y resueltos
• Utilización real del sistema contra los pronósticos del Plan de capacidad (donde el
equipo ha contribuido al desarrollo del plan )
• Seguimiento contra SIP
• Gastos con cargo al presupuesto .
Página 225
• Rendimiento tecnológico . Estas métricas se basan en el diseño del servicio.

especificaciones y estándares de desempeño técnico establecidos por los proveedores, y
normalmente estará contenido en OLA o procedimientos operativos estándar.
Las métricas reales variarán según la tecnología, pero es probable que incluyan:
• Tasas de utilización (por ejemplo, memoria o procesador para servidor , ancho de banda para
redes, etc.)
• Disponibilidad (de sistemas, red, dispositivos, etc.), que es útil para
medir el rendimiento del equipo o del sistema, pero no debe confundirse
con disponibilidad de servicio, que requiere la capacidad de medir la
disponibilidad general del servicio y puede utilizar las cifras de disponibilidad
para un número de sistemas individuales o componentes s
• Rendimiento (por ejemplo , tiempos de respuesta , tasas de espera, etc.).
• Tiempo medio entre fallos del equipo especificado. Esta métrica es
se utiliza para garantizar que se tomen buenas decisiones de compra y, cuando
en comparación con los programas de mantenimiento, si el equipo está siendo
debidamente mantenido
• Medición de la actividad de mantenimiento , que incluye:
• Mantenimiento realizado por programa
• Se superó el número de ventanas de mantenimiento
• Se han alcanzado los objetivos de mantenimiento (número y porcentaje).
• Formación y desarrollo de habilidades . Estas métricas aseguran que el personal tenga
las habilidades y la formación para gestionar la tecnología que está bajo su control ,
y también identificará áreas donde aún se requiere capacitación.
6.3.7 Documentación de gestión técnica
La Gerencia Técnica participa en la redacción y mantenimiento de varios

documentos como parte de otros procesos (p. ej. , planificación de capacidad , cambio
Gestión , Gestión de Problemas , etc.). Estos documentos se analizan en
algún detalle en las descripciones relevantes del proceso .
Sin embargo, hay algunos documentos que son específicos de la técnica

Grupos o equipos de gestión que documentarán la gestión y el control de
documentos relacionados con la tecnología bajo su control. Manejo tecnico
La documentación incluye lo siguiente.
6.3.7.1 Documentación técnica
El abastecimiento y el mantenimiento de la documentación técnica para todos los CI es el

responsabilidad de la Dirección Técnica. Éstos incluyen:
• Manuales técnicos
• Manuales de gestión y administración
• Manuales de usuario para CI. Por lo general, estos excluirán al usuario de la aplicación
manuales, que son mantenidos por Application Management .
Página 226
6.3.7.2 Programas de mantenimiento
Estos cronogramas se elaboran y acuerdan durante la fase de Diseño del Servicio.

relacionados con la disponibilidad y la gestión de la capacidad , pero son esencialmente los
propiedad de los distintos departamentos, grupos o equipos de la Dirección Técnica .
Esto se debe a que tienen la experiencia técnica para tecnologías específicas y
es más probable que sepan lo que se necesita para mantenerlos en funcionamiento.
Para obtener más detalles sobre la definición de servicios y programas de mantenimiento

Objetivos de mantenimiento , consulte la publicación ITIL Service Design .
6.3.7.3 Inventario de habilidades
Un inventario de habilidades es un sistema o herramienta que identifica las habilidades necesarias para entregar
y soporte a los servicios de TI y también a las personas que poseen esas habilidades. Habilidades
Los inventarios son más efectivos si están alineados con procesos, arquitectura s
y estándar de desempeño s.
Además, los inventarios de habilidades deben identificar la capacitación disponible para cultivar
cada habilidad debe el personal existente dejar la organización .
Los inventarios de habilidades también se pueden utilizar como parte de la cartera de servicios para evaluar
si se puede prestar un nuevo servicio con el personal existente y los conjuntos de habilidades, o
si es necesario realizar una inversión en personal nuevo o en formación. Habilidades
Por lo tanto, los inventarios pueden contribuir significativamente a la planificación de la capacidad .
La definición y mantenimiento de Skills Inventories requiere una buena interfaz

con los procesos y herramientas de Recursos Humanos en la organización.
Página 227
6.4 Gestión de operaciones de TI
En los negocios, el término ' Gestión de operaciones ' se utiliza para referirse al departamento,
grupo o equipo de personas responsables de realizar el día a día de la organización
actividades operativas , como ejecutar la línea de producción en una fábrica
medio ambiente o la gestión de los centros de distribución y los movimientos de la flota dentro de un
organización logística.
La Gerencia de Operaciones generalmente tiene las siguientes características:
• Hay trabajo para asegurar que un dispositivo, sistema o proceso sea realmente
correr o trabajar (a diferencia de la estrategia o la planificación )
• Aquí es donde los planes se convierten en acciones.
• La atención se centra en las actividades diarias o de corto plazo, aunque debe tenerse en cuenta
que estas actividades generalmente se realizarán y repetirán durante un
período relativamente largo (a diferencia de las actividades puntuales del tipo de proyecto )
• Estas actividades son ejecutadas por personal técnico especializado, que a menudo
tener que someterse a una formación técnica para aprender a realizar cada actividad
• Hay un enfoque en la construcción de acciones repetibles y consistentes que, si
repetido con la frecuencia suficiente con el nivel adecuado de calidad - asegurará la
éxito de la operación
• Aquí es donde se entrega el valor real de la organización y
Medido
• Existe una dependencia de la inversión en equipos o recursos humanos.
o ambos
• El valor generado, debe exceder el costo de la inversión y todos los demás
gastos generales de la organización (como los costos de gestión y marketing) si
el negocio es triunfar.
De manera similar, la Gestión de Operaciones de TI se puede definir como la función

responsable de la gestión y el mantenimiento continuos de los
Infraestructura de TI para garantizar la entrega del nivel acordado de servicios de TI al
negocio.
Las operaciones de TI se pueden definir como el conjunto de actividades involucradas en el día a día.
funcionamiento de la infraestructura de TI con el fin de brindar servicios de TI según lo acordado
niveles para cumplir con los objetivos comerciales establecidos .
6.4.1 Rol de gestión de operaciones de TI
El rol de la Gerencia de Operaciones es ejecutar las actividades en curso y

procedimientos necesarios para administrar y mantener la infraestructura de TI a fin de entregar
y apoyar los servicios de TI en los niveles acordados. Estos ya han sido
se describen en la sección 5, pero se resumen aquí para que sean más completos:
Página 228
• Control de Operaciones , que supervisa la ejecución y seguimiento de la

actividades operativas y eventos en la infraestructura de TI. Esto puede hacerse
con la ayuda de un Puente de Operaciones o Operaciones de Red
Centrar. Además de ejecutar tareas rutinarias de todas las áreas técnicas,
El control de operaciones también realiza las siguientes tareas específicas:
• Gestión de la consola , que se refiere a la definición de la observación central
y capacidad de monitoreo y luego usar esas consolas para ejercitar
actividades de seguimiento y control
• Programación de trabajos o la gestión de trabajos por lotes de rutina o scripts
• Copia de seguridad y restauración en nombre de todos los técnicos y aplicaciones
Equipos y departamentos de gestión y, a menudo, en nombre de los usuarios .
• Gestión de impresión y salida para la clasificación y distribución de
toda impresión centralizada o salida electrónica
• Realización de actividades de mantenimiento en nombre del técnico o
Equipos o departamentos de gestión de aplicaciones .
• Gestión de instalaciones , que se refiere a la gestión de la TI física
entorno , normalmente un centro de datos o salas de informática y recuperación
sitios junto con todo el equipo de energía y enfriamiento. Instalaciones
La gestión también incluye la coordinación de la consolidación a gran escala
proyectos , por ejemplo, consolidación de centros de datos o proyectos de consolidación de servidores .
En algunos casos se subcontrata la gestión de un centro de datos, en los que
caso de Gestión de Instalaciones se refiere a la gestión de la subcontratación
contrato .
Como ocurre con muchos procesos y funciones de gestión de servicios de TI , las operaciones de TI
La gestión juega un papel doble.
• La Gerencia de Operaciones de TI es responsable de ejecutar las actividades y

estándares de desempeño definidos durante el Diseño del Servicio y probados durante
Transición de servicio. En este sentido, el papel de las operaciones de TI es principalmente mantener
el status quo. La estabilidad de la infraestructura de TI y la coherencia de la TI.
service s es una preocupación principal de las operaciones de TI . Incluso operativo
Las mejoras están destinadas a encontrar formas mejores y más sencillas de realizar
la misma cosa.
• Al mismo tiempo, las operaciones de TI son parte del proceso de agregar valor a
las diferentes líneas de negocio y para apoyar la red de valor (ver el
Publicación ITIL Service Strategy ). La capacidad de la empresa para cumplir con sus
objetivo sy seguir siendo competitivo depende del rendimiento y la fiabilidad
del funcionamiento diario de TI. Como tal, la gestión de operaciones de TI
debe ser capaz de adaptarse continuamente a los requisitos y la demanda del negocio .
A la empresa no le importa que las operaciones de TI cumplan con un estándar
procedimiento o que un servidor se desempeñó de manera óptima. Como demanda empresarial y
los requisitos cambian, la gestión de operaciones de TI debe poder mantener
seguirles el ritmo, a menudo desafiando el status quo.
Página 229
Las operaciones de TI deben lograr un equilibrio entre estos roles, lo que requerirá la
siguiente:
• Comprensión de cómo se utiliza la tecnología para proporcionar servicios de TI.

• Comprensión de la importancia relativa y el impacto de esos servicios.
en el negocio
• Procedimientos y manuales que describen la función de las operaciones de TI tanto en la
gestión de la tecnología y la entrega de servicios de TI s
• Un conjunto de métricas claramente diferenciadas para informar a la empresa sobre el
logro de los objetivos del Servicio; e informar a los gerentes de TI sobre la
eficiencia y eficacia de las operaciones de TI
• Todo el personal de operaciones de TI comprende exactamente cómo funciona el
la tecnología afecta la prestación de servicios de TI
• Una estrategia de costos destinada a equilibrar los requisitos de diferentes negocios.
unidades con los ahorros de costos disponibles a través de la optimización de los
tecnología o inversión en nueva tecnología
• Una estrategia de retorno de la inversión basada en el valor, más que en el costo.
6.4.2 Objetivos de la gestión de operaciones de TI
Los objetivos de la gestión de operaciones de TI incluyen:
• Mantenimiento del status quo para lograr la estabilidad de la organización .

procesos y actividades del día a día
• Escrutinio regular y mejoras para lograr un mejor servicio en
costes reducidos, manteniendo la estabilidad
• Aplicación rápida de habilidades operativas para diagnosticar y resolver cualquier TI.
fallas de operaciones que ocurren.
6.4.3 Organización de gestión de operaciones de TI
La Figura 6.1 en la introducción al Capítulo 6 ilustra que Operaciones de TI

La gestión se considera una función por derecho propio, pero que, en muchos casos, el personal
de los grupos de Gestión Técnica y de Aplicaciones forman parte de esta función.
Esto significa que algunos departamentos de gestión técnica y de aplicaciones o

los grupos gestionarán y ejecutarán sus propias actividades operativas . Otros lo harán
delegue estas actividades en un departamento de operaciones de TI dedicado .
No existe un método único para la asignación de actividades, ya que depende de la madurez

y estabilidad de la infraestructura gestionada. Por ejemplo, técnico y
Las áreas de administración de aplicaciones que son bastante nuevas e inestables tienden a administrar
sus propias operaciones. Grupos donde la tecnología o aplicación es estable,
maduros y bien entendidos tienden a estandarizar cada vez más sus operaciones
por lo tanto, se sentirá más cómodo delegando estas actividades.

Página 230
Algunas opciones de cómo estructurar las operaciones de TI se analizan en detalle en la sección

6.7 de esta publicación.
6.4.4 Métricas de gestión de operaciones de TI
La Gestión de Operaciones de TI se mide en términos de su ejecución efectiva de

actividades y procedimientos especificados , así como su ejecución de actividades de proceso .
Ejemplos de estos son los siguientes:
• Finalización exitosa de trabajos programados

• Número de excepciones a actividades y trabajos programados
• Número de datos o restauración del sistema necesarios
• Estadísticas de instalación de equipos, incluida la cantidad de elementos instalados por
tipo, instalaciones exitosas, etc.
• Métricas de proceso s. La gestión de operaciones de TI ejecuta muchos servicios
parte de las métricas del proceso cuando corresponda (consulte la sección sobre cada
• Tiempo de respuesta al evento s
• Incidentes resolución tiempos de incidentes
• Número de incidentes relacionados con la seguridad
• Número de escaladas y motivo de esas escaladas
• Número de cambios implementados y retirados
• Número de lanzamientos implementados, totales y exitosos
• Si se han delegado las actividades de mantenimiento, entonces las métricas relacionadas con
estas actividades también serán apropiadas:
• Las métricas relacionadas con la gestión de instalaciones son amplias, pero normalmente
incluir:
• Costos versus presupuesto relacionados con mantenimiento, construcción, seguridad ,
envío, etc.
• Incidentes relacionados con el edificio, por ejemplo, reparaciones necesarias en la instalación.
• Informes sobre el acceso a la instalación
• Número de eventos e incidentes de seguridad y su resolución
• Estadísticas de uso de energía, especialmente en lo relacionado con cambios en el diseño.
y estrategias de acondicionamiento ambiental
• Eventos o incidencias relacionados con el envío y la distribución.
Página 231
6.4.5 Documentación de gestión de operaciones de TI
Se producen y utilizan varios documentos durante las operaciones de TI

Gestión . Esta lista es un resumen de algunos de los más importantes y no
incluir informes que son producidos por Gestión de Operaciones de TI en nombre de
otros procesos o funciones s.
6.4.5.1 Procedimientos operativos estándar
Los POE son un conjunto de documentos que contienen instrucciones detalladas y actividades
horarios para cada equipo, departamento o grupo de gestión de operaciones de TI.
Estos documentos representan el trabajo de rutina que debe realizarse para cada
dispositivo, sistema o procedimiento . También describen los procedimientos a seguir si
se detecta una excepción o si se requiere un cambio .
Los documentos SOP también podrían usarse para definir niveles estándar de desempeño para
dispositivos o procedimientos. En algunas organizaciones, los documentos SOP se remiten
a en el OLA. En lugar de enumerar medidas de desempeño detalladas en el OLA, un
se inserta una cláusula para referirse a las normas de desempeño en el SOP y cómo
estos serán medidos y reportados.
6.4.5.2 Registros de operaciones
Cualquier actividad que se lleve a cabo como parte de las operaciones de TI debe registrarse para un
varias razones, que incluyen:
• Se pueden utilizar para confirmar la finalización satisfactoria de trabajos específicos o

ocupaciones
• Se pueden utilizar para confirmar que se entregó un servicio de TI según lo acordado.
• Gestión de problemas puede utilizarlos para investigar la causa raíz de
incidentes
• Son la base para los informes sobre el desempeño de las operaciones de TI.
Equipos y departamentos de gestión.
El formato de estos registros es tan variado como el número de sistemas y operaciones

Equipos o departamentos de gestión . Los ejemplos de registros de operaciones incluyen
siguiente:
• Registros del sistema operativo almacenados en cada dispositivo

• Registros de actividad de la aplicación almacenados en un archivo en el servidor de aplicaciones
• Registros de eventos almacenados en el servidor de la herramienta de monitoreo
• Registros de utilización de dispositivos clave
• Registros de acceso físico que registran quién accedió a edificios seguros y cuándo
Página 232
• Registros manuscritos de acciones realizadas por operadores. Esto debe ser en un

cuaderno de bitácora o carpeta formal, numerado y almacenado en un entorno seguro .
Las comprobaciones deben garantizar que las páginas no se eliminen.
Es necesario establecer una política como parte de los procedimientos operativos estándar para establecer cuánto tiempo necesitan los registros.
guardar, cómo se archivan y cuándo se pueden eliminar. Estas politicas
tendrá en cuenta los requisitos legales y de cumplimiento s. Las políticas deben
también especifique los parámetros para el almacenamiento adecuado y las estrategias de respaldo para almacenar
y recuperar archivos de registro.
6.4.5.3 Informes y horarios de turnos
Los horarios de turnos son documentos que describen las actividades exactas que deben
llevado a cabo durante el turno . También enumerarán todas las dependencias y actividades
secuencias. Probablemente habrá más de un horario de turnos, donde cada
team tendrá una versión para sus propios sistemas . Es importante que todos los horarios estén
coordinado antes del inicio del turno. Esto generalmente lo hace una persona que está
especializada en la programación de turnos, con la ayuda de herramientas de programación.
Un horario de turnos puede consistir en una serie de elementos de rutina que se incluyen en
el SOP. En este caso, los elementos podrían simplemente enumerarse brevemente con una referencia a
la sección o página del POE.
La mayoría de los horarios de turnos toman la forma de una lista de verificación donde los operadores pueden marcar
el artículo a medida que se completa, junto con el tiempo de finalización. Esto lo hace
Fácil de ver el progreso de las actividades y también ayuda a identificar cualquier potencial
problemas en los que los trabajos tardan demasiado.
Los informes de turnos son una forma de registro de operaciones, pero tienen las funciones adicionales como
sigue:
• Para registrar eventos importantes y acciones que ocurrieron durante el turno.

• Formar parte del traspaso entre jefes de turno
• Para reportar cualquier excepción a Mantenimiento Servicio Objetivo s
• Para identificar cualquier actividad incompleta que podría resultar en degradación
rendimiento en cualquier servicio durante las próximas horas de servicio .
6.4.5.4 Programa de operaciones
Los horarios de operaciones son similares a los horarios de turnos, pero cubren todos los aspectos de
Operaciones de TI a alto nivel. Este programa incluirá una descripción general de todos
cambios planificados, mantenimiento, trabajos de rutina y trabajo adicional, junto con
información sobre próximos eventos comerciales o de proveedores. Las operaciones
El horario se utiliza como base para la reunión diaria de operaciones y es el maestro
referencia para todos los gerentes de operaciones de TI para rastrear el progreso y detectar
excepciones.
Página 233
6.5 Gestión de aplicaciones
La administración de aplicaciones es responsable de administrar las aplicaciones en todo

su ciclo de vida . La función de gestión de aplicaciones la realiza cualquier
departamento, grupo o equipo involucrado en la gestión y soporte operativo
aplicaciones. La gestión de aplicaciones también juega un papel importante en el diseño ,
testeo y mejora de aplicaciones que forman parte de los servicios de TI . Como tal,
puede estar involucrado en proyectos de desarrollo , pero generalmente no es el mismo que el
Equipos de desarrollo de aplicaciones.
6.5.1 Rol de gestión de aplicaciones
La gestión de aplicaciones es para las aplicaciones lo que la gestión técnica es para el

Infraestructura de TI . La gestión de aplicaciones juega un papel en todas las aplicaciones,
ya sea comprado o desarrollado internamente. Una de las decisiones clave que
contribuir es la decisión de comprar una aplicación o construirla (esto es
discutido en detalle en la publicación Service Design ). Una vez que se toma esa decisión
realizada, la gestión de aplicaciones desempeñará un doble papel:
• Es el custodio de los conocimientos técnicos y la experiencia relacionados con

gestión de aplicaciones. En esta función de Gestión de aplicaciones, trabajando
junto con la Gerencia Técnica, asegura que el conocimiento
necesario para diseñar, probar , gestionar y mejorar los servicios de TI.
desarrollado y refinado.
• Proporciona los recursos reales para respaldar el ciclo de vida de ITSM . En este papel,
La gestión de aplicaciones garantiza que los recursos estén capacitados de manera efectiva
y desplegado para diseñar, construir , hacer la transición, operar y mejorar el
tecnología necesaria para ofrecer y respaldar los servicios de TI.
Al desempeñar estos dos roles, la Administración de aplicaciones puede garantizar que

la organización tiene acceso al tipo y nivel adecuados de recursos humanos para
administrar aplicaciones y así cumplir con los objetivos comerciales . Esto comienza en Servicio
Estrategia y se amplía en Diseño de servicios, se prueba en Transición de servicios y
refinado en Mejora Continua del Servicio (vea otras publicaciones de ITIL en este
serie).
Parte de esta función es garantizar un equilibrio entre el nivel de habilidad y el costo de

estos recursos.
Además de estos dos roles de alto nivel, la Gestión de aplicaciones también realiza
los siguientes dos roles específicos:
• Brindar orientación a las operaciones de TI sobre la mejor manera de llevar a cabo

gestión operativa permanente de aplicaciones. Este papel es en parte
llevada a cabo durante el proceso de Diseño del Servicio , pero también es parte de
Página 234
comunicación diaria con la Gerencia de Operaciones de TI mientras buscan

lograr estabilidad y rendimiento óptimo .
• La integración del ciclo de vida de la gestión de aplicaciones en el ITSM
Ciclo vital. Esto se analiza a continuación.
Los objetivos, actividades y estructuras que permiten a la Gestión de Aplicaciones

desempeñar estos roles de manera efectiva se discuten a continuación.
6.5.2 Objetivos de la gestión de aplicaciones
Los objetivos de la Gestión de aplicaciones son apoyar a la organización

procesos de negocio ayudando a identificar funcional y manejabilidad
requisitos para el software de aplicación, y luego para ayudar en el diseño y
despliegue de esas aplicaciones y el apoyo y mejora continuos de
esas aplicaciones.
Estos objetivos se logran mediante:
• Aplicaciones bien diseñadas, resistentes y rentables

• Asegurarse de que la funcionalidad requerida esté disponible para lograr la
resultado comercial
• La organización de habilidades técnicas adecuadas para mantener operacional
aplicaciones en óptimas condiciones
• Uso rápido de habilidades técnicas para diagnosticar y resolver rápidamente cualquier problema técnico.
fallas que ocurren.
6.5.3 Principios de gestión de aplicaciones
6.5.3.1 ¿Construir o comprar?
Una de las decisiones clave en la gestión de aplicaciones es si comprar un

aplicación que admita la funcionalidad requerida, o si construir el
aplicación específicamente para los requisitos de la organización . Estas decisiones son
a menudo realizado por un Director Técnico (CTO) o un Comité Directivo, pero
dependen de la información de varias fuentes. Estos se discuten en
detalles en el diseño del servicio , pero se resumen aquí de una aplicación
Perspectiva de la función de gestión .
La administración de aplicaciones ayudará en esta decisión durante el diseño del servicio como
sigue:
• Dimensionamiento de aplicaciones y previsiones de carga de trabajo (consulte la sección 4.6.4)

• Especificación de manejabilidad requisito s
• Identificación de curso costo operativo s
• Requisitos de acceso a datos para informes o integración en otros
aplicaciones
Página 235
• Investigar hasta qué punto la funcionalidad requerida puede ser cumplida por
herramientas existentes, y cuánta personalización será necesaria para lograr
esta
• Estimando el costo de la personalización
• Identificar qué habilidades se requerirán para respaldar la solución (por ejemplo, si un
se adquiere la aplicación, ¿requerirá un nuevo conjunto de empleados o
los empleados existentes estén capacitados para respaldarlo?)
• Requisitos de administración
• Requerimientos de seguridad.
Si la decisión es construir la aplicación, se debe tomar una decisión adicional en

si el desarrollo se subcontratará o se construirá con empleados. Este es
detallado en las publicaciones de Estrategia de servicio y Diseño de servicio, pero hay
algunas consideraciones importantes que afectan el funcionamiento del servicio, por ejemplo:
• ¿Cómo se especificarán y acordarán los requisitos de manejabilidad (p. Ej.

diseñar el monitoreo de aplicaciones y transacciones )? Estas son a veces
olvidado cuando los equipos o departamentos operativos no están representados
en el proyecto
• Cuáles son los Criterios de aceptación para el desempeño operativo ; Cómo y
¿Dónde se probará la solución y quién realizará las pruebas?
• ¿Quién poseerá y administrará la Biblioteca Definitiva para esa aplicación?
• Quién diseñará y mantendrá la gestión operativa y
scripts de administración para estas aplicaciones?
• Quién es responsable de la configuración del medio ambiente y la propiedad y el mantenimiento
los diferentes componentes de la infraestructura ?
• ¿Cómo se instrumentará la solución para que sea capaz de generar
el evento requerido s?
6.5.3.2 Modelos operativos
Un modelo operativo es la especificación del entorno operativo en el que

la aplicación finalmente se ejecutará cuando entre en funcionamiento . Esto se utilizará durante
fases de prueba y transición para simular y evaluar el entorno en vivo . Esta
es una forma de garantizar que la aplicación se pueda dimensionar correctamente y
las condiciones ambientales pueden ser documentadas y comprendidas por todos. los
El modelo operativo debe definirse y utilizarse en las pruebas durante el servicio.
Fases de diseño y transición del servicio respectivamente (consulte Diseño del servicio y
Publicaciones de transición del servicio).
6.5.4 Ciclo de vida de la gestión de aplicaciones
Se ha hecho referencia al ciclo de vida seguido para desarrollar y gestionar aplicaciones

por muchos nombres, incluido el ciclo de vida del software (SLC) y el software
Ciclo de vida de desarrollo (SDLC). Estos son generalmente utilizados por Aplicaciones.
Equipos de desarrollo y sus Project Managers para definir su participación en
Página 236
diseñar, construir, probar, implementar y dar soporte a aplicaciones. Ejemplos de

Estos enfoques son Metodología de diseño y análisis de sistemas estructurados.
(SSADM), método de desarrollo de sistemas dinámicos (DSDM), aplicación rápida
Desarrollo (RAD), etc.
ITIL está principalmente interesado en la gestión general de aplicaciones como parte de TI.
servicios , ya sean desarrollados internamente o comprados a un tercero .
Por esta razón, se ha utilizado el término ciclo de vida de gestión de aplicaciones , ya que
implica una visión más holística.
Esto no debería reemplazar el SDLC, que sigue siendo un enfoque válido utilizado por
desarrolladores, especialmente por empresas de software de terceros. Sin embargo, significa
que debería haber una mayor alineación entre la visión de desarrollo de
aplicaciones y la gestión "en vivo" de esas aplicaciones.
Esto es más difícil en aplicaciones compradas a gran escala, como el correo electrónico, ya que
los desarrolladores no suelen interactuar individualmente con los usuarios de sus aplicaciones .
Sin embargo, el ciclo de vida básico sigue siendo cierto en el sentido de que la aplicación necesita
requisitos , diseño , personalización, operación y despliegue . La optimización es
logrado a través de una mejor gestión, mejoras en la personalización y
actualizaciones.
El ciclo de vida de la gestión de aplicaciones se ilustra a continuación:
Página 237
Figura 6.5 Ciclo de vida de la gestión de aplicaciones
Los procesos de ITSM y los procesos de desarrollo de aplicaciones deben estar alineados como
parte de la estrategia general de prestación de servicios de TI en apoyo del negocio.
El desarrollo y las operaciones de aplicaciones forman parte del mismo ciclo de vida general
y ambos deben participar en todas las etapas, aunque su nivel de participación será
varían según la etapa del ciclo de vida.
Relación entre la gestión de aplicaciones y la gestión de servicios

Ciclo de vida s
El ciclo de vida de la gestión de aplicaciones no debe verse como una alternativa a

el ciclo de vida de la gestión de servicios. Las aplicaciones son parte de los servicios y deben
ser gestionado como tal. Sin embargo, las aplicaciones son una combinación única de
tecnología y funcionalidad y esto requiere un enfoque especializado en cada etapa
del ciclo de vida de la gestión de servicios.
Cada etapa del ciclo de vida de la administración de aplicaciones tiene su propio conjunto específico de
objetivos , actividades, entregables y equipos dedicados. Cada etapa también tiene un
Página 238
Responsabilidad clara de garantizar que sus resultados coincidan con los objetivos específicos.
del ciclo de vida de la gestión de servicios. Diferentes aspectos de la aplicación
La gestión se trata en detalle en cada una de las publicaciones de ITIL, de la siguiente manera:
• Estrategia de servicio : define la arquitectura general de aplicaciones y

infraestructura. Esto incluirá la definición de los criterios para el desarrollo de
vivienda, desarrollo de subcontratación o compra y personalización
aplicaciones. La estrategia de servicio también ayudará a definir el servicio.
Portafolio (incluidas las aplicaciones) que también incluye información sobre el
Retorno de la inversión de las aplicaciones y los servicios que soportan. Por lo tanto
Los requisitos de alto nivel se establecen durante esta fase.
• Diseño de servicios : ayuda a establecer requisitos de funcionalidad y
manejabilidad de aplicaciones y trabaja con equipos de desarrollo para
asegurarse de que cumplan estos objetivos. El diseño del servicio cubre la mayor parte de
Fase de requisitos y participa durante la fase de construcción del
Ciclo de vida de la gestión de aplicaciones.
• Transición del servicio : los equipos de gestión y desarrollo de aplicaciones
involucrado en probar y validar lo que se ha construido y desplegarlo
operativamente.
• Funcionamiento del servicio : cubre la fase de funcionamiento de la aplicación.
Ciclo de vida de la gestión. Estos procesos y estructuras se discuten en
detalle en esta publicación.
• Mejora continua del servicio : cubre la fase de optimización del
Ciclo de vida de la gestión de aplicaciones. servicio de Mejoramiento contínuo
mide la calidad y relevancia de las aplicaciones en funcionamiento y
proporciona recomendaciones sobre cómo mejorar las aplicaciones si hay una
claro retorno de la inversión para hacerlo.
6.5.4.1 Requisitos
Esta es la fase durante la cual se cumplen los requisitos para una nueva aplicación.
recopilados, en función de las necesidades comerciales de la organización . Esta fase está activa
principalmente durante la fase de diseño de servicios del ciclo de vida de ITSM.
Hay seis tipos de requisitos para cualquier aplicación, ya sea que se esté desarrollando
interna, subcontratada o comprada:
• Los requisitos funcionales son los que se requieren específicamente para soportar un
función comercial particular
• Requisitos de manejabilidad , vistos desde un Service Management
perspectiva, abordar la necesidad de una respuesta receptiva, disponible y segura
servicio y ocuparse de cuestiones como la implementación , las operaciones, el sistema
gestión y seguridad
• Los requisitos de usabilidad son aquellos que abordan las necesidades del usuario final ,
y dar como resultado características del sistema que facilitan su facilidad de uso
Página 239
• Requisitos arquitectónicos, especialmente si esto requiere un cambio a los existentes.

estándar de arquitectura s
• Requisitos de interfaz, donde hay dependencias entre los
aplicaciones o herramientas y la nueva aplicación
• Requisitos de nivel de servicio , que especifican cómo debe
realizar, la calidad de su producción y cualquier otro aspecto cualitativo
medido por el usuario o cliente .
6.5.4.2 Diseño
Esta es la fase durante la cual los requisitos se traducen en especificaciones .
El diseño incluye el diseño de la aplicación en sí y el diseño de la
entorno o modelo operativo en el que debe ejecutarse la aplicación.
Las consideraciones arquitectónicas son el aspecto más importante de esta fase, ya que
Pueden impactar en la estructura y el contenido tanto de la aplicación como operativa.
modelo. Consideraciones arquitectónicas para la aplicación (diseño de la aplicación
arquitectura) y consideraciones arquitectónicas para el modelo de operación (diseño de
la arquitectura del sistema) están estrechamente relacionados y deben alinearse.
En el caso del software comprado, la mayoría de las organizaciones no podrán acceder directamente
entrada al diseño del software (que ya ha sido construido). Sin embargo lo és
Es importante que la Gestión de aplicaciones pueda proporcionar retroalimentación a los
proveedor de software sobre la funcionalidad, la capacidad de gestión y el rendimiento del
software. Esto, a su vez, será asumido por el proveedor de software como parte del
mejora continua del software.
Parte del proceso de evaluación del software comprado debe incluir una
evaluación de si el proveedor responde a dicha retroalimentación. Al mismo
tiempo, deben asegurarse de que haya un equilibrio entre ser receptivo y
cambiando su software tanto que es disruptivo o que cambia algunos aspectos básicos
funcionalidad.
El diseño del software comprado también incluirá el diseño de cualquier personalización.

eso es requerido. De especial importancia aquí es una evaluación de si el futuro
La versión del software admitirá la personalización.
6.5.4.3 Construir
En la fase de construcción se realizan tanto la aplicación como el modelo operativo

listo para el despliegue. Los componentes de la aplicación están codificados o adquiridos, integrados
y probado.
Tenga en cuenta que la prueba no es una etapa separada en el ciclo de vida , aunque es una
actividad discreta , y aunque las pruebas se realizan independientemente tanto de la
desarrollo y actividades operativas. Sin las fases de construcción e implementación,
Página 240
no habría nada que probar y, sin probar, no habría control

sobre lo desarrollado y desplegado.
Las pruebas son un componente integral de las fases de construcción e implementación como un
validación de la actividad y el resultado de esas fases, incluso si utiliza diferentes
medio ambiente y personal. La prueba en la fase de construcción se centra en si el
La aplicación cumple con sus especificaciones de funcionalidad y capacidad de administración. A menudo el
Se hace una distinción entre un entorno de desarrollo y de prueba . La prueba
El entorno permite probar la combinación de aplicaciones y operaciones
modelo. Las pruebas se tratan en la publicación ITIL Service Transition.
Para el software comprado, esto implicará la compra real de la aplicación,
cualquier
Cualquiermiddleware necesario
personalización y elnecesaria
que sea hardwaredeberá
y el equipo de red
realizarse relacionados.
aquí, al igual que la creación.
de tablas, categorías, etc. que se utilizarán. Esto se hace a menudo como piloto.
implementación por parte del equipo o departamento de gestión de aplicaciones correspondiente .
6.5.4.4 Implementar
En esta fase se despliegan tanto el modelo operativo como la aplicación . los

El modelo operativo está incorporado en el entorno de TI existente y el
La aplicación se instala en la parte superior del modelo operativo, utilizando la versión y
Proceso de gestión de la implementación descrito en la Transición del servicio ITIL
publicación.
Las pruebas también se llevan a cabo durante esta fase, aunque aquí el énfasis está en
Asegurar que el proceso y los mecanismos de implementación funcionen eficazmente, p.
probar si la aplicación sigue funcionando según las especificaciones después de haber sido
descargado e instalado. Esto se conoce como soporte vital temprano y cubre una
período de garantía definido que prueba, validación y seguimiento de un nuevo
aplicación o servicio durante ese período. El soporte vital temprano está cubierto en
detalles en la publicación Transición del servicio.
6.5.4.5 Operar
En la fase de operación, el servicio de TI s organización opera la aplicación como

parte de la prestación de un servicio requerido por la empresa. La actuación del
La aplicación en relación con el servicio general se mide continuamente contra el
Niveles de servicio e impulsores clave del negocio . Es importante distinguir que
las aplicaciones en sí mismas no equivalen a un servicio. Es común en muchos
organizaciones para referirse a las aplicaciones como "servicios"; sin embargo, las aplicaciones son
uno de los muchos componentes necesarios para proporcionar un servicio comercial .
La fase de funcionamiento no es exclusiva de las aplicaciones y se analiza a lo largo

esta publicación, con una lista más detallada de actividades en la sección 6.5.5 a continuación.
Página 241
6.5.4.6 Optimizar
En la fase de optimización , los resultados del rendimiento del nivel de servicio

las mediciones se miden, analizan y actúan sobre ellas. Posibles mejoras
se discuten y se inician desarrollos si es necesario. Las dos estrategias principales
en esta fase son mantener y / o mejorar los niveles de servicio y reducir
costo . Esto podría conducir a una iteración en el ciclo de vida o al retiro justificado de un
solicitud.
Una cosa importante para recordar sobre el ciclo de vida de la administración de aplicaciones es
que, por ser circular, una misma aplicación puede residir en diferentes fases de
el ciclo de vida al mismo tiempo. Por ejemplo, cuando la próxima versión de un
se está diseñando la aplicación y se está implementando la versión actual, el
Es posible que la versión anterior todavía esté en funcionamiento en partes de una organización. Esta
obviamente requiere un fuerte control de versión, configuración y lanzamiento .
Fases particulares pueden tomar más tiempo o parecer más importantes que otras, pero
todos son cruciales. Cada aplicación debe pasar por todas ellas al menos una vez
y, debido a la naturaleza circular del ciclo de vida, pasará por más
de una vez.
Este enfoque también admite enfoques de desarrollo iterativos, donde el software

se está desarrollando continuamente en pasos incrementales. Cada paso sigue el
ciclo de vida y la aplicación se construye en incrementos, utilizando las prioridades comerciales como un
conductor.
La buena comunicación es la clave, ya que una aplicación se abre paso a través de

fases del ciclo de vida. Es fundamental que se transmita información de alta calidad
por quienes manejan la solicitud en una fase de su existencia a quienes manejan
en la siguiente fase. También es importante que una organización controle la calidad
del ciclo de vida de la gestión de aplicaciones. Cambios en el ciclo de vida, por ejemplo en
la forma en que una organización pasa información entre las diferentes fases,
afectar su calidad. Comprender las características de cada fase del
El ciclo de vida de la gestión de aplicaciones es fundamental para mejorar la calidad del conjunto.
Los métodos y herramientas utilizados en una fase pueden tener un impacto en otras, mientras que
la optimización de una fase podría sub-optimizar la totalidad.
6.5.5 Actividades genéricas de gestión de aplicaciones
Si bien la mayoría de los equipos o departamentos de administración de aplicaciones se dedican a

aplicaciones específicas o conjuntos de aplicaciones, hay una serie de actividades que
Ellos tienen en común. Éstos incluyen:
• Identificar el conocimiento y la experiencia necesarios para gestionar y operar

aplicaciones en la prestación de servicios de TI . Este proceso comienza durante el
La fase de estrategia de servicio , se amplía en detalle en Diseño de servicio y se
Página 242
ejecutado en Operación de servicio . Continua evaluación y actualización de

estas habilidades se realizan durante la mejora continua del servicio .
• Iniciar programas de formación para desarrollar y perfeccionar las habilidades en el
recursos adecuados de gestión de aplicaciones y mantenimiento de la formación
registros para estos recursos .
• Reclutar o contratar recursos con habilidades que no se pueden desarrollar
internamente, o donde no hay suficientes personas para realizar las tareas requeridas.
Actividades de gestión de aplicaciones.
• Diseño e impartición de formación al usuario final . La formación se puede desarrollar y
entregado por el desarrollo de la aplicación o la aplicación
Grupos de administración, o por un tercero , pero la administración de aplicaciones es
responsable de garantizar que la formación se lleve a cabo según corresponda.
• Abastecimiento para actividades específicas donde las habilidades requeridas no están disponibles
internamente o en el mercado abierto, o donde sea más rentable hacerlo.
• Definición de estándares utilizados en el diseño de nuevas arquitecturas y
participación en la definición de las arquitecturas de la aplicación durante el Servicio
Procesos estratégicos.
• Investigación y desarrollo de soluciones que pueden ayudar a expandir el Servicio.
Portafolio o que se puede utilizar para simplificar o automatizar las operaciones de TI ,
reduzca los costos o aumente los niveles de servicio de TI.
• Implicación en el diseño y construcción de nuevos servicios. Todas las aplicaciones
Los equipos o departamentos de gestión contribuirán al diseño de la
Arquitectura técnica y estándares de desempeño para servicios de TI. En
Además también serán responsables de especificar la operativa
actividades necesarias para gestionar aplicaciones de forma continua.
• Participación en los proyectos , no solo durante el proceso de Diseño del Servicio , sino
también para proyectos operativos o de mejora continua del servicio , como
Actualizaciones del sistema operativo, proyectos de consolidación de servidores o
se mueve.
• Diseñar y realizar pruebas de funcionalidad, rendimiento y
la capacidad de gestión de los servicios de TI (teniendo en cuenta que las pruebas deben
controlado y realizado por un probador independiente - ver Servicio
Publicación de transición ).
• La disponibilidad y la gestión de la capacidad dependen de la aplicación
Gestión por contribuir al diseño de aplicaciones para cumplir con los
Niveles de servicio requeridos por la empresa. Esto significa que el modelado y
La previsión de la carga de trabajo a menudo se realiza junto con
Recursos de gestión de aplicaciones.
• Asistencia en la evaluación de riesgos , identificación de servicios y sistemas críticos
dependencias y definir e implementar contramedidas .
• Gestión de proveedores. Muchos departamentos o grupos de administración de aplicaciones
son los únicos que saben exactamente qué se requiere de un proveedor y cómo
para medirlos y gestionarlos. Por esta razón, muchas organizaciones confían
sobre la gestión de aplicaciones para gestionar los contratos con proveedores de
aplicación s. Si este es el caso, es importante asegurarse de que estos
Las relaciones se gestionan como parte del proceso SLM .
Página 243
• Participación en la definición de estándares de Gestión de Eventos y especialmente

en la instrumentación de aplicaciones para la generación de información significativa
evento s.
• La gestión de aplicaciones como función proporciona los recursos que
ejecutar el proceso de Gestión de Problemas . Es su experiencia técnica
y conocimientos que se utilizan para diagnosticar y resolver problemas . Tambien es
su relación con los proveedores que se utiliza para escalar y dar seguimiento
con equipos o departamentos de soporte de proveedores.
• Los recursos de gestión de aplicaciones participarán en la definición de codificación
sistemas que se utilizan en la gestión de incidentes y problemas (p. ej.
Categorías).
• Los recursos de gestión de aplicaciones se utilizan para respaldar el problema
Gestión en la validación y mantenimiento de la KEDB junto con la
Equipos de desarrollo de aplicaciones.
• La gestión del cambio se basa en el conocimiento técnico y la experiencia para
evaluar los cambios y muchos cambios serán construidos por la aplicación
Equipos de gestión.
• La gestión de versiones exitosa depende de la participación de
Personal de gestión de aplicaciones. De hecho, con frecuencia son los conductores del
Proceso de Release Management para sus aplicaciones.
• La gestión de aplicaciones definirá, gestionará y mantendrá los atributos y
relaciones de los CI de aplicación en el CMS.
• La gestión de aplicaciones participa en la mejora continua del servicio.
procesos, particularmente en la identificación de oportunidades de mejora y
luego en ayudar a evaluar soluciones alternativas.
• La gestión de aplicaciones garantiza que todos los sistemas y
La documentación está actualizada y se utiliza correctamente. Esto incluye asegurar
que todos los manuales de diseño , gestión y usuario estén actualizados y
completa y que el personal y los usuarios de Gestión de aplicaciones están familiarizados
con su contenido.
• Colaboración con la Gerencia Técnica en la realización de Necesidades de Capacitación
Análisis y mantenimiento de inventarios de competencias.
• Ayudar a la gestión financiera de TI a identificar el costo de la
gestión de aplicaciones.
• Participación en la definición de las actividades operativas realizadas como parte de TI
Jefe de operaciones. Muchos departamentos de gestión de aplicaciones,
grupos o equipos también realizan las actividades operativas como parte de un
organización ‘s Gestión de Operaciones de TI función.
• Entrada y mantenimiento de políticas de configuración de software .
• Junto con los equipos de Desarrollo de Software, la definición y
mantenimiento de documentación relacionada con aplicaciones. Estos incluirán
manuales de usuario , manuales de administración y gestión, así como cualquier
Procedimientos operativos estándar necesarios para gestionar los aspectos operativos de la aplicación .
Página 244
Se necesitarán equipos o departamentos de gestión de aplicaciones para todas las

aplicaciones. La naturaleza exacta del rol variará dependiendo de la
aplicaciones admitidas, pero es probable que las responsabilidades genéricas incluyan:
• Soporte de tercer nivel para incidentes relacionados con las aplicaciones cubiertas por
ese equipo o departamento
• Participación en los planes de prueba de funcionamiento y problemas de implementación
• Seguimiento de errores de aplicaciones y gestión de parches (correcciones de codificación para
código, transportes / parches para código de terceros)
• Participación en cuestiones de compatibilidad y operatividad de la aplicación, como
diseño de códigos de error , mensajes de error, ganchos de gestión de eventos
• Tamaño y rendimiento de la aplicación ; métricas de volumen y pruebas de carga, etc.
Esto es en apoyo de los procesos de gestión de la capacidad y la disponibilidad.
• Participación en el desarrollo de políticas de lanzamiento
• Identificación de mejoras al software existente, tanto desde un
perspectiva de funcionalidad y manejabilidad.
6.5.6 Organización de gestión de aplicaciones
Aunque todos los departamentos, grupos o equipos de Gestión de aplicaciones se desempeñan

actividades similares, cada aplicación o conjunto de aplicaciones tiene un conjunto diferente de
requisitos operativos y de gestión s. Ejemplos de estas diferencias
incluir:
• El propósito de la aplicación. Cada aplicación fue desarrollada para

cumplir con un conjunto específico de objetivos , generalmente objetivos comerciales . Para eficaz
apoyo y mejora, el grupo que gestiona esa aplicación necesita
tener una comprensión completa del contexto empresarial y cómo
la aplicación se utiliza para cumplir sus objetivos. Esto a menudo se logra mediante
Analistas de negocio cercanos al negocio y responsables de
Asegurar que los requisitos comerciales se traduzcan de manera efectiva en
especificación de la aplicación s. Los analistas de negocios deben reconocer que
Los requisitos comerciales deben traducirse tanto en funcional como en
especificación de manejabilidad s.
• La funcionalidad de la aplicación. Cada aplicación está diseñada para
trabajar de una manera diferente y realizar diferentes funciones en diferentes momentos.
• La plataforma en la que se ejecuta la aplicación. Aunque la plataforma es
generalmente administrado por un equipo o departamento de Gerencia Técnica , cada
de ellos afecta la forma en que una aplicación necesita ser administrada y
operado.
• El tipo o marca de tecnología utilizada. Incluso las aplicaciones que tienen
Funcionalidad similar opera de manera diferente en diferentes bases de datos o plataformas.
Estas diferencias deben entenderse para gestionar la
aplicación con eficacia.
Página 245
Aunque las actividades para gestionar estas aplicaciones son genéricas, las
El horario de actividades y la forma en que se realizan serán diferentes. Para esto
razón, los equipos y departamentos de administración de aplicaciones tienden a estar organizados
según las categorías de aplicaciones que admiten. Ejemplos típicos de
Las organizaciones de gestión de aplicaciones incluyen:
• Aplicaciones financieras. En organizaciones más grandes donde una serie de

Se utilizan diferentes aplicaciones para diferentes aspectos de Finanzas.
Gestión , puede haber varios departamentos, grupos o equipos
gestionar estas aplicaciones, por ejemplo, deudores y acreedores, análisis de edad,
Libro mayor, etc.
• Aplicaciones de mensajería y colaboración
• Aplicaciones de recursos humanos
• Aplicaciones de apoyo a la fabricación
• Automatización de fuerza de ventas
• Aplicaciones de procesamiento de pedidos de venta
• Aplicaciones de marketing y call center
• Aplicaciones específicas de la empresa (por ejemplo, atención médica, seguros, banca, etc.)
• Aplicaciones de TI, como Service Desk , Enterprise System Management ,
etc.
• Portales web
• Las compras en línea.
Página 246
6.5.6.1 Roles organizacionales
Tradicionalmente, los equipos y departamentos de Gestión y Desarrollo de Aplicaciones

han sido unidades autónomas. Cada uno gestiona su propio entorno en su propio
manera y cada uno tiene una interfaz separada para el negocio. Esto se ilustra en
Cuadro 6.2.
Desarrollo de aplicaciones Gestión de aplicaciones
Enfoque primario Construyendo funcionalidad para su cliente . Céntrese en cuál es la funcionalidad

Lo que hace la aplicación es más así como cómo entregarlo.
importante para ellos que cómo se opera
Aspectos de manejabilidad del
aplicación, es decir, cómo garantizar
estabilidad y rendimiento del
solicitud
administración La mayor parte del trabajo de desarrollo se realiza en La mayor parte del trabajo se realiza como parte de
modo proyectos donde el enfoque está en entregar Procesos repetibles y continuos. A
unidades específicas de trabajo según la especificación , en número relativamente pequeño de personas
tiempo y dentro del presupuesto . trabajar en proyectos.
Esto significa que a menudo es difícil para Esto significa que es muy difícil
los desarrolladores a entender y acumulación de para que el personal operativo se involucre
operaciones en curso, especialmente porque en proyectos de desarrollo, ya que
no están disponibles para el soporte del los aleja de su 'real
aplicación una vez que hayan pasado a trabajos'
el proximo proyecto
Medición El personal es recompensado por su creatividad y por El personal es recompensado por su coherencia
completar un proyecto para que puedan y para prevenir inesperados
pasar al siguiente proyecto evento sy no(por
funcionalidad autorizado
ejemplo, campanas y
silbidos 'agregados por los desarrolladores)
Costo Los proyectos de desarrollo son relativamente fáciles Los costos de administración continuos son
cuantificar ya que se conocen los recursos a menudo mezclado con los costos de
y es fácil vincular sus gastos a una otros servicios de TI desde recurso s
aplicación específica o servicio de TI a menudo se comparten entre varias TI
servicios y aplicaciones
Ciclo de vida s El personal de desarrollo se centra en el software Personal involucrado en

Ciclos de vida de desarrollo, que destacan la gestión normalmente solo controla
las dependencias para el éxito una o dos fases de estos
operación , pero no asigna responsabilidad ciclo de vida s - Operación y
para éstos Mejora
Tabla 6.2 Roles organizacionales
Durante los últimos años, estos dos mundos han sido reunidos por
movimientos recientes hacia enfoques orientados a objetos y SOA, junto con el crecimiento
presión de la empresa para ser más receptivo y fácil de trabajar.
Página 247
Esto significa que el desarrollo de aplicaciones tendrá una mayor responsabilidad por el
el funcionamiento exitoso de las aplicaciones que diseñan , mientras que la gestión de aplicaciones
tendrá una mayor implicación en el desarrollo de aplicaciones.
Esto no cambia el rol fundamental de cada grupo, pero sí requiere un

enfoque más integrado del SLC. También significará que la salida de
El desarrollo de aplicaciones será más comercializado y esa aplicación
La gerencia estará más involucrada en los proyectos de desarrollo.
Esto requerirá los siguientes cambios:
• Una única interfaz para el negocio para todas las etapas del ciclo de vida y un
común requisito s y especificación -setting proceso .
• Un cambio en la forma en que se mide al personal de Desarrollo y Gestión.
Los equipos de desarrollo deben ser responsables en parte de los defectos de diseño.
que crean interrupciones operativas . El personal de gestión debe mantenerse en parte
responsable de la contribución a la arquitectura técnica y
diseño de manejabilidad de aplicaciones.
• Un único proceso de Gestión del Cambio para ambos grupos, con Cambio
El control en cada grupo está subordinado a la autoridad general de Cambio.
Gestión (consulte la publicación Transición del servicio ).
• Un mapeo claro de las actividades de Desarrollo y Gestión en el
ciclo de vida, que se ilustra a un alto nivel en la Figura 6.5. El exacto
actividades y cómo interactúan deben definirse en cada organización ,
aunque se dan algunas pautas genéricas en cada uno de los ITIL
Publicaciones.
• Enfoque mayor en la integración de la funcionalidad y capacidad de gestión de requisitos s
al principio del proyecto.
Página 248
Figura 6.6 Función de los equipos en el ciclo de vida de la gestión de aplicaciones
La figura 6.6 muestra un ciclo de vida de administración de aplicaciones común con participación
de ambos grupos. En este diagrama, está claro que el desarrollo de aplicaciones será
impulsando algunas fases con aportes de Gestión de aplicaciones. En otros casos
La gestión de aplicaciones impulsará la fase con aportes y apoyo de
Desarrollo de aplicaciones. Ambos grupos están subordinados al Servicio de TI
La estrategia de la organización y sus esfuerzos se coordinan a través del Servicio.
Mecanismos y procesos de transición .
6.5.7 Roles y responsabilidades de la gestión de aplicaciones
6.5.7.1 Gerentes de aplicaciones / líderes de equipo
Un administrador de aplicaciones o líder de equipo (según el tamaño y / o

importancia del equipo o departamento y la aplicación que apoyan, y la
Página 249
estructura y cultura de la organización ) serán necesarios para cada una de las aplicaciones
equipos o departamentos. El rol :
• Asumir la responsabilidad general del liderazgo, el control y la toma de decisiones de

el equipo o departamento de aplicaciones
• Proporcionar conocimiento técnico y liderazgo en las aplicaciones específicas.
actividades de apoyo cubiertas por el equipo o departamento
• Asegurarse de que los niveles de formación, conciencia y experiencia técnicos necesarios
mantenido dentro del equipo o departamento relevante para las aplicaciones
siendo apoyados y procesos que se utilizan
• Involucrar la comunicación continua con los usuarios y los clientes con respecto a
Rendimiento de la aplicación y requisitos cambiantes del negocio.
• Informar a la alta dirección sobre todas las cuestiones relevantes para las aplicaciones.
siendo apoyado
• Realice la gestión de línea para todos los miembros del equipo o del departamento.
6.5.7.2 Analista / Arquitecto de aplicaciones
Los analistas y arquitectos de aplicaciones son responsables de hacer coincidir los requisitos con
especificación de la aplicación s. Las actividades específicas incluyen:
• Trabajar con usuarios, patrocinadores y todas las demás partes interesadas para determinar su
necesidades en evolución
• Trabajar con la Gerencia Técnica para determinar el nivel más alto de
requisitos del sistema requeridos para cumplir con los requisitos comerciales dentro
limitaciones presupuestarias y tecnológicas
• Realizar análisis de costo-beneficio para determinar el más apropiado
medios para cumplir con el requisito establecido
• El desarrollo del Modelo Operacional s que va a asegurar el uso óptimo de los recursos s
y el nivel apropiado de desempeño
• Asegurar que las aplicaciones estén diseñadas para ser administradas de manera efectiva
La arquitectura tecnológica de la organización , las habilidades y herramientas disponibles.
• Desarrollar y mantener estándares para el tamaño y el rendimiento de las aplicaciones .
modelado , etc.
• Generar un conjunto de requisitos de prueba de aceptación , junto con el
diseñadores, ingenieros de pruebas y el usuario , que determinan que todos los
Se han cumplido requisitos de alto nivel con respecto a los aspectos funcionales y
manejabilidad
• Entrada en el diseño de los datos de configuración necesarios para administrar y rastrear
la aplicación de forma eficaz.
Se necesitará un número apropiado de analistas de aplicaciones para cada uno de los

Equipos o departamento de gestión de aplicaciones para realizar las actividades genéricas
descrito en el párrafo 6.5.5.
Página 250
Las formas en que se pueden organizar los grupos de administración de aplicaciones y la

opciones disponibles, se discuten con cierto detalle en la sección 6.7 a continuación.
6.5.8 Métricas de gestión de aplicaciones
Las métricas para la gestión de aplicaciones dependerán en gran medida de qué aplicaciones se
siendo administrado, pero algunas métricas genéricas incluyen:
• Medición de productos acordados. Estos podrían incluir:

• Capacidad de los usuarios para acceder a la aplicación y su funcionalidad.
• Los informes y archivos se transmiten a los usuarios.
• Tasas de transacción y disponibilidad para transacciones comerciales críticas
• Capacitación de Service Desk
• Grabación de la resolución de problemas en el KEDB
• Medidas de usuario de la calidad de los resultados según se define en los SLA.
• Métricas de proceso. Los equipos de gestión técnica ejecutan muchos servicios
parte de las métricas del proceso cuando sea apropiado (consulte la sección sobre cada
• Tiempo de respuesta a eventos y tasas de finalización de eventos
• Tiempos de resolución de incidentes para soporte de segunda y tercera línea
• Estadísticas de resolución de problemas
• Número de escaladas y motivo de esas escaladas
• Número de cambios implementados y retirados
• Número de lanzamientos implementados, totales y exitosos, incluidos
Asegurar el cumplimiento de las Políticas de divulgación de la organización.
• Problemas de seguridad detectados y resueltos
• Utilización real del sistema contra los pronósticos del Plan de capacidad (donde el
equipo ha contribuido al desarrollo del plan )
• Rendimiento de la aplicación . Estas métricas se basan en el diseño del servicio.
especificaciones y estándares de rendimiento técnico establecidos por los proveedores y
normalmente estará contenido en OLA o SOP. Las métricas reales variarán según
aplicación, pero es probable que incluya:
• Tiempo de respuesta s
• Disponibilidad de la aplicación , que es útil para medir el equipo o
rendimiento de la aplicación , pero no debe confundirse con el servicio
Disponibilidad, que requiere la capacidad de medir el total
disponibilidad del servicio, y puede utilizar las cifras de disponibilidad para un
número de individuales del sistema s o componentes s
• Integridad de los datos y los informes.
• Medición de la actividad de mantenimiento , que incluye:
Página 251

• Es probable que los equipos de administración de aplicaciones trabajen en estrecha colaboración con
Los equipos de desarrollo de proyecto s , y las métricas apropiadas se deben utilizar
para medir esto, incluyendo:
• Tiempo dedicado a proyectos
• Satisfacción del cliente y del usuario con el resultado del proyecto.
• Costo de participación en el proyecto.
• Formación y desarrollo de habilidades . Estas métricas aseguran que el personal tenga
las habilidades y la formación para gestionar la tecnología que está bajo su control ,
y también identificará áreas donde aún se requiere capacitación.
6.5.9 Documentación de gestión de aplicaciones
Se producen y utilizan varios documentos durante la gestión de aplicaciones.

Esta lista es un resumen de algunos de los más importantes y no incluye
informes o documentos producidos por Application Management en nombre de
otros procesos o funciones (por ejemplo, RFC, documentación de errores conocidos , versión
Registros , etc.). Tenga en cuenta que los documentos deben controlarse como CI y estar relacionados con
las aplicaciones relevantes o los equipos de gestión de aplicaciones.
6.5.9.1 Portafolio de aplicaciones
La cartera de aplicaciones se utiliza principalmente como parte de la estrategia de servicio , pero

se hace referencia aquí para que esté completo. La cartera de aplicaciones es una lista (más
con precisión un sistema o base de datos) de todas las aplicaciones en uso dentro del
organización , junto con la siguiente información:
Atributos clave de la aplicación
• Clientes y usuarios
• Propósito de negocio
• Nivel de criticidad empresarial
• Arquitectura (incluidas las dependencias de la infraestructura de TI )
• Desarrolladores, grupos de apoyo , proveedores o vendedores
• La inversión realizada en la aplicación hasta la fecha. A este respecto, el
La cartera de aplicaciones se puede utilizar como un registro de activos para aplicaciones,
El propósito de la carpeta de aplicaciones es analizar la necesidad y el uso de

aplicaciones en la organización . Se puede utilizar para vincular funciones y
inversión en la actividad empresarial y, por lo tanto, es una parte importante de la TI en curso.
planificación
se utiliza parayidentificar
control . Otro beneficio de
duplicaciones la carteraexcesivas
y licencias de aplicaciones es que se puede
de aplicaciones.
La cartera de aplicaciones forma parte de la cartera general de servicios de TI , que es

discutido en detalle en la publicación Estrategia de servicio .
Página 252
La cartera de aplicaciones y el catálogo de servicios
La carpeta de aplicaciones no debe confundirse con el catálogo de servicios y

no debe anunciarse como una lista de servicios para los clientes o usuarios . Aplicaciones
son uno de los componentes utilizados para proporcionar servicios de TI, generalmente no el servicio
sí mismo.
Por lo tanto, la carpeta de aplicaciones debe utilizarse únicamente como documento de planificación.
por aquellos gerentes y personal que están involucrados con el desarrollo y
la gestión de la estrategia de TI de la organización, así como el personal de TI que tiene la tarea
con la gestión de las aplicaciones o las plataformas en las que se ejecutan las aplicaciones.
El catálogo de servicios debe centrarse en enumerar los servicios que están disponibles,
en lugar de simplemente enumerar las aplicaciones y asumir que los usuarios y clientes
puede hacer el enlace. Dicho esto, hay ocasiones en las que la aplicación es
sinónimo del servicio, por ejemplo, las aplicaciones de procesamiento de textos suelen
conocido por su nombre; un servicio de alojamiento de aplicaciones mencionará los nombres de
la aplicación alojada, etc.
6.5.9.2 Requisitos de la aplicación
Hay dos conjuntos de documentos que contienen los requisitos para las solicitudes:
• Los requisitos comerciales describen el caso comercial para los requisitos

aplicación, en otras palabras, qué hará la empresa con la aplicación.
Esto incluirá el retorno de la inversión de la aplicación, así como todos los
mejoras relacionadas con el negocio. Los requisitos comerciales también
Incluir los requisitos de nivel de servicio definidos por el servicio.
clientes y usuarios.
• Los documentos de requisitos de solicitud se basan en el negocio
Requisitos y especifique exactamente cómo la aplicación cumplirá esos
requisitos. En resumen, los documentos de requisitos de la aplicación se reúnen
información que se utilizará para encargar nuevas aplicaciones o cambios
a aplicaciones existentes, por ejemplo:
• Para diseñar la arquitectura de la aplicación ( especificación de la
diferentes componentes del sistema , cómo se relacionan entre sí
y cómo se gestionarán)
• Para especificar una solicitud de propuesta (RFP) para un comercial fuera de
Aplicación de estante (COTS)
• Iniciar el diseño y la construcción de una aplicación internamente.
Los documentos de requisitos son normalmente propiedad de un líder de proyecto , ya sea de un

equipo de proyecto de desarrollo , o para un equipo que elabora especificaciones para una RFP.
Los documentos de los requisitos están sujetos a control de documentos para el proyecto, ya que
forman parte del alcance global del proyecto.
Página 253
Es necesario definir cuatro tipos diferentes de requisitos de aplicación (para más

información detallada, consulte el Diseño y servicio de ITIL
Publicaciones de transición ):
• Los requisitos funcionales describen los objetivos de una aplicación

hacer, y puede expresarse como servicios, tareas o funciones de la aplicación
se requiere para realizar.
• Los requisitos de manejabilidad se utilizan para definir lo que se necesita para
administrar la aplicación o asegurarse de que realiza las funciones requeridas
consistentemente y al nivel correcto. Los requisitos de manejabilidad también identifican
limitaciones en el sistema de TI . Estos requisitos sirven de base para
dimensionamiento del sistema temprano y estimaciones de costo , y puede respaldar la
evaluación de la viabilidad del sistema informático propuesto. Más importante,
que definen el diseño del modelo operativo s y las normas de rendimiento s
utilizado en la gestión de operaciones de TI.
• Los requisitos de usabilidad normalmente los especifican los usuarios del
aplicación y consulte su facilidad de uso. Cualquier requisito especial para
Los usuarios discapacitados también deben especificarse aquí.
• Los requisitos de prueba especifican lo que se requiere para asegurar que la prueba
El entorno es representativo del entorno operativo y que el
la prueba es válida (es decir, que realmente prueba lo que se supone que debe hacer).
6.5.9.3 Casos de uso y cambio
Los casos de uso y cambio se gestionan como parte del diseño del servicio y
Procesos de mejora continua del servicio , pero son mantenidos por la aplicación
Gestión . Para el software comprado, es común que el equipo que desarrolla
las especificaciones funcionales para mantener el caso de uso para esa aplicación.
• Los casos de uso documentan el uso previsto de la aplicación con la vida real
escenarios para demostrar sus límites y su funcionalidad completa. Usar
Los casos también se pueden utilizar como escenarios de modelado y dimensionamiento y para
Facilitar la comunicación entre usuarios, Desarrolladores y Aplicación.
Equipo administrativo.
• Los casos de cambio utilizan escenarios para predecir el impacto de los cambios potenciales en
utilización, arquitectura o funcionalidad, y proyectar el impacto de determinadas
cambiar escenarios. Los casos de cambio se utilizan para aclarar el alcance y la dirección
con el patrocinador. Se necesitará trabajo adicional de arquitectura y diseño en este
punto para garantizar que los casos de cambio se puedan cumplir en el futuro a un precio razonable
costo . El patrocinador debe estar preparado para pagar el costo adicional. Si no, el
Los casos de cambio deben reducirse a lo que el patrocinador está dispuesto a pagar
por. Los casos de cambio también se utilizan para evaluar la arquitectura . Ellos
influir en el proceso de desarrollo permitiendo el diseño de
características arquitectónicas para minimizar el impacto de cambios futuros.
Página 254
Para obtener más información, consulte ITIL Service Design and Continual Service
Publicaciones de mejora .
6.5.9.4 Documentación de diseño
Este no es un documento específico , sino que se refiere a cualquier documento elaborado por
Personal de desarrollo o administración de aplicaciones que especifica cómo una aplicación
será construido. Como estos documentos generalmente son propiedad y están administrados por
Equipos de desarrollo, esta publicación no los cubrirá en detalle. Sin embargo, para
asegurar una operación exitosa , la Gestión de Aplicaciones debe asegurar que el diseño
la documentación contiene:
• Especificación de tamaño s
• Perfiles de carga de trabajo y previsiones de utilización
• Arquitectura técnica
• Modelo de datos s
• Estándar de codificación s
• Estándares de desempeño
• Definiciones de gestión de la configuración de software
• Definiciones ambientales y consideraciones de construcción (si corresponde).
Para las aplicaciones COTS, estos documentos toman la forma de Solicitud

Especificaciones que se utilizan como entrada en la redacción de RFP. En estos casos el
Los documentos son propiedad y están gestionados por Application Management .
Para obtener más información sobre la documentación de diseño, consulte ITIL Service Design
publicación.
6.5.9.5 Manuales
Application Management es responsable de la gestión de manuales para todos

aplicaciones. Aunque normalmente son desarrollados por la Aplicación
Equipos de desarrollo o proveedores externos, la Gestión de aplicaciones es
responsable de asegurar que los manuales son relevantes para la versión operativa s
de las aplicaciones.
Por lo general, Application Management mantiene tres tipos de manuales:
• Los manuales de diseño contienen información sobre la estructura y la arquitectura.

de la aplicación. Son útiles para crear informes o definir eventos.
reglas de correlación. También podrían ayudar a diagnosticar problemas .
• Los manuales de administración o gestión describen las actividades necesarias
para mantener y operar la aplicación a los niveles de rendimiento
especificado en la fase de Diseño. Estos manuales también proporcionarán información detallada
resolución de problemas, descripciones de errores conocidos y fallas, y paso a paso
instrucciones para tareas de mantenimiento comunes.
Página 255
• Los manuales de usuario describen la funcionalidad de la aplicación tal como la utiliza un

usuario final . Estos manuales contienen instrucciones paso a paso sobre cómo utilizar
la aplicación , así como descripciones de lo que normalmente se debe ingresar
en ciertos campos, o qué hacer si hay un error .
Manuales y de Operación Estándar Procedimiento s
Los manuales no deben verse como un reemplazo de los procedimientos operativos estándar, sino como un insumo
POE.
Los POE deben contener todos los aspectos de las aplicaciones que deben gestionarse como parte
de operaciones estándar. Si no se extraen de los manuales, existe una alta
probabilidad de que sean ignorados o ejecutados de una manera no estándar.
La gestión de aplicaciones debe asegurarse de que se extraigan dichas instrucciones.
de los manuales y se inserta en la documentación SOP separada para Operaciones.
También es responsable de garantizar que estas instrucciones se actualicen con cada
cambio o nueva versión del software.
Página 256
6.6 Funciones y responsabilidades de la operación del servicio
La clave para un ITSM eficaz es garantizar que exista una responsabilidad y unos roles claros.
definido para llevar a cabo la práctica de Operación del Servicio . Un rol a menudo está ligado a un trabajo.
descripción o descripción del grupo de trabajo, pero no es necesario completarla
por un individuo. El tamaño de una organización , cómo está estructurada, la existencia
de socios externos y otros factores influirán en cómo se asignan los roles.
Si un rol en particular lo desempeña una sola persona o se comparte entre dos o
Además, la importancia es la coherencia de la rendición de cuentas y la ejecución, junto con
con la interacción con otros roles en la organización.
6.6.1 Roles de la mesa de servicio
Los siguientes roles son necesarios para la mesa de servicio .
6.6.1.1 Administrador de la mesa de servicio
En organizaciones más grandes donde el Service Desk es de un tamaño significativo, un Service

El rol de Desk Manager puede justificarse con el Supervisor de Service Desk
informarle a él o ella. En tales casos, esta función puede asumir la responsabilidad de algunos de los
las actividades enumeradas anteriormente y, además, puede realizar las siguientes actividades:
• Gestionar las actividades generales del escritorio, incluidos los supervisores.

• Actuar como un punto de escalada adicional para los supervisores
• Asumir un rol más amplio de servicio al cliente
• Informar a los altos directivos sobre cualquier problema que pueda tener un impacto significativo en la
negocio
• Asistir a las reuniones de la Junta Asesora de Cambio
• Asumir la responsabilidad general del manejo de incidentes y solicitudes de servicio en
el Service Desk. Esto también podría ampliarse a cualquier otra actividad realizada
en el Service Desk, por ejemplo, monitoreando ciertas clases de eventos .
Nota: En todos los casos, se deben redactar y acordar descripciones de trabajo claramente definidas.
para que se conozcan las responsabilidades específicas.
6.6.1.2 Supervisor de la mesa de servicio
En escritorios muy pequeños, es posible que el analista senior de Service Desk también actúe
como supervisor, pero en escritorios más grandes es probable que un Service Desk dedicado
Será necesario el papel de supervisor . Cuando lo dicten las horas de turno , puede haber dos o
más titulares de puestos que cumplen el rol, generalmente sobre una base superpuesta. los
Es probable que el rol del supervisor incluya:
• Asegurar que el personal y los niveles de habilidad se mantengan en todo

horas operativas mediante la gestión de horarios de personal por turnos , etc.
• Realización de actividades de recursos humanos según sea necesario
Página 257
• Actuar como un punto de escalada donde las llamadas difíciles o controvertidas son
recibió
• Elaboración de estadísticas e informes de gestión
• Representar al Service Desk en reuniones
• Organización de sesiones de formación y sensibilización del personal
• Enlace con la alta dirección
• Enlace con la gestión del cambio
• Realizar sesiones informativas al personal de la mesa de servicio sobre cambios o implementaciones que
puede afectar los volúmenes en el Service Desk
• Ayudar a los analistas a brindar soporte de primera línea cuando la carga de trabajo es alta,
o donde se requiera experiencia adicional.
6.6.1.3 Analistas de la mesa de servicio
El rol principal del Analista de Service Desk es el de brindar soporte de primer nivel.
a través de tomar llamadas y manejo de los incidentes resultantes o solicitud de servicio s
utilizando los procesos de Reporte de Incidentes y Cumplimiento de Solicitudes , en línea con el
los objetivos descritos anteriormente. El número exacto de personal necesario se analiza en
párrafo 6.2.4.1.
6.6.1.4 Superusuarios
Los superusuarios se analizan en detalle en la sección sobre dotación de personal de Service Desk en
párrafo 6.2.4. En resumen, este rol consistirá en usuarios comerciales que actúan como
puntos de enlace con TI en general y el Service Desk en particular. El papel del
El superusuario se puede resumir de la siguiente manera:
• Facilitar la comunicación entre TI y la empresa a nivel operativo.

nivel
• Reforzar las expectativas de los usuarios con respecto a los niveles de servicio que tienen
sido acordado
• Formación de personal a los usuarios de su zona
• Brindar soporte para incidentes menores o simple cumplimiento de solicitudes
• Participación con nuevas versiones y lanzamientos .
6.6.2 Roles de gestión técnica
Los siguientes roles son necesarios en las áreas de Gestión Técnica
6.6.2.1 Directores técnicos / jefes de equipo
Un gerente técnico o líder de equipo (dependiendo del tamaño y / o

importancia del equipo y de la organización ‘s estructura y la cultura ) puede ser
necesarios para cada uno de los equipos o departamentos técnicos. El rol:
Página 258

el equipo técnico o departamento
• Proporcionar conocimiento técnico y liderazgo en las áreas técnicas específicas.
cubierto por el equipo o departamento
mantenido dentro del equipo o departamento
• Informar a la alta dirección sobre todas las cuestiones técnicas relevantes para su área.
de responsabilidad
6.6.2.2 Analistas técnicos / arquitectos
Este término se refiere a cualquier miembro del personal de la Dirección Técnica que realice la
actividades enumeradas en el párrafo 6.3.3, excluidas las acciones operativas diarias , que
son realizados por Operadores en Gestión de Operaciones Técnicas o de TI .
Sobre la base de la lista de actividades genéricas en el párrafo 6.3.3, el papel del técnico
Analistas y arquitectos incluye:
• Trabajar con usuarios , patrocinadores, gestión de aplicaciones y todos los demás

las partes interesadas para determinar sus necesidades cambiantes
• Trabajar con Gestión de aplicaciones y otras áreas en Técnico
Gestión para determinar el nivel más alto de los requisitos del sistema s
requerido para cumplir con los requisitos dentro del presupuesto y la tecnología
limitaciones
• Definir y mantener el conocimiento sobre cómo se relacionan los sistemas y
Asegurarse de que las dependencias se comprendan y gestionen en consecuencia.
medios para cumplir con los requisitos establecidos
• El desarrollo operacional Modelo s que va a asegurar el uso óptimo de los recursos s
• Asegurar que la infraestructura esté configurada para ser administrada de manera efectiva
dada la arquitectura tecnológica de la organización , las habilidades y herramientas disponibles
• Asegurar el desempeño consistente y confiable de la infraestructura para
brindar el nivel de servicio requerido a la empresa
• Definir todas las tareas necesarias para gestionar la infraestructura y garantizar que
estas tareas se realizan adecuadamente
Las formas en que se puede organizar la Gestión Técnica y las opciones

disponibles, se analizan con cierto detalle en la sección 6.7.
6.6.2.3 Operador técnico
Este término se utiliza para referirse a cualquier personal que realiza tareas operativas diarias.
en Gestión Técnica. Por lo general, estas tareas se delegan a un departamento de TI dedicado .
Página 259
Equipo de operaciones y, por lo tanto , esta función se analiza en el párrafo 6.6.3.4 sobre TI.
Operadores.
6.6.3 Roles de gestión de operaciones de TI
Los siguientes roles y necesarios en el área de Gestión de Operaciones de TI :
6.6.3.1 Gerente de operaciones de TI
Se necesitará un gerente de operaciones de TI para asumir la responsabilidad general de todos los

las actividades de gestión de operaciones de TI , que incluyen:
• Control de Operaciones , que supervisa la ejecución y seguimiento de la

actividades operativas en la infraestructura de TI . Esto se puede hacer con el
asistencia de un puente de operaciones o un centro de operaciones de red. En
además de ejecutar tareas rutinarias de todas las áreas técnicas, Operaciones
Control también realiza las siguientes tareas específicas:
• Gestión de la consola , que se refiere a la definición de la observación central
y capacidad de monitoreo y luego usar esas consolas para ejercitar
actividades de seguimiento y control
• Programación de trabajos o la gestión de trabajos por lotes de rutina o scripts
• Copia de seguridad y restauración en nombre de todos los técnicos y aplicaciones
Equipos o departamentos de gestión y, a menudo, en nombre de los usuarios .
• Gestión de impresión y salida para la clasificación y distribución de
toda impresión centralizada o salida electrónica.
• Gestión de instalaciones , que se refiere a la gestión de la TI física
entorno , normalmente un centro de datos o salas de informática y recuperación
sitios junto con todo el equipo de energía y enfriamiento. Instalaciones
La gestión también incluye la coordinación de la consolidación a gran escala
proyectos , por ejemplo, consolidación de centros de datos o proyectos de consolidación de servidores . En
algunos casos se subcontrata la gestión de un Data Center, en los que
caso de Gestión de Instalaciones se refiere a la gestión de la subcontratación
contrato .
El rol del Gerente de Operaciones de TI es:
• Proporcionar liderazgo, control y toma de decisiones generales y asumir

responsabilidad de los equipos y el departamento de gestión de operaciones de TI
• Informar a la alta dirección sobre todos los problemas de operaciones de TI
• Realice la gestión de línea para todo el equipo o departamento de operaciones de TI
gerentes / supervisores.
6.6.3.2 Líderes de turno
Página 260
Muchas áreas de operaciones de TI trabajarán horas extendidas, ya sea en dos o tres

base de turno . En tales casos , se necesitará un líder de turno en cada uno de los turnos, para
realizar las siguientes actividades:
• Asumir la responsabilidad general del liderazgo, el control y la toma de decisiones.

durante el período de turno
• Asegúrese de que todas las actividades operativas se realicen satisfactoriamente dentro de
plazos acordados y de acuerdo con las políticas de la empresa y
procedimiento s
• Servir de enlace con los otros líderes de turno para garantizar el traspaso, la continuidad y
consistencia entre los turnos
• Actuar como gerente de línea para todos los analistas de operaciones en su turno.
• Asumir la responsabilidad general de salud y seguridad y protección del turno.
(a menos que se designe específicamente a otros miembros del personal).
6.6.3.3 Analistas de operaciones de TI
Los analistas de operaciones de TI son personal senior de operaciones de TI que pueden determinar
la forma más eficaz y eficiente de realizar una serie de operaciones, generalmente en
Entorno diverso y de gran volumen s.
Esta función se realiza normalmente como parte de la gestión técnica , pero

Las organizaciones pueden encontrar que el volumen y la diversidad de las actividades operativas
requiere una planificación y ejecución más a fondo . Los ejemplos incluyen Job
Programación y definición de una estrategia y cronograma de Backup .
6.6.3.4 Operadores de TI
Los operadores de TI son el personal que realiza las actividades operativas diarias que
se definen en Gestión técnica o de aplicaciones y, en algunos casos, TI
Analistas de operaciones. Los roles típicos del operador incluyen:
• La realización de copias de seguridad s

• Operaciones de la consola, es decir, monitorear el estado de sistemas específicos, trabajo
colas, etc. y proporcionando intervención de primer nivel si es apropiado
• Gestión de dispositivos de impresión, reabastecimiento de papel, tóner, etc.
• Asegurarse de que se realicen trabajos por lotes, archivado, etc.
• Ejecutar trabajos de mantenimiento de casa programados, como el mantenimiento de la base de datos,
limpieza de archivos, etc.
• Grabación de imágenes para su distribución e instalación en nuevos servidores y escritorios
o laptops
• Instalación física de equipos estándar en el Data Center.
6.6.4 Roles de gestión de aplicaciones
6.6.4.1 Gerentes de aplicaciones / líderes de equipo
Página 261
Se debe considerar un administrador de aplicaciones o un líder de equipo para cada uno de los
aplicación es equipos o departamentos. El rol:
el equipo o departamento de aplicaciones
• Proporcionar conocimiento técnico y liderazgo en las aplicaciones específicas.
actividades de apoyo cubiertas por el equipo o departamento
mantenido dentro del equipo o departamento relevante para las aplicaciones
siendo apoyados y procesos que se utilizan
• Involucrar la comunicación continua con los usuarios y los clientes con respecto a
Rendimiento de la aplicación y requisitos cambiantes del negocio.
• Informar a la alta dirección sobre todas las cuestiones relevantes para las aplicaciones.
siendo apoyado
6.6.4.2 Analista / Arquitecto de aplicaciones
Los analistas y arquitectos de aplicaciones son responsables de hacer coincidir los requisitos con
especificación de la aplicación s. Las actividades específicas incluyen:
• Trabajar con usuarios, patrocinadores y todas las demás partes interesadas para determinar su
necesidades en evolución
• Trabajar con la Gerencia Técnica para determinar el nivel más alto de
requisitos del sistema necesarios para cumplir con los requisitos dentro del presupuesto y
limitaciones tecnológicas
medios para cumplir con el requisito establecido
• El desarrollo operacional Modelo s que va a asegurar el uso óptimo de los recursos s
• Asegurar que las aplicaciones estén diseñadas para ser administradas de manera efectiva
La arquitectura tecnológica de la organización , las habilidades y herramientas disponibles.
• Desarrollar y mantener estándares para el tamaño y el rendimiento de las aplicaciones .
modelado , etc.
• Generar un conjunto de requisitos de prueba de aceptación , junto con la
diseñadores, ingenieros de pruebas y el usuario, que determinan que todos los
Se han cumplido requisitos de alto nivel, tanto funcionales como de manejabilidad.
Se necesitará un número apropiado de analistas de aplicaciones para cada uno de los

Equipos o departamento de Gestión de aplicaciones para realizar las actividades descritas
en otras partes de esta publicación, principalmente en el párrafo 6.5.5.
Las formas en que se pueden organizar los grupos de administración de aplicaciones y la

opciones disponibles, se discuten con cierto detalle en la sección 6.7.
Página 262
6.6.5 Roles de gestión de eventos
Es inusual que una organización designe un 'Administrador de eventos', ya que los eventos tienden a
ocurren en múltiples contextos y por muchas razones diferentes. Sin embargo lo és
Es importante que los procedimientos de gestión de eventos estén coordinados para evitar
duplicación de esfuerzos y herramientas. Los roles de la función de Operación del Servicio en
La gestión de eventos es la siguiente.
6.6.5.1 El rol del Service Desk
El Service Desk no suele participar en la gestión de eventos como tal, a menos que
un evento requiere alguna respuesta que está dentro del alcance de la Mesa de Servicio
actividad definida , por ejemplo, notificar a un usuario que un informe está listo. En general,
Sin embargo, este tipo de actividad es realizada por el Puente de Operaciones , a menos que el
Service Desk y Operations Bridge se han combinado.
La investigación y resolución de hechos que hayan sido identificados como

Inicialmente, los incidentes serán realizados por la mesa de servicio y luego escalados a
el (los) equipo (s) de operación de servicio apropiados
El Service Desk también es responsable de comunicar información sobre este

tipo de incidente al equipo técnico o de gestión de aplicaciones pertinente y,
en su caso, el usuario.
6.6.5.2 El papel de la gestión técnica y de aplicaciones
La gestión técnica y de aplicaciones desempeña varios roles importantes de la siguiente manera:
• Durante el Diseño del Servicio , participarán en la instrumentación del

servicio , clasificar eventos, actualizar motores de correlación y asegurarse de que cualquier
las respuestas automáticas están definidas
• Durante la Transición del servicio, probarán el servicio para asegurarse de que los eventos
se generan correctamente y que las respuestas definidas son adecuadas
• Durante la operación de servicio, estos equipos normalmente realizarán eventos
Gestión de los sistemas bajo su control. Es inusual que los equipos
tener una persona dedicada a gestionar la gestión de eventos, pero cada
gerente o líder del equipo se asegurará de que se apliquen los procedimientos
definido y ejecutado de acuerdo con los procesos y de política requisito s
• La gestión técnica y de aplicaciones también participará en el tratamiento
con incidentes y problemas relacionados con eventos
• Si las actividades de gestión de eventos se delegan a la mesa de servicio o al departamento de TI
La gestión de operaciones, la gestión técnica y de aplicaciones deben
Asegurar que el personal esté adecuadamente capacitado y que tenga acceso a
las herramientas adecuadas que les permitan realizar estas tareas.
6.6.5.3 El papel de la gestión de operaciones de TI
Página 263
Cuando las operaciones de TI están separadas de la gestión técnica o de aplicaciones,

Es común que la supervisión de eventos y la respuesta de primera línea se deleguen en TI.
Gestión de operaciones . Los operadores de cada área tendrán la tarea de monitorear
eventos, respondiendo según sea necesario o asegurando que los Incidentes se creen como
apropiado. Las instrucciones sobre cómo hacerlo deben incluirse en los POE para
esos equipos.
El monitoreo de eventos se delega comúnmente en Operations Bridge, donde

existe. El Puente de Operaciones puede iniciar y coordinar, o incluso realizar, la
las respuestas requeridas por el servicio, o proporcionar soporte de primer nivel para esos eventos s
que generan una incidencia .
6.6.6 Roles de gestión de incidentes
Los siguientes roles son necesarios para el proceso de gestión de incidentes .
6.6.6.1 Administrador de incidentes
Un administrador de incidentes tiene la responsabilidad de:
• Impulsando la eficiencia y eficacia de la Gestión de Incidentes

proceso
• Producir información de gestión
• Gestionar el trabajo del personal de apoyo a incidentes (primera y segunda línea)
• Monitorear la efectividad de la Gestión de Incidentes y hacer
recomendaciones de mejora
• Desarrollo y mantenimiento de las gestión de incidentes del sistema s
• La gestión de incidentes de importancia s
• Desarrollar y mantener el proceso de gestión de incidentes y
procedimiento s.
En muchas organizaciones, el rol de administrador de incidentes se asigna al servicio

Supervisor de escritorio, aunque en organizaciones más grandes con grandes volúmenes, un
el papel puede ser necesario. En cualquier caso, es importante que el administrador de incidentes esté
se le ha dado la autoridad para gestionar los incidentes de manera eficaz a través de la primera, segunda y tercera
línea.
6.6.6.2 Primera línea
Esto se trata en detalle en la Mesa de servicio (sección 6.1) y no se

repetido aquí.
6.6.6.3 Segunda línea
Muchas organizaciones optarán por tener un grupo de apoyo de segunda línea , compuesto por
personal con mayores habilidades técnicas (aunque todavía generales) que el Service Desk -
Página 264
y con tiempo adicional para dedicarlo al diagnóstico y resolución de incidentes sin

interferencia de interrupciones telefónicas.
Tal grupo puede manejar muchos de los incidentes menos complicados, dejando más
grupos de apoyo de especialistas (tercera línea) para concentrarse en tratar con
incidentes arraigados y / o nuevos desarrollos, etc.
Cuando se utiliza un grupo de segunda línea, a menudo hay ventajas de ubicar este
grupo cerca de la mesa de servicio para ayudar con buenas comunicaciones y para facilitar
movimiento de personal entre los grupos, lo que puede ser útil para
capacitación / sensibilización y durante períodos de mucho trabajo o escasez de personal. Una segunda linea
El gerente de soporte (o supervisor si solo es un grupo pequeño) normalmente encabezará este
grupo.
Es concebible que este grupo pueda ser subcontratado, y esto es más probable y
práctico si el Service Desk se ha subcontratado.
6.6.6.4 Tercera línea
El apoyo de tercera línea será proporcionado por una serie de grupos técnicos internos.
y / o proveedores / mantenedores externos. La lista variará de una organización a otra.
organización, pero es probable que incluya:
• Soporte de red
• Soporte de voz (si está separado)
• Soporte del servidor
• Soporte de escritorio
• Gestión de aplicaciones : es probable que haya equipos separados para
diferentes aplicaciones o tipos de aplicaciones , algunas de las cuales pueden ser externas
proveedor / mantenedores. En muchos casos, el mismo equipo se encargará de
Desarrollo de aplicaciones , así como soporte, y por lo tanto es
importante que los recursos se prioricen para que se brinde el apoyo adecuado
prominencia
• Soporte de base de datos
• Ingenieros de mantenimiento de hardware
• Proveedores / mantenedores de equipos ambientales.
Nota: Dependiendo de dónde una organización decida obtener su apoyo.

servicios, cualquiera de los grupos anteriores pueden ser grupos internos o externos.
6.6.7 Solicitar roles de cumplimiento
El manejo inicial de las solicitudes de servicio será realizado por la mesa de servicio y
Personal de gestión de incidentes .
Página 265
El eventual cumplimiento de la solicitud será realizado por el Servicio correspondiente.

Equipo (s) de operación o departamentos y / o proveedores externos, según corresponda.
A menudo, la gestión de instalaciones , adquisiciones y otras áreas comerciales ayudan en la
Cumplimiento de la Solicitud de Servicio. En la mayoría de los casos no será necesario
adicionales a seguir s o puestos que se crearon.
En casos excepcionales en los que se gestiona un número muy elevado de solicitudes de servicio,
o cuando las solicitudes son de importancia crítica para la organización, puede ser
apropiado tener uno o más miembros del equipo de gestión de incidentes dedicados a
manejo y gestión de solicitudes de servicio.
6.6.8 Roles de gestión de problemas
Los siguientes roles son necesarios para el proceso de Gestión de problemas .
6.6.8.1 Administrador de problemas
Debe haber una persona designada (o, en organizaciones más grandes, un equipo)
responsable de la gestión de problemas. Es posible que las organizaciones más pequeñas no puedan
justificar un recurso de tiempo completo para este rol, y se puede combinar con otros roles en
tales casos, pero es fundamental que no se deje solo a los recursos técnicos para que lo realicen.
Debe haber un único punto de coordinación y un propietario del problema.
Proceso de gestión. Este rol coordinará toda la gestión de problemas
actividades y tendrá la responsabilidad específica de:
• Enlace con todos los grupos de resolución de problemas para garantizar una rápida resolución de
problemas dentro de los objetivos de SLA
• Propiedad y protección de la KEDB
• Gatekeeper para la inclusión de todos los errores conocidos y la gestión de
algoritmos de búsqueda
• Formal de cierre de todas Registro de problema s
• Enlace con proveedores , contratistas, etc. para asegurar que terceros cumplan
sus obligaciones contractuales, especialmente con respecto a la resolución de problemas
y proporcionar información y datos relacionados con el problema
• Organizar, ejecutar, documentar y todas las actividades de seguimiento relacionadas con
Revisión de problemas importantes s.
6.6.8.2 Grupos de resolución de problemas
Es probable que la resolución real de los problemas la lleven a cabo uno o más
grupos de soporte técnico y / o proveedores o contratistas de soporte - bajo el
Coordinación del Gestor de Problemas.
Cuando un problema individual es lo suficientemente grave como para justificarlo, un problema específico
El equipo de gestión debe estar formulado para trabajar juntos en la superación de
Problema particular. El administrador de problemas tiene un papel que desempeñar para asegurarse de que
Página 266
el número y el nivel correctos de recursos están disponibles en el equipo y para

Escalada y comunicación en la cadena de gestión de todas las organizaciones.
preocupado.
6.6.9 Roles de gestión de acceso
Dado que la gestión de acceso es una ejecución de seguridad y disponibilidad

Gestión , estas dos áreas serán las encargadas de definir la adecuada
roles. Es inusual que una organización designe un 'Administrador de acceso', aunque
Es importante que haya un único proceso de gestión de acceso y un único conjunto
de políticas relacionadas con la gestión de derechos y acceso. Este proceso y el relacionado
Es probable que las políticas sean definidas y mantenidas por Seguridad de la Información.
Gestión y ejecución por las distintas funciones de Operación del Servicio . Su
las actividades se pueden resumir de la siguiente manera.
6.6.9.1 El rol del Service Desk
La mesa de servicio se utiliza normalmente como un medio para solicitar acceso a un servicio.
Normalmente, esto se hace mediante una solicitud de servicio . El Service Desk validará
la solicitud comprobando que la solicitud ha sido aprobada en el
nivel de autoridad, que el usuario es un empleado, contratista o cliente legítimo
y que califican para el acceso.
Una vez que ha realizado estas comprobaciones (normalmente accediendo a la

bases de datos y documentos de gestión de nivel de servicio ) pasará la solicitud a
el equipo apropiado para proporcionar acceso. Es bastante común que el Service Desk
que se le delegue la responsabilidad de proporcionar acceso a servicios simples durante el
llamar .
El Service Desk también será responsable de comunicarse con el usuario para

asegurarse de que sepan cuándo se ha concedido el acceso y asegurarse de que
recibir cualquier otro apoyo necesario.
El Service Desk también está bien situado para detectar e informar incidentes relacionados con
acceso. Por ejemplo, los usuarios que intentan acceder a los servicios sin autorización; o
usuarios que informan incidentes que indican que se ha utilizado un sistema o servicio
inapropiadamente, es decir, por un ex empleado que usó un nombre de usuario anterior para obtener
acceder y realizar cambios no autorizados.
6.6.9.2 El papel de la gestión técnica y de aplicaciones
La gestión técnica y de aplicaciones desempeña varias funciones importantes de la siguiente manera:
• Durante el Diseño del Servicio , se asegurarán de que se creen mecanismos para

simplificar y controlar la gestión de acceso en cada servicio que se
Página 267
diseñado. También especificarán las formas en que se puede realizar el abuso de derechos.
detectado y detenido
• Durante la Transición del servicio , probarán el servicio para asegurarse de que el acceso
puede concederse, controlarse y prevenirse según lo diseñado
• Durante la operación del servicio, estos equipos normalmente realizarán el acceso
Gestión de los sistemas bajo su control. Es inusual que los equipos
tener una persona dedicada a gestionar la Gestión de acceso, pero cada
El gerente o lder del equipo se asegurara de que se apliquen los procedimientos adecuados .
definido y ejecutado de acuerdo con los procesos y de política requisito s
• La gestión técnica y de aplicaciones también participará en el tratamiento
con Incidencias y Problemas relacionados con la Gestión de Accesos
• Si las actividades de Gestión de acceso se delegan a la mesa de servicio o al departamento de TI
La gestión de operaciones , la gestión técnica y de aplicaciones deben
Asegurar que el personal esté adecuadamente capacitado y que tenga acceso a
las herramientas adecuadas que les permitan realizar estas tareas.
6.6.9.3 El papel de la gestión de operaciones de TI

Cuando las operaciones de TI están separadas de la gestión técnica o de aplicaciones,

Es común que las tareas operativas de Gestión de acceso se deleguen en TI.
Gestión de operaciones . Los operadores de cada área tendrán la tarea de proporcionar
o revocar el acceso a sistemas o recursos clave . Las circunstancias bajo las cuales
pueden hacerlo, y las instrucciones sobre cómo hacerlo, deben incluirse en el
POE para esos equipos.
El Puente de operaciones , si existe, se puede utilizar para monitorear eventos relacionados con
Gestión de acceso e incluso puede proporcionar apoyo y coordinación de primera línea en
la resolución de esos eventos en su caso.
Página 268
6.7 Estructuras de organización de operaciones de servicio
Ya se ha proporcionado alguna información general sobre la organización

consideraciones para cada función (véanse los apartados 6.2.3, 6.3.4 y 6.5.6). Esta
La sección considera algunas estructuras organizativas específicas para todas las funciones. Allí
Hay varias formas de organizar las funciones de Operación del Servicio, y cada
La organización tendrá que tomar sus propias decisiones, basadas en su escala,
geografía, cultura y entorno empresarial . Algunas opciones se discuten en
el resto de esta sección.
6.7.1 Organización por especialización técnica
En este tipo de organización, los departamentos se crean de acuerdo con la tecnología y

las habilidades y actividades necesarias para gestionar esa tecnología. Operaciones de TI se
seguir la estructura de los departamentos de Gestión Técnica y de Aplicación.
La implicación de esto es que las operaciones de TI están orientadas hacia las operaciones
agendas de los departamentos de Gestión Técnica y de Aplicaciones.
Esta estructura puede funcionar bien, siempre que estos grupos estén completamente representados en
los procesos de Diseño , Prueba y Mejora del Servicio, que asegurarán que
sus agendas están alineadas con los requerimientos del negocio.
Esta estructura también asume que toda la gestión técnica y de aplicaciones

departamentos han distinguido claramente entre su actividad de Gestión y
actividad de operaciones. También se requiere que éstos han estandarizado operativa
actividades para que puedan ser administradas de manera efectiva por el gerente de operaciones de TI
sin interferencias indebidas de la gestión técnica y de aplicaciones
equipos o departamentos.
Un ejemplo de una estructura de organización de operaciones de TI basada en

La experiencia se da en la Figura 6.7.
Página 269
Figura 6.7 Operaciones de TI organizadas según la especialización técnica (muestra)
Las ventajas de este tipo de estructura organizativa incluyen las siguientes.
• Es más fácil establecer objetivos de desempeño internos ya que todo el personal en un solo
departamento tiene un conjunto similar de tareas en una tecnología similar
Página 270
• Los dispositivos, sistemas o plataformas individuales se pueden administrar de manera más efectiva
ya que las personas con las habilidades adecuadas se dedican a gestionar estos
y medido de acuerdo a su desempeño
• La gestión de los programas de formación es más fácil ya que los conjuntos de habilidades están claramente definidos.
y separados en grupos específicos.
Las desventajas de este tipo de estructura organizativa incluyen.
• Cuando las personas se dividen en departamentos separados, las prioridades de sus

propio grupo tienden a anular las prioridades de otros departamentos. Un ejemplo
de esto es cuando los departamentos se niegan a aceptar la propiedad de un incidente ,
cada uno culpando al otro mientras el negocio continúa en crisis.
• Conocimiento sobre la infraestructura y las relaciones entre
Los componentes son difíciles de recopilar y están fragmentados. Los grupos individuales tienden a
recopilar y mantener solo los datos necesarios para respaldar sus propios
función , y no le da acceso a ella muy fácilmente.
• Cada tecnología administrada por un grupo se considera una entidad separada. Esta
se convierte en un problema en los sistemas que constan de componentes gestionados por
diferentes equipos, por ejemplo, una aplicación , gestionada por la aplicación
Equipo de administración, se ejecuta en un servidor administrado por la Administración del servidor.
departamento, utilizando un segmento de red gestionado por el Área Local
Departamento de networking. Si un equipo o departamento realiza un cambio
sin consultar a los demás, esto podría ser desastroso para el servicio .
• Es más difícil comprender el impacto de los pobres de un solo departamento.
rendimiento en el servicio de TI, ya que hay muchos grupos diferentes
contribuyendo al mismo servicio, cada uno con su propio conjunto de prestaciones
objetivos.
• Es más difícil rastrear el desempeño general del servicio de TI ya que cada grupo
se mide de forma individual.
• Coordinar evaluaciones de cambios y programas es más difícil ya que
muchos departamentos diferentes tienen que aportar información para cada cambio.
• El trabajo que requiere conocimiento de múltiples tecnologías es difícil ya que la mayoría
recursos s slo estn capacitados y se preocupan por la gestin de un
tecnología única. Por lo tanto, los proyectos deben incluir capacitación cruzada, que
consume mucho tiempo y es caro.
6.7.2 Organización por actividad
Este tipo de estructura organizativa se centra en el hecho de que actividades similares tienen
a realizar en todas las tecnologías de la organización. Esto significa que la gente
que realizan actividades similares, independientemente de la tecnología, deben agruparse
juntos, aunque dentro de cada departamento puede haber equipos que se centran en un
tecnología específica, aplicación , etc.
Página 271
En este tipo de organización, no existe una diferenciación clara entre los diferentes
Áreas de Gestión Técnica y de Aplicaciones. Actividades similares de muchos
diferentes áreas se pueden agrupar en un solo departamento.
Ejemplos de departamentos que se han configurado para realizar un conjunto específico de

Las actividades a través de múltiples tecnologías incluyen:
• Mantenimiento (esto implica que un equipo coordinará y realizará todos

mantenimiento en todas las tecnologías)
• Gestión de contratos o de Terceros Gestión
• Monitorear y controlar
• Puente de operaciones
• Centro de operaciones de red
• Estrategia y planificación de operaciones (que, como parte del diseño del servicio
procesos, normalmente define los estándares que se utilizarán en operaciones de TI ) -
este departamento puede establecer estrategias o estándares para cada tipo de técnico
y área de Gestión de Aplicaciones.
El departamento de Estrategia y Planificación de Operaciones se utiliza para ilustrar este tipo.

de estructura en la Figura 6.8.
Figura 6.8 Un departamento basado en la ejecución de un conjunto de actividades
Página 272
• Es más fácil gestionar grupos de actividades relacionadas ya que todas las personas
involucrados en estas actividades reportan al mismo gerente
• La medición de equipos o departamentos se basa más en la producción que en
actividades aisladas. Esto ayuda a construir niveles más altos de garantía de que un
el servicio puede ser entregado.
Las desventajas de este tipo de estructura organizativa incluyen las siguientes.
• Los recursos con habilidades similares pueden duplicarse en diferentes funciones ,

lo que resulta en mayores costos s
• Aunque la medición se basa más en los resultados, todavía se centra en la
desempeño de actividades internas en lugar de impulsado por la experiencia de
el cliente o usuario final .
6.7.3 Organización para gestionar procesos
No es una buena idea estructurar toda la organización según procesos.

Los procesos se utilizan para superar el 'efecto silo' de los departamentos, no para crear
silos. Sin embargo, hay una serie de procesos que necesitarán un
estructura organizativa para apoyarlo y gestionarlo. Por ejemplo, será muy
difícil para la gestión financiera tener éxito sin un departamento de finanzas dedicado
departamento, incluso si ese departamento consta de una pequeña cantidad de personal.
En las organizaciones basadas en procesos , las personas se organizan en grupos o departamentos.

que realizan o gestionan un proceso específico. Esto es similar al basado en actividades
estructura, excepto que sus departamentos se centran en conjuntos de actividades de un extremo a otro en lugar de
que en un tipo de actividad individual.
Cabe señalar que este tipo de estructura organizativa solo debe utilizarse si
La gestión
Algunas de operacionespor
organizaciones, de ejemplo,
TI es responsable de más
Operaciones que
de TI essolo operaciones
responsable de TI SLA
de definir . En
y negociación de UC.
Además, existen procesos específicamente para vincular las actividades de diferentes grupos a
lograr un resultado específico . Usando procesos como base para crear departamentos
puede frustrar el propósito de tener procesos en primer lugar. Basado en procesos
Los departamentos solo son efectivos cuando son capaces de coordinar la
ejecución del proceso a través de toda la organización.
Esto significa que los departamentos basados en procesos solo deben considerarse si TI
La gestión de operaciones debe desempeñar el papel de propietario del proceso para un
proceso.
Ejemplos de grupos o departamentos basados en procesos incluyen:
• Operaciones de capacidad
Página 273
• Monitoreo y control de disponibilidad

• Gestión financiera de TI
• Administración de seguridad
• Gestión de activos y configuración (incluida la instalación de equipos
y despliegue ).
• Los procesos son más fáciles de definir

• Hay menos conflicto de roles que las descripciones del trabajo y las descripciones de los roles del proceso.
son lo mismo. En otras estructuras, una sola descripción de trabajo normalmente
incluir actividades para varios roles
• Las métricas del desempeño del equipo o departamento y el desempeño del proceso son
lo mismo, alineando eficazmente métricas 'internas' y 'externas'.
• Un principio básico de los procesos es que son un medio de vincular el

actividades de diversos departamentos y grupos. Al utilizar procesos como
base para el diseño organizacional , es necesario definir procesos adicionales para
asegurarse de que los departamentos trabajen juntos.
• Incluso si un departamento es responsable de ejecutar un proceso , todavía habrá
Ser dependencias externas. Los grupos no pueden ver las actividades del proceso fuera de
de su propio proceso como importante, lo que resulta en procesos que no pueden
se ejecutará por completo porque las dependencias no se pueden cumplir.
• Si bien algunos aspectos de un proceso pueden centralizarse, siempre habrá
una serie de actividades que deberán ser realizadas por otros grupos. los
relación entre el equipo o departamento dedicado y las personas
realizar las actividades descentralizadas es a menudo difícil de definir y
administrar.
6.7.4 Organización de las operaciones de TI por geografía

Las operaciones de TI se pueden distribuir físicamente y, en algunos casos, cada ubicación

debe organizarse de acuerdo con su propio contexto particular.
Esta estructura se utiliza normalmente en las siguientes circunstancias:
• Los centros de datos están distribuidos geográficamente

• Las diferentes regiones o países tienen diferentes tecnologías o proporcionan una
diferente conjunto de servicios
• Existen diferentes modelos de negocio o estructuras organizativas en el
diferentes regiones, es decir, el negocio está descentralizado por geografía y cada
La unidad de negocio es bastante autónoma
• Se aplica una legislación diferente a diferentes países o regiones (por ejemplo, seguridad
regulaciones)
Página 274
• Se aplican diferentes estándares a diferentes países o regiones

• Existen diferencias culturales o de idioma entre el personal que administra TI.
En la figura 6.9 se ofrece un ejemplo de este tipo de estructura. Tenga en cuenta que en este
ejemplo, cada departamento geográfico está estructurado internamente utilizando Technical
Especialización. Esto podría ser diferente en cada región. Por ejemplo una región
puede estructurarse de esta manera, mientras que otra región utiliza un proceso o actividad -
estructura basada.
Figura 6.9 Operaciones de TI organizadas según la geografía
La figura 6.9 también ilustra que una ubicación podría realizar operaciones centralizadas.
para todas las regiones si son lo suficientemente similares. En este ejemplo, el servidor americano
El Departamento de Operaciones gestiona todas las operaciones del servidor en todas las ubicaciones, Bruselas
gestiona todas las operaciones de la base de datos y Singapur gestiona todo el almacenamiento
operaciones.
Página 275
• La estructura de la organización se puede personalizar para cumplir con las condiciones locales
• Las operaciones de TI se pueden personalizar para cumplir con diferentes niveles de servicio de TI de
región a región.
• Las líneas de denuncia y las estructuras de autoridad pueden resultar confusas. Por ejemplo,
¿Las operaciones de red informan al administrador del centro de datos local o al
un administrador de operaciones de red centralizado?
• Los estándares operativos son difíciles de imponer, lo que resulta en inconsistencias y
actividades y herramientas duplicadas, lo que se traduce en economías de escala reducidas ,
lo que a su vez aumenta el costo total de las operaciones.
• Duplicación de roles , actividades, herramientas e instalaciones en múltiples ubicaciones
podría ser muy costoso.
• Los servicios compartidos, como el correo electrónico, son más difíciles de ofrecer, ya que
La organización regional opera de manera diferente.
• La comunicación con los clientes y dentro de TI será más difícil, ya que
no están ubicados en el mismo lugar y puede ser difícil para el personal de una ubicación
comprender las prioridades de los clientes o del personal en otra ubicación.
6.7.5 Estructuras organizativas híbridas
Es poco probable que la gestión de operaciones de TI se estructura con solo una

tipo de estructura organizativa. La mayoría de las organizaciones utilizan una especialización técnica,
con alguna actividad adicional - o departamentos basados en procesos.
El tipo de estructura utilizada y la combinación exacta de especialización técnica,

Los departamentos basados en actividades y procesos dependerán de una serie de
variables organizacionales.
Variables de estructura organizativa
Los criterios exactos elegidos y la estructura organizativa resultante dependerán

en una serie de variables, que pueden incluir:
•
•
La naturaleza del negocio
Requisitos y expectativas comerciales
• La arquitectura tecnológica y técnica
• La estabilidad de la infraestructura de TI actual y la disponibilidad de habilidades para
administrarlo
• El gobierno de la organización (es decir, la forma en que la autoridad se
se asignan y se toman decisiones, así como cualquier gobierno formal
marco que se utiliza, como COBIT o SOX)
Página 276
• El entorno legislativo, político y socioeconómico de la

organización
• El tipo y nivel de habilidades disponibles para la organización.
• El tamaño, la edad y la madurez de la organización.
• El estilo de gestión de la organización.
• La dependencia de las TI para las actividades críticas para el negocio, procesos y funciones s
• La forma en que TI participa en la red de valor (es decir, la forma en que TI
interactúa con la empresa y sus socios, proveedores y clientes )
• La relación entre TI y sus proveedores.
Para obtener una descripción más completa de cómo estos factores influyen en la organización
diseño , consulte la sección 'Desarrollo organizacional' del Servicio
Publicación de estrategia .
6.7.5.1 Funciones combinadas
Debería discutirse un último tipo de organización. Esta estructura incorpora TI

Departamentos de operaciones, gestión técnica y de aplicaciones en un solo
estructura. Este es a veces el caso en el que todos los grupos comparten el mismo
centro de datos. Aquí, el administrador del centro de datos asume la responsabilidad de todos los aspectos técnicos,
Gestión de aplicaciones y operaciones de TI .
Este tipo de estructura organizativa se ilustra en la Figura 6.10.
Página 277
Figura 6.10 Gestión de aplicaciones, técnica y operaciones de TI centralizadas

estructura
En esta estructura, la Gerencia de Operaciones de TI es responsable de los aspectos técnicos y

Funciones de gestión de aplicaciones , que a su vez son responsables de gestionar
sus propias actividades operativas . Cada departamento puede delegar algunos de
estas actividades al departamento de Control de Operaciones .
Las ventajas de esta estructura organizativa son:
• Hay mayor consistencia y control entre los más tácticos y
actividades de Gestión Técnica más operativas
• Es más fácil hacer cumplir los estándares de desempeño y los
arquitecturas que se crean en Service Design , ya que las personas que
Página 278
participaron en el diseño están gestionando las actividades de las personas que están
ejecutando esas actividades
• Como no hay duplicación entre ubicación o actividad , esta estructura es
a menudo más rentable.
La desventaja de esta estructura organizativa es:
• El alcance de esta estructura hace que sea muy difícil de gestionar eficazmente en
grandes organizaciones o en organizaciones con múltiples centros de datos.
6.7.5.2 Organización de la aplicación y la gestión técnica
Las organizaciones de gestión técnica y de aplicaciones tienden a ser

simple. Como se indica en los párrafos 6.3.4 y 6.5.6, Gestión técnica
Los departamentos generalmente se basan en la tecnología que administran y la aplicación
Departamentos de gestión de las aplicaciones y conjuntos de aplicaciones que
administrar.
Sin embargo, existen algunas estructuras organizativas alternativas y variaciones,

que se discuten en esta sección.
6.7.5.3 Geografía
En organizaciones con múltiples ubicaciones, es común que los técnicos y

Departamentos de Gestión de Aplicaciones que estarán representados en cada
localización. Sin embargo, esto no significa que cada ubicación tendrá todos los mismos
departamentos, o que todos son responsables de las mismas acciones.
A medida que las herramientas de gestión y soporte maduran, más y más infraestructura de TI y
Los CI de la aplicación se pueden gestionar de forma remota. Esto significa que cada departamento
contar con un equipo de gestión técnica o de aplicaciones sólido y centralizado, con
miembros para brindar apoyo o actividades especializadas en el lugar.
Por ejemplo, en Gestión de servidores , el equipo central ayudará a crear

s estándar para la configuración del servidor , supervisarán y controlarán los dispositivos remotos,
realizar copias de seguridad , realizar actualizaciones del sistema operativo, etc. Los equipos locales
proporcionar soporte básico en el sitio, mantenimiento y reparación de hardware y
configuración e instalación de nuevos servidores.
En Gestión de aplicaciones, el equipo central podría participar en el diseño continuo

y prueba de la aplicación , seguimiento y control; realizar copias de seguridad, datos
controles de integridad , etc. El equipo local podría brindar apoyo y educación en el lugar
a los usuarios finales y trabajar con el equipo de gestión técnica local para resolver
problemas más complejos que involucran equipos locales.
Página 279
Sin embargo, hay un problema potencial que debe resolverse y es quién

el equipo local reporta a. En algunas organizaciones reportan al gerente de la
equipo centralizado. Esto tiene la ventaja adicional de un rendimiento constante y
gestión en toda la empresa.
En otras organizaciones, los equipos locales informan al gerente de TI de mayor jerarquía en

ese sitio. Esto tiene la ventaja adicional de que los servicios de TI se pueden personalizar para
cumplen con las condiciones locales, pero crea mucha confusión sobre quiénes son los equipos locales
debe tomar la dirección desde.
• La estructura de la organización se puede personalizar para cumplir con las condiciones locales
• La gestión técnica y de aplicaciones se puede personalizar para cumplir
diferentes niveles de servicio de TI de una región a otra.
• Las líneas de denuncia y las estructuras de autoridad pueden resultar confusas

• Los estándares son difíciles de imponer, lo que resulta en inconsistencias y duplicaciones.
actividades y herramientas, lo que resulta en economías de escala reducidas , que a su vez
aumenta el costo total de las operaciones
• Duplicación de roles , actividades, herramientas e instalaciones en múltiples ubicaciones
podría ser muy costoso.
6.7.5.4 Estructura combinada de gestión técnica y de aplicaciones
Algunas organizaciones organizan su gestión técnica y de aplicaciones

funcionan según los sistemas. Esto significa que cada departamento estará compuesto por
especialistas en aplicaciones y especialistas técnicos en infraestructura de TI , todos orientados
hacia la gestión de los servicios basados en ese conjunto de sistemas. Componente s que
se comparten en todos estos sistemas, como la red, serán gestionados por
departamentos de Gestión Técnica dedicados .
La ventaja de esta estructura organizativa es:
• Es más fácil producir resultados de alta calidad para el usuario final porque todos
Los miembros del departamento se centran en el éxito del sistema como
en su conjunto, en lugar del rendimiento de un componente tecnológico individual
o aplicación .
Las desventajas de esta estructura organizativa son:
• La duplicación de habilidades y recursos en varios departamentos

aumentar el costo de la organización. Por ejemplo, es probable que cada grupo
Página 280
tener una persona o un equipo dedicado a administrar los servidores , cada uno de los cuales
hará tareas muy similares.
• La comunicación entre el personal que administra tecnología similar es
reducido. Esto reduce la cantidad de aprendizaje por experiencia y
aumenta la dependencia de las herramientas colaborativas de gestión del conocimiento .
• Cuando personas con habilidades similares están en el mismo departamento, la
El departamento compensará a los miembros con menor habilidad y competencia.
niveles. Cuando solo hay una persona con habilidades de administración de servidores en un
departamento basado en el sistema, y su competencia es mínima, afectará
el desempeño de todo el departamento.
Página 281
7 Consideraciones tecnológicas
Cada función y proceso se define en la sección correspondiente de los Capítulos 4 y 6.
Este capítulo reúne todos los requisitos tecnológicos para definir el
requisito de un conjunto integrado de tecnología de gestión de servicios para el servicio
Operación .
La misma tecnología, con algunas posibles adiciones, debería utilizarse para los demás
fases de ITSM - Estrategia del Servicio , Diseño Servicio , Transición del Servicio y
Mejora continua del servicio : para dar consistencia y permitir una
El ciclo de vida de ITSM se gestionará correctamente.
Los principales requisitos para la operación del servicio se establecen en este capítulo.
Página 282
7.1 Requisitos genéricos
Una tecnología ITSM integrada (o conjunto de herramientas, ya que algunos proveedores venden sus
tecnología como 'módulos', mientras que algunas organizaciones pueden optar por integrar
productos de proveedores alternativos) que incluye el siguiente núcleo
funcionalidad.
7.1.1 Autoayuda
Muchas organizaciones encuentran beneficioso ofrecer capacidades de 'Autoayuda' a sus usuarios.

Por lo tanto, la tecnología debe respaldar esta capacidad con algún tipo de web.
front-end que permite que las páginas web se definan ofreciendo una gama de menús de Self-
Solicitud de ayuda y servicio - con una interfaz directa en el proceso de back-end -
software de manipulación.
7.1.2 Flujo de trabajo o motor de proceso
Se necesita un motor de flujo de trabajo o de control de procesos para permitir la predefinición y

control de procesos definidos, como el ciclo de vida de un incidente, el cumplimiento de solicitudes
Ciclo de vida, ciclo de vida del problema, modelo de cambio , etc.
Esto debería permitir responsabilidades, actividades, escalas de tiempo, rutas de escalada y

alerta para ser predefinidos y luego administrados automáticamente.
7.1.3 CMS integrado
La herramienta debe tener un CMS integrado para permitir que la organización ‘s de TI

Activos de infraestructura , componentes , servicios y cualquier CI auxiliar (como
contratos , ubicaciones, licencias, proveedores , etc., cualquier cosa que la organización de TI
desea controlar ) que se mantendrá, junto con todos los atributos relevantes , en un
ubicación - y permitir que las relaciones entre cada uno se almacenen y mantengan,
y vinculado a Incidente, Problema, Error conocido y Registro de cambios como
apropiado.
7.1.4 Tecnología de descubrimiento / implementación / licencia
Para completar o verificar los datos del CMS y ayudar en la gestión de licencias,
Se requerirán herramientas de descubrimiento o auditoría automatizadas . Tales herramientas deben ser capaces
de ser ejecutado desde cualquier lugar de la red y permitir la interrogación y
recuperación de información relativa a todos los componentes que componen o están conectados
a la infraestructura de TI.
Dicha tecnología debería permitir el 'filtrado' para que los datos que se transfieren puedan
ser examinados y solo se extraigan los datos necesarios. También es muy útil si 'solo cambios'
ya que la última auditoría se puede extraer y reportar.
Página 283
La misma tecnología se puede utilizar a menudo para implementar nuevo software para apuntar
ubicaciones: este es un requisito esencial para todos los equipos de operación de servicio o
departamentos, para permitir que los parches, transportes, etc.se distribuyan a las
usuario s.
Es deseable una interfaz para las capacidades de 'Autoayuda' para permitir software aprobado
descargas para ser solicitadas de esta manera pero manejadas automáticamente por el
software de implementación .
Herramientas que permiten la comparación automática de los detalles de las licencias de software (en el
CMS, idealmente) y números de licencia reales implementados, con informes de cualquier
discrepancias - son extremadamente deseables.
7.1.5 Mando a distancia
A menudo es útil que los analistas de la mesa de servicio y otros grupos de apoyo estén
capaz de tomar el control del escritorio del usuario (bajo seguridad debidamente controlada
condiciones) para permitirles realizar investigaciones o corregir la configuración, etc.
Se necesitarán instalaciones que permitan este nivel de control remoto.
7.1.6 Utilidades de diagnóstico
Podría ser extremadamente útil para la mesa de servicio y otros grupos de apoyo si el
La tecnología incorporó la capacidad de crear y utilizar secuencias de comandos de diagnóstico y
otras utilidades de diagnóstico (como, por ejemplo, herramientas de razonamiento basadas en casos) para
ayudar con el diagnóstico temprano de incidentes. Idealmente, estos deberían ser 'contexto
sensible 'y presentación de los scripts automatizada en la medida de lo posible.
7.1.7 Informes
No sirve de nada almacenar datos a menos que se puedan recuperar y utilizar fácilmente para cumplir
los propósitos de la organización. Por tanto, la tecnología debe incorporar buenos
capacidades de informes, así como permitir interfaces estándar que se pueden utilizar para
introducir datos en paquetes de informes estándar de la industria, paneles de control , etc. Idealmente,
Se pueden proporcionar informes instantáneos, en pantalla e impresos mediante el uso de
informes de los "diez primeros" sensibles al contexto.
7.1.8 Paneles de control
La tecnología tipo tablero es útil para permitir una visibilidad general de 'ver de un vistazo'
Niveles de disponibilidad y rendimiento del servicio de TI . Estas pantallas se pueden incluir en
informes de nivel de gestión para los usuarios y los clientes , pero también pueden proporcionar en tiempo real
información para su inclusión en las páginas web de TI para proporcionar informes dinámicos, y puede ser
utilizado con fines de apoyo e investigación. Capacidades de soporte personalizado
Las vistas de información para satisfacer niveles específicos de interés pueden ser particularmente útiles.
Página 284
Sin embargo, a veces representan una visión técnica más que de servicio de la
infraestructura y en tales casos pueden ser de menor interés para los clientes y
usuarios.
7.1.9 Integración con la gestión de servicios empresariales
Existe una tendencia dentro de la industria de TI para tratar de unir la TI relacionada con el negocio
con los procesos y disciplinas de la Gestión de Servicios de TI - algunos llaman a esto
Gestión de servicios empresariales . Para facilitar esto, las aplicaciones y herramientas comerciales
deben estar interconectados con las herramientas de soporte de ITSM para brindar la funcionalidad requerida.
Esto se puede ilustrar con este ejemplo:
Una empresa de telecomunicaciones de Europa del Este pudo interconectar su teléfono celular:
sistema de facturación y monitoreo de red a su Gestión de Eventos , Incidentes
Procesos de Gestión y Gestión de la Configuración . De esta manera pudo
para detectar patrones de facturación / uso inusuales e interpretarlos de manera que
identificar, con un alto grado de certeza, que un teléfono había sido robado y
estaba siendo utilizado para realizar llamadas ilícitas.
Pudo generar eventos para tales patrones y automatizar acciones para suspender
uso de los dispositivos de telefonía móvil y, en paralelo, identificar la ubicación exacta de
el usuario ilícito (utilizando tecnología GPRS) y plantear incidencias para que la policía hubiera
la capacidad de encontrar al presunto ladrón y recuperar el dispositivo.
Se necesitan capacidades de integración de herramientas más avanzadas para permitir una mayor
explotación de este tipo de negocios e integración de TI.
Página 285
7.2 Gestión de eventos
Las siguientes características son deseables para cualquier tecnología de gestión de eventos:
• Interfaz abierta multi-ambiental para permitir el monitoreo y las alertas a través de

servicios heterogéneos y toda la infraestructura de TI de una organización .
• Fácil de implementar, con un costo de instalación mínimo .
• Agentes 'estándar' para monitorear los más comunes
medio ambiente s / componentes / sistemas.
• Interfaces abiertas para aceptar cualquier entrada de evento estándar (por ejemplo, SNMP) y
generación de alertas múltiples.
• Enrutamiento centralizado de todos los eventos a una única ubicación, programable para
Permitir diferentes ubicaciones en distintos momentos.
• Soporte para las fases de diseño / prueba , para que se puedan implementar nuevos servicios / aplicaciones.
monitoreado durante las fases de diseño / prueba y los resultados retroalimentados en el diseño
y transición.
• Programable evaluación y manejo de alerta s dependiendo
síntomas e impacto .
• La capacidad de permitir que un operador reconozca una alerta, y si no
La respuesta se ingresa dentro de un período de tiempo definido, para escalar la alerta.
• Buena funcionalidad de informes para permitir retroalimentación en el diseño y la transición
fases, así como una información de gestión significativa y un usuario empresarial
' tablero '.
Dicha tecnología debe permitir una interfaz directa con el incidente de la organización .
Los procesos de gestión (mediante la entrada en el Registro de incidentes), así como la capacidad
para escalar al personal de soporte, proveedores externos, ingenieros, etc.por correo electrónico, SMS
mensajería, etc.
Se necesitarán instalaciones especializadas, o quizás herramientas especializadas independientes, para

seguimiento del sitio web . Tales instalaciones deben poder simular el tráfico de clientes en
el sitio web y para informar sobre la disponibilidad y el rendimiento en relación con el
'experiencia del cliente'.
Página 286
7.3 Gestión de incidentes

7.3.1 Tecnología ITSM integrada
Se requiere tecnología ITSM integrada que tenga la siguiente funcionalidad:
• Un CMS integral que permite establecer relaciones automatizadas y

mantenido entre los incidentes, solicitudes de servicio s, problema s, Conocido error s
y todos los demás elementos de configuración .
• El CMS que se puede utilizar para ayudar a determinar la prioridad y ayudar en
investigación y diagnóstico .
• Un motor de flujo de proceso para permitir que los procesos sean predefinidos (incluyendo
modelos de incidentes definidos , ver párrafo 3.2.1.5) y automáticamente
controlado: con enrutamiento interno flexible a todos los grupos de apoyo relevantes y
Interfaces externas de correo electrónico / SMS.
• Capacidades automatizadas de alerta y escalamiento para evitar que se produzca un incidente.
pasado por alto o retrasado.
• Abra la interfaz de gestión de eventos herramientas, de modo que cualquier fallo de s puede ser
planteados automáticamente como incidentes.
• Una interfaz web para permitir la entrada de solicitudes de autoayuda y servicio a través de
Pantallas de Internet / Intranet.
• Un KEDB integrado para diagnosticar y / o resolver incidencias / problemas
se puede registrar y buscar para ayudar a acelerar futuros incidentes
resolución .
• Fácil de usar las instalaciones para permitir la notificación de incidentes métricas s para ser producido
y para facilitar el análisis de incidentes para la gestión de problemas y la disponibilidad
Fines de gestión.
• Herramientas de diagnóstico (integradas o interfaces para productos separados), como
ya mencionado en Service Desk .
7.3.2 Flujo de trabajo y escalamiento automático
Los tiempos objetivo deben incluirse en las herramientas de apoyo, que deben utilizarse para
Automatice el control del flujo de trabajo y las rutas de escalamiento .
Si, por ejemplo, un grupo de apoyo de segunda línea no ha resuelto un incidente dentro de un
Objetivo acordado de 60 minutos, el incidente debe enrutarse automáticamente al
grupo de apoyo de tercera línea apropiado (determinado por la categorización del incidente) - y
cualquier escalada jerárquica necesaria debe realizarse automáticamente (p. ej.
Mensaje SMS al administrador de la mesa de servicio, al administrador de incidentes y / o al departamento de TI
Gerente de Servicios y quizás al usuario , si corresponde). La segunda linea
El grupo de apoyo debe ser informado de la acción de escalada como parte del proceso automatizado.
proceso .
Página 287
7.4 Cumplimiento de la solicitud
Se necesita tecnología ITSM integrada para que las solicitudes de servicio se puedan vincular a
incidentes o eventos que los han iniciado (y han sido almacenados en el mismo CMS,
que se puede interrogar para informar sobre los SLA). Algunas organizaciones serán
contenido para utilizar el elemento de gestión de incidentes de dichas herramientas y para tratar
Solicitudes de servicio como subconjunto y categoría definida de incidentes. Donde un
organización elige generar Solicitudes de servicio por separado, requerirá una herramienta
lo que permite esta capacidad .
Se necesitarán capacidades de autoayuda de front-end para permitir a los usuarios enviar solicitudes
a través de algún tipo de proceso de selección basado en la web y basado en menús.
En todos los demás aspectos, las instalaciones necesarias para gestionar las solicitudes de servicio son muy
similares a los de la gestión de incidentes: control de flujo de trabajo predefinido de Solicitud
Modelos , niveles de prioridad , escalado automático, informes efectivos, etc.
Página 288
7.5 Gestión de problemas
7.5.1 Tecnología de gestión de servicios integrados
Se necesita una herramienta ITSM integrada que distinga entre incidentes y
problema s - de modo
causas subyacentes de que se puedan generar
los incidentes, registros adelos
pero vinculadas problemas
incidentesseparados para tratar
relacionados. los
La funcionalidad de los registros de problemas debe ser similar a las necesarias para el incidente.
Registre sy también permita la coincidencia de múltiples incidentes con los registros de problemas.
7.5.2 Gestión de cambios
La integración con la Gestión de cambios es muy importante, por lo que Solicitud, Evento,
Los registros de incidentes y problemas pueden estar relacionados con RFC que han causado
problema s. Esto es para evaluar el éxito del proceso de Gestión del Cambio :
así como los registros de incidentes y errores conocidos , y para que los RFC puedan ser fácilmente
planteado para controlar las actividades necesarias para superar los problemas que se han
identificados a través del análisis de causa raíz o análisis de tendencias proactivo .
7.5.3 CMS integrado
También es importante tener un CMS integrado que permita a los registros de problemas
estar vinculado a los componentes afectados y los servicios afectados, y a cualquier
otros IC relevantes.
La gestión de la configuración forma parte de un SKMS más grande que incluye vínculos
a muchos de los repositorios de datos utilizados en las operaciones de servicio . El proceso y
prácticas de Gestión de la Configuración y sus tecnologías subyacentes
Los requisitos se incluyen en la publicación Transición del servicio .
7.5.4 Base de datos de errores conocidos
Un KEDB efectivo será un requisito esencial, lo que debería permitir una fácil
almacenamiento y recuperación de datos de errores conocidos .
Se necesitan buenas instalaciones de informes para facilitar la producción de gestión

informes, permitiendo que los datos se incorporen automáticamente sin necesidad de
reingreso de datos, y para permitir capacidades de desglose para Incidentes y Problemas
Análisis.
Nota: En algunos casos, los componentes o sistemas que está investigando el problema
La administración puede ser proporcionada por terceros proveedores o fabricantes. A
Para solucionar este problema, es posible que también sea necesario utilizar las herramientas de soporte de los proveedores y / o los KEDB.
Página 289
7.6 Gestión de acceso
La gestión de acceso utiliza una variedad de tecnologías, principalmente:
• Tecnología de Gestión de Recursos Humanos, para validar la identidad de

usuarios y para rastrear su estado
• Tecnología del servicio de directorio (consulte la sección 5.8 para obtener una descripción de
Directorio de Servicios). Esta tecnología permite a los gerentes de tecnología
asignar nombres a los recursos en una red y luego proporcionar acceso a esos
recursos basados en el perfil del usuario. Las herramientas de servicios de directorio también
habilitar Access Management para crear roles y grupos y vincularlos
tanto para los usuarios como para los recursos
• Funciones de gestión de acceso en aplicaciones, middleware , funcionamiento
Sistemas y sistemas operativos de red
• Sistemas de gestión de cambios
• Solicitar tecnología de cumplimiento (consulte la sección 7.4).
Página 290
7.7 Mesa de servicio
Se deben proporcionar herramientas adecuadas y soporte tecnológico para permitir el servicio.

Personal de escritorio para desempeñar sus funciones de la manera más eficiente y efectiva posible. Esta voluntad
Incluya lo siguiente.
7.7.1 Telefonía
Porque es probable que un alto porcentaje de incidentes se planteen mediante llamadas telefónicas
de los usuarios , el Service Desk debe contar con una buena y moderna telefonía
servicios. Esto debe incluir:
• Un sistema automatizado de llamada de distribución (ACD) del sistema para permitir que un solo teléfono
número (o números si un Service Desk distribuido o segmentado es el
opción preferida) y capacidades de recogida en grupo. Advertencia: si las opciones son
ofrecido a través de ACD, mediante teclado o reconocimiento de voz interactivo (IVR)
selección, no utilice demasiados niveles de opciones ni ofrezca ambigüedades
opciones. Tampoco incluya ningún 'callejón sin salida' u opción que, una vez
elegido, no permita que la persona que llama vuelva a los menús anteriores.
• Software Computer Telephony Interface (CTI) para permitir el reconocimiento de llamadas
(a través del ACD vinculado) y la población automatizada de los detalles del usuario en
el registro de incidentes del CMS.
• VoIP - uso de esta tecnología puede reducir significativamente la telefonía costo s
al tratar con usuarios remotos e internacionales
• Software estadístico que permite recopilar estadísticas de telefonía y
interrogado / impreso para análisis - esto debería permitir lo siguiente
información a obtener para cualquier período seleccionado:
• Número de llamadas recibidas, en total y desglosadas por cualquier 'división' -
donde cualquier enrutamiento de llamadas ha sido elegido y proporcionado por un
Respuesta del sistema / teclado IVR
• Perfiles de llegada de llamadas y tiempos de respuesta
• Tasas de abandono de llamadas
• Tarifas de manejo de llamadas por manejadores de llamadas individuales del Service Desk
• Duraciones promedio de llamadas
• Auriculares manos libres, con capacidad de acceso para dos usuarios (al menos en
algunos de los auriculares) para su uso durante la formación de personal nuevo, etc.
7.7.2 Herramientas de soporte
Hay una gama de herramientas de soporte de Service Desk independientes disponibles en el

marketplace, y algunas organizaciones pueden optar por producir sus propios
sistema de registro / gestión de incidentes s. Si una organización tiene la intención seria de
implementar ITSM, entonces se requerirá un conjunto de herramientas ITSM totalmente integrado que tenga un
CMS en el centro y proporciona soporte integrado para todos los elementos definidos por ITIL .
Procesos.
Página 291
Elementos específicos de dicha herramienta que serán particularmente beneficiosos para el Servicio.
El escritorio incluye lo siguiente.
7.7.2.1 Base de datos de errores conocidos
Se debe utilizar un KEDB integrado para almacenar detalles de

incidentes / problemas y su resolución , de modo que cualquier recurrencia pueda ser más
diagnosticado y reparado rápidamente.
Para facilitar esto, se necesita funcionalidad para categorizar y recuperar rápidamente

Errores conocidos anteriores , utilizando la coincidencia de patrones y la búsqueda de palabras clave contra
síntomas. La gestión del KEDB es responsabilidad del Problema
Administración , pero la Mesa de Servicio lo utilizará para ayudar a acelerar el manejo de incidentes.
7.7.2.2 Scripts de diagnóstico
Se deben desarrollar, almacenar y administrar secuencias de comandos de diagnóstico multinivel para permitir
El personal de la mesa de servicio para identificar la causa de las fallas . Grupos de apoyo especializados y
proveedor s se debe pedir a proporcionar detalles de las posibles averías y la clave
preguntas que se deben hacer para identificar exactamente qué ha fallado, y para obtener detalles de
las acciones de resolución a tomar.
Estos detalles deben incluirse en secuencias de comandos sensibles al contexto que deben
aparecer en la pantalla, dependiendo de la categorización multinivel del incidente ,
y debe basarse en las respuestas del usuario a las preguntas de diagnóstico.
7.7.2.3 Interfaz web de autoayuda
A menudo es rentable y conveniente proporcionar alguna forma automatizada de

Funcionalidad de ayuda, para que los usuarios puedan buscar y obtener ayuda que les permitirá
ellos para resolver sus propias dificultades. Idealmente, esto debería ser a través de una web 24 horas al día, 7 días a la semana.
interfaz que es impulsada por la selección del menú y puede incluir, según corresponda:
• Preguntas frecuentes (FAQ) y soluciones.

• Capacidades de búsqueda de 'Cómo hacer': para guiar a los usuarios a través de una
lista de tareas o actividades.
• Un servicio tipo boletín que contiene detalles de un servicio destacado.
problemas / problemas junto con los tiempos de restauración anticipados.
• Capacidades de cambio de contraseña: uso de protección de contraseña segura
software para verificar identidades, realizar autorizaciones y cambiar contraseñas
sin necesidad de la intervención de Service Desk .
• Descargas de correcciones de software (parches, paquetes de servicios, correcciones de errores, etc.
determinado que el usuario tiene la versión incorrecta o se necesita una solución) - herramientas
están disponibles para automatizar el proceso de verificación , para comparar el
imagen de escritorio con las compilaciones 'estándar' acordadas y para permitir actualizaciones a
ser ofrecidos y aceptados cuando sea necesario.
Página 292
• Reparación de software s: donde se detecta que puede haber una corrupción

ocurrido, para permitir correcciones de software, eliminación y / o reinstalación.
• Solicitudes de eliminación de software: se completan automáticamente con cualquier licencia
siendo devuelto a la piscina.
• Descargas de paquetes de software adicionales: hay herramientas disponibles para comprobar
una política de software predefinida y para permitir la descarga de
paquetes de software, si están cubiertos por la póliza. Esto puede incluir automatizado
verificaciones de licencias de software y aprobaciones financieras, así como actualización de CMS.
• Aviso anticipado de cualquier tiempo de inactividad planificado o interrupciones del servicio o
degradaciones.
La solución de autoayuda debe incluir la capacidad para que los usuarios registren incidentes.
ellos mismos, que se pueden utilizar durante los períodos en que el Service Desk está cerrado (si
no opera 24 horas al día, 7 días a la semana) y atendido por el personal de Service Desk al comienzo del próximo
turno .
Se debe tener cierto cuidado para garantizar que las actividades de autoayuda seleccionadas para
la inclusión no es demasiado avanzada para el usuario medio, y que las salvaguardas son
incluido para evitar que un "pequeño conocimiento sea algo peligroso". Puede ser
posible ofrecer facilidades de autoayuda un poco más avanzadas a los "superusuarios" que
han tenido entrenamiento adicional. También es necesario tener mucho cuidado con los supuestos.
realizado al dotar de personal a una mesa de servicio sobre la cantidad de uso que harán los usuarios
de las instalaciones de autoayuda.
Nota: Como ya se ha cubierto en la lista anterior, es posible combinar algunos

Solicitar actividades de cumplimiento como parte de un sistema de autoayuda general , que puede
también será de gran beneficio para reducir las llamadas al Service Desk
7.1.1 para más detalles).
7.7.2.4 Mando a distancia
Como ya se dijo, pero se repite aquí para completar, a menudo es útil para la
Analistas de Service Desk para poder tomar el control del escritorio del usuario para
permitirles realizar investigaciones o corregir la configuración, etc. Instalaciones para permitir
este nivel de control remoto será necesario.
7.7.3 Planificación de la continuidad del servicio de TI para las herramientas de soporte de ITSM
Es probable que las organizaciones dependan rápidamente de sus herramientas ITSM y

le resultará difícil trabajar sin ellos. Un análisis de riesgo y de impacto empresarial completo
Deben realizarse análisis y luego desarrollarse planes para garantizar que la TI sea adecuada .
Niveles de continuidad y resiliencia del servicio .
Página 293
8 Consideraciones de implementación
Cabe señalar que la operación del servicio es una fase de un ciclo de vida y no una
entidad por derecho propio. Para cuando un servicio, proceso , estructura organizativa o
la tecnología está funcionando, ya se ha implementado. Sin embargo, hay una
número de procesos y funciones descritos en esta publicación, y es
Por lo tanto, es importante abordar las consideraciones de implementación que deben
se han abordado en el momento en que entren en funcionamiento .
Varios de estos se han cubierto en la sección correspondiente, por ejemplo

En el Capítulo 6 se proporciona orientación sobre las estructuras organizativas y los roles .
no se repetirá aquí. Más bien, esta sección se centrará en algunos
guía de implementación para la operación del servicio en su conjunto.
Página 294
8.1 Gestión de cambios en la operación del servicio
La operación de servicio debe esforzarse por lograr la estabilidad, ¡pero no el estancamiento! Allí
Hay muchas razones válidas y ventajosas por las que 'el cambio es algo bueno', pero
El personal de operaciones de servicio debe asegurarse de que cualquier cambio se absorba sin
impacto adverso sobre la estabilidad de los servicios de TI que se ofrecen.
8.1.1 Cambiar desencadenantes
Hay muchas cosas que pueden desencadenar un cambio en la operación del servicio.
medio ambiente . Éstos incluyen:
• Nuevo o actualizado de hardware o de red componente s

• Software de aplicación nuevo o actualizado
• Software de sistema nuevo o actualizado (sistemas operativos, utilidades,
middleware, etc., incluidos parches y correcciones de errores
• Cambios legislativos, de conformidad o de gobernanza
• Obsolescencia: algunos componentes pueden volverse obsoletos y requerir
reemplazo o dejar de ser respaldado por el proveedor / mantenedor
• Es imperativo empresarial: debe ser flexible para trabajar en ITSM, especialmente
durante la operación del servicio, y habrá muchas ocasiones en las que el
negocio necesita cambios de TI para satisfacer dinámica de negocio requisito s
• Mejoras en los procesos, procedimientos y / o herramientas de apoyo para
mejorar la entrega de TI o reducir financieros de costos s
• Cambios de dirección o personal (que van desde la pérdida o transferencia de
individuos hasta importantes adquisiciones o adquisiciones)
• Cambio de nivel de servicio so en la prestación de servicios : subcontratación , subcontratación ,
asociaciones , etc.
8.1.2 Evaluación de cambios
El personal de operación del servicio debe participar en la evaluación de todos los cambios
asegurarse de que se tengan plenamente en cuenta las cuestiones operativas . Esta participación
debe comenzar lo antes posible (ver párrafo 4.6.1) no solo en el último
etapas de cambio , es decir, membresía de CAB y ECAB, en cuyo momento muchos
se habrán tomado decisiones fundamentales y es probable que la influencia sea muy
limitado. El administrador de cambios debe informar a todas las partes afectadas del cambio.
siendo evaluados para que los aportes puedan estar preparados y disponibles antes de las reuniones del CAB.
Sin embargo, es importante que el personal de Operaciones del Servicio participe en estos últimos
etapas, ya que pueden estar involucrados en la implementación real y desearán
Asegurarse de que se lleve a cabo una programación cuidadosa para evitar posibles disputas o
períodos particularmente sensibles.
Página 295
8.1.3 Medición del cambio exitoso
La máxima medida de éxito con respecto a los cambios realizados en el Servicio.

La operación es que los clientes y usuarios no experimenten ninguna variación o interrupción
de servicio. En la medida de lo posible, los efectos de los cambios deben ser invisibles, aparte
de cualquier funcionalidad mejorada, calidad o ahorros financieros resultantes de la
cambio.
Página 296
8.2 Operación del servicio y gestión de proyectos
Debido a que la Operación del Servicio se considera generalmente como "el negocio habitual" y, a menudo,
centrado en ejecutar procedimientos definidos de manera estándar, existe una tendencia
No utilizar los procesos de Gestión de proyectos cuando de hecho serían
apropiado. Por ejemplo, importantes actualizaciones de infraestructura o la implementación de
procedimientos nuevos o modificados , son tareas importantes en las que el proyecto formal
La administración se puede utilizar para mejorar el control y administrar los costos / recursos .
El uso de la Gestión de proyectos para gestionar estos tipos de actividad tendría la

siguientes beneficios:
• Los beneficios del proyecto están claramente establecidos y acordados.

• Hay más visibilidad de lo que se está haciendo y cómo se está gestionando,
lo que facilita que otros grupos de TI y la empresa cuantifiquen la
contribuciones de los equipos operativos
• Esto, a su vez, facilita la obtención de fondos para proyectos que tienen
tradicionalmente ha sido difícil justificar el costo
• Mayor consistencia y calidad mejorada
• El logro de los objetivos da como resultado una mayor credibilidad para las operaciones
grupos
Página 297
8.3 Evaluación y gestión de riesgos en la operación del servicio
Habrá varias ocasiones en las que será imperativo que la evaluación de riesgos
al servicio La operación se lleva a cabo y se actúa rápidamente.
El área más obvia es evaluar el riesgo de cambios potenciales o conocidos.

Error s (ya cubierto en otra parte) pero además el personal de operación de servicio puede
deben participar en la evaluación del riesgo y el impacto de:
• Fallos o posibles fallos , ya sea informados por Event Management o

Gestión de incidentes / problemas , o advertencias de los fabricantes,
proveedores o contratistas
• Nuevos proyectos que, en última instancia, darán como resultado la entrega al entorno en vivo.
• Riesgo medioambiental (que abarca los riesgos de tipo Continuidad del servicio de TI para el
entorno físico y local, así como político, comercial o
riesgos relacionados con las relaciones laborales)
• Proveedores, especialmente cuando hay nuevos proveedores involucrados o cuando es clave
los componentes del servicio están bajo el control de terceros
• Los riesgos de seguridad - tanto teórica o real que surge de seguridad relacionados
incidentes o eventos s
• Nuevo cliente / s servicios que se apoyarán
Página 298
8.4 Personal operativo en Diseño y Transición de Servicios
Todos los grupos de TI participarán durante el diseño del servicio y la transición del servicio a
Asegurarse de que los nuevos componentes o servicios se diseñen, prueben e implementen para
proporcionar los niveles correctos de funcionalidad, usabilidad , disponibilidad , capacidad , etc.
Además, el personal de Operación del Servicio debe participar durante las primeras etapas de
Diseño de servicios y transición de servicios para garantizar que cuando lleguen nuevos servicios
el entorno en vivo que son adecuados para su propósito , desde una Operación de servicio
perspectiva, y son 'compatibles' en el futuro.
En este contexto, 'soportable' significa:
• Capaz de ser apoyado desde un punto de vista técnico y operativo

desde dentro de los niveles de habilidades y recursos adicionales existentes o previamente acordados
• Sin impacto adverso en otros trabajos técnicos u operativos existentes
prácticas , procesos u horarios
• Sin ningún costo operativo inesperado , continuo o creciente
gastos de apoyo
• Sin complicaciones contractuales o legales inesperadas
• No hay rutas de soporte complejas entre múltiples departamentos de soporte de terceros
organizaciones del partido.
Nota: El cambio no se trata solo de tecnología. También requiere formación, sensibilización,

cambio cultural, cuestiones de motivación y mucho más. Más detalles sobre
La gestión más amplia del cambio se trata en la publicación Transición del servicio.
Página 299
8.5 Planificación e implementación de la gestión de servicios

tecnologias
Hay una serie de factores que las organizaciones deben planificar para estar preparados
para y durante el despliegue e implementación de herramientas de soporte de ITSM. Estos
8.5.1 Licencias
El costo total de las herramientas ITSM, particularmente la herramienta integrada que formará el
corazón del conjunto de herramientas requerido, generalmente se determina por el número y tipo de
licencias de usuario que necesita la organización .
Estas herramientas se venden a menudo en formato modular, por lo que la funcionalidad exacta de cada
El módulo debe entenderse bien y se debe realizar un dimensionamiento inicial para
determinar cuántos (y qué tipo) de usuarios necesitarán acceder a cada
módulo.
Las licencias suelen estar disponibles en los siguientes tipos (la terminología exacta puede
varían según el proveedor de software ).
8.5.1.1 Licencias dedicadas
Para uso del personal que requiera un uso frecuente y prolongado del módulo
(p . ej ., el personal de la mesa de servicio necesitaría una licencia dedicada para usar un incidente
Módulo de gestión ).
8.5.1.2 Licencias compartidas
Para el personal que hace un uso bastante regular del módulo, pero con intervalos importantes
en el medio, por lo que generalmente se puede administrar con una licencia compartida (por ejemplo , soporte de tercera línea
El personal puede necesitar acceso regular a un módulo de gestión de incidentes, pero solo en
momentos en los que están actualizando activamente un registro de incidentes ). La proporción de requerido
Es
ser necesario
compradoestimar las licencias
- esto dependerá delpara los usuarios,
número de modo
de usuarios que selapueda
potenciales, calcular
duración de el número correcto de licencias.
períodos de uso y la frecuencia esperada entre usos para dar una estimación
nivel de concurrencia .
El costo de una licencia compartida suele ser más caro que el de una licencia dedicada.
licencias, pero el costo general es menor, ya que los usuarios comparten y hay menos licencias
por lo tanto necesario en total.
8.5.1.3 Licencias web
Por lo general, permite alguna forma de 'interfaz ligera' a través del acceso web a la herramienta
capacidades, esto suele ser adecuado para el personal que requiere acceso remoto, solo
Página 300
acceso ocasional o uso de solo un pequeño subconjunto de la funcionalidad (p. ej.

personal de ingeniería que desee registrar detalles de las acciones tomadas en incidentes o usuarios simplemente
querer registrar un incidente directamente). Las licencias web suelen costar mucho menos que
otras licencias (¡incluso pueden ser gratuitas con otras licencias!) y la proporción de uso también es
a menudo más bajos, por lo que los costos generales se reducen aún más.
Tenga en cuenta que algunos miembros del personal pueden requerir acceso a varias licencias (por ejemplo, personal de soporte
puede requerir una licencia dedicada o compartida cuando esté en la oficina durante el día, pero
puede requerir una licencia web cuando se brinda soporte fuera de horario desde casa).
Tenga en cuenta que las licencias pueden ser necesarias para los clientes / usuarios / proveedores que utilizan
la misma herramienta para ingresar, ver o actualizar registros o informes.
Nota: Algunos acuerdos de licencia (de cualquiera de los tipos mencionados anteriormente) pueden
¡Restrinja el uso del software a un dispositivo individual o CPU!
8.5.1.4 Servicio a pedido
Ha habido una tendencia en la industria de TI para el proveedor s para ofrecer TI de aplicaciones s

'bajo demanda', donde se da acceso a la aplicación por un período de demanda y
luego se corta cuando ya no se necesita, y se carga en función del tiempo
gastado usando la aplicación. Algunos ITSM pueden ofrecer este tipo de oferta.
proveedores de herramientas, lo que podría resultar atractivo para organizaciones más pequeñas o si las herramientas en
Las preguntas son muy especializadas y se utilizan con relativa poca frecuencia.
Una alternativa a esto es cuando se ofrece el uso de una herramienta como parte de una
asignación de consultoría (por ejemplo, una consultoría especializada en gestión de capacidad ,
digamos, que puede ofrecer una planificación de capacidad regular pero relativamente infrecuente
paquete de consultoría y proporcionar el uso de las herramientas durante la duración del
asignación). En tales casos, es probable que los derechos de licencia se incluyan como parte de,
o, una adición al honorario de consultoría.
Una variación adicional es cuando el software se licencia y se carga a un agente / actividad

base. Un ejemplo de esto es el software de interrogación / monitoreo y / o simulación
(por ejemplo, software de agente que puede simular rutas de cliente predefinidas a través de un
sitio web de la organización , para evaluar e informar sobre el rendimiento y la disponibilidad ).
Este software se suele cobrar en función del número de agentes, su
ubicación y / o cantidad de actividad generada.
En todos los casos, se deben investigar y realizar investigaciones completas de la estructura de la concesión de licencias.
bien entendido durante las investigaciones de adquisiciones y mucho antes de que las herramientas sean
implementado, de modo que los costos finales no sean una sorpresa.
8.5.2 Despliegue
Muchas herramientas ITSM, en particular las herramientas de detección y monitoreo de eventos, requerirán
algún software de cliente / agente que se implementa en todas las ubicaciones de destino antes de que puedan ser
Página 301
usado. Esto requerirá una planificación y ejecución cuidadosas , y debe manejarse

a través de la gestión formal de lanzamiento y despliegue (consulte Transición del servicio
publicación).
Incluso cuando la implementación de la red es posible, esto requiere una programación y

pruebas, y los registros deben mantenerse durante todo el lanzamiento para que el soporte
el personal tiene conocimiento de quién ha sido actualizado y quién no. Alguna forma de
La gestión de cambios provisional puede ser necesaria y el CMS debe actualizarse
a medida que avanza el lanzamiento.
A menudo es necesario reiniciar los dispositivos para que el software del cliente sea
reconocido, y esto debe organizarse con anticipación, de lo contrario, largas demoras
puede ocurrir si el personal generalmente no apaga sus escritorios durante la noche.
Puede haber problemas particulares al implementarlo en laptops y otros dispositivos portátiles.

puede ser necesario equipo y arreglos especiales para que el personal inicie sesión y
recibir el nuevo software.
8.5.3 Comprobaciones de capacidad
Es posible que sea necesaria alguna gestión de la capacidad de antemano para garantizar que todos los
las ubicaciones de destino tienen suficiente capacidad de almacenamiento y procesamiento para alojar y
ejecutar el nuevo software, cualquiera que no pueda necesitará actualización o reemplazo, y
los plazos de ejecución de estas acciones deben incluirse en los planes .
También debe comprobarse la capacidad de la red para establecer si puede

manejar la transmisión de información de gestión , la transmisión de archivos de registro
y la distribución de clientes, y también posiblemente software y archivos de configuración .
8.5.4 Momento del despliegue de la tecnología
Es necesario tener cuidado para garantizar que las herramientas se implementen en el momento adecuado en
relación con el nivel de sofisticación y conocimiento de ITSM de la organización . Si herramientas
se despliegan demasiado pronto, pueden verse como una panacea inmediata y cualquier
La acción necesaria para cambiar los procesos, las prácticas de trabajo o las actitudes puede ser
obstaculizado o pasado por alto.
Una herramienta por sí sola no suele ser suficiente para que las cosas funcionen mejor. Hay un viejo
adagio: "¡Un tonto con una herramienta sigue siendo un tonto!"
La organización debe examinar primero los procesos que la herramienta está buscando para
abordar y también asegurarse de que el personal esté `` comprado '' en los nuevos procesos y formas
de trabajar y adoptar una " cultura de servicio ".
Página 302
Sin embargo, las herramientas pueden, y a menudo lo hacen, hacer que las cosas sean una realidad para muchas personas.
personal tangible y técnico puede ver inmediatamente cómo los nuevos procesos pueden
trabajar y cómo pueden mejorar su forma de trabajar.
Algunos procesos simplemente no se pueden realizar sin las herramientas adecuadas, por lo que hay una
Se debe realizar un cuidadoso equilibrio para garantizar que las herramientas se introduzcan cuando se necesiten
- ¡pero no antes!
De manera similar, se debe tener cuidado para garantizar que se brinde capacitación en cualquier herramienta en el
punto correcto: no demasiado pronto o el conocimiento disminuirá o se perderá, pero temprano
lo suficiente para que el personal pueda recibir capacitación formal y familiarizarse completamente con
el funcionamiento de las herramientas mucho antes de la implementación en vivo . Entrenamiento adicional
debe planificarse para un período adicional cuando las herramientas se pongan en funcionamiento y en el
futuro, según sea necesario.
8.5.5 Tipo de introducción
Se necesita una decisión sobre qué tipo de presentación se necesita: si optar por un
Introducción al 'Big Bang' o algún tipo de enfoque por fases. Como la mayoría de las organizaciones
no partirá de una situación de 'campo verde' y tendrá servicios en vivo para mantener
durante la introducción, es más probable que se aplique un enfoque por fases.
necesario.
En muchos casos, una nueva herramienta reemplazará a una más antigua, probablemente menos sofisticada,
herramienta y el cambio entre los dos es otro factor a planificar.
Esto a menudo implicará decidir qué datos deben transferirse desde el

herramienta antigua a la nueva, y esto puede requerir un reformateo significativo para lograr
los resultados requeridos. Idealmente, esta transferencia debería realizarse electrónicamente, pero en
En algunos casos, una pequeña cantidad de reingreso de datos en vivo puede ser inevitable y debería
ser incluido en el plan s.
Precaución: las herramientas más antiguas generalmente dependían de una mayor entrada manual y mantenimiento de
datos, por lo que si se está utilizando la migración de datos electrónicos, se debe realizar una auditoría
para verificar la calidad de los datos .
Cuando la transferencia de datos sea complicada o requiera mucho tiempo, una alternativa
podría ser permitir un período de ejecución en paralelo, con la herramienta anterior disponible
durante un período inicial junto con el nuevo, de modo que los datos históricos puedan ser
referenciado si es necesario. En tales casos, será prudente hacer que la herramienta antigua 'lea-
only 'para que no se puedan cometer errores al registrar nuevos datos en la herramienta anterior.
Los detalles completos sobre el proceso de entrega y despliegue de gestión pueden ser
que se encuentra en la publicación de Transición del servicio
Página 303
9 Desafíos, factores críticos de éxito y riesgos
9.1 Desafíos
Hay una serie de desafíos que se enfrentan dentro de la operación del servicio que deben ser
superar. Estos incluyen los establecidos en esta sección.
9.1.1 Falta de compromiso con el personal de desarrollo y proyectos
Tradicionalmente, ha habido una separación entre el personal de Operaciones de Servicio y

el personal involucrado en el desarrollo de nuevas aplicaciones o en la ejecución de proyectos que
finalmente entregará nuevas funcionalidades en el entorno operativo .
Esta separación fue originalmente deliberada e impulsada por el deseo de prevenir

colusión y evitar posibles riesgos de seguridad (en algunas organizaciones sigue siendo un
requisito legislativo ). Sin embargo, en lugar de utilizar esta separación de deberes para
crear contribuciones positivas, en muchas organizaciones es una fuente de rivalidad y
maniobras políticas.
Con demasiada frecuencia, ITSM se ve como algo que se ha iniciado en el

áreas y no tiene nada que ver con desarrollos o proyectos.
Esta vista es muy perjudicial ya que es el momento adecuado para pensar en Service
Los problemas operativos se encuentran al comienzo de nuevos desarrollos o proyectos, cuando
Aún es tiempo de incluir estos factores en las etapas de planificación .
Las publicaciones Service Design y Service Transition describen los pasos

necesario para garantizar que los problemas de operaciones de TI se consideren desde el principio
nuevos desarrollos y proyectos.
Anécdotas
Una organización utiliza una ' Política de transición de operación ' para garantizar que los servicios
que se están desplegando han tenido el nivel apropiado de aportes de las operaciones
equipos. Esta es básicamente una política que muestra claramente bajo qué circunstancias un
la aplicación está "lista" para la transición a Operaciones. Esto ayudó con
comunicación con los equipos de desarrollo y proyecto y también proporcionó un conjunto claro
de las pautas sobre cómo trabajar con los equipos operativos.
Otra organización utiliza los casos de uso de operaciones para que los equipos de desarrollo
incluir los requisitos que debe cumplir la aplicación que se ejecutará en
producción bajo el control del personal de Operaciones.
Página 304
9.1.2 Justificación de la financiación
A menudo es difícil justificar los gastos en el área de Operación del Servicio, ya que
El dinero gastado en esta esfera a menudo se considera como ' costo de infraestructura s', con
nada nuevo que mostrar para la inversión.
La publicación de Estrategia de servicio analiza cómo garantizar un retorno de

Inversión y eliminar la percepción de inversión como puramente Infraestructura
' sobrecarga '. Se ofrece una buena orientación sobre cómo justificar la inversión.
En realidad, muchas inversiones en ITSM, particularmente en las áreas de Operación de Servicios ,

puede ahorrar dinero y mostrar un retorno de la inversión positivo, además de
mejora de la calidad del servicio . Algunos ejemplos de áreas potenciales de ahorro
incluir:
• Costes de licencia de software reducidos gracias a una mejor gestión de

licencias y copias desplegadas
• Costos de soporte reducidos debido a menos incidentes y problemas y reducción
tiempos de resolución
• Plantilla reducida a través de la racionalización fuerza de trabajo, apoyando a seguir s
y estructuras de rendición de cuentas
• Menos 'pérdida de negocios' debido a la mala calidad del servicio de TI
• Mejor utilización del equipo de infraestructura existente y aplazamiento de más
gastos debido a una mejor gestión de la capacidad
• Procesos mejor alineados, lo que conduce a una menor duplicación de actividades y
mejor uso de los recursos existentes s.
9.1.3 Desafíos para los gerentes de operación del servicio
La siguiente es una lista de algunos de los desafíos que los gerentes en servicio
La operación debe esperar enfrentar. No existe una solución fácil para estos desafíos,
principalmente porque son subproductos de la cultura organizacional y la
decisiones tomadas durante el proceso de decidir la estructura organizacional. los
El propósito de incluir la lista es asegurar que los gerentes de operaciones del servicio
consciente de ellos y puede crear un plan para lidiar con ellos.
Las diferencias entre las actividades de diseño y las actividades operativas continuarán
para presentar desafíos. Esto se debe a varias razones, incluidas las siguientes.
• El diseño del servicio puede tender a centrarse en un servicio individual a la vez,

mientras que la operación del servicio tiende a centrarse en brindar y apoyar a todos
servicios al mismo tiempo. Los gerentes de operaciones deben trabajar en estrecha colaboración con
Diseño de servicio y transición de servicio para proporcionar la operación
perspectiva para asegurar que el diseño y los resultados de la transición apoyen la
necesidades operativas generales .
Página 305
• El diseño del servicio a menudo se llevará a cabo en proyectos , mientras que el servicio
La operación se centra en procesos de gestión continuos y repetibles y
ocupaciones. El resultado de esto es que el personal operativo a menudo no está disponible
para participar en las actividades del proyecto de Diseño de Servicios, que a su vez resulta en TI
servicios que son difíciles de operar o que no incluyen
Elementos de diseño de manejabilidad. Además, una vez que el personal del proyecto
terminaron el diseño de un servicio de TI que podrían pasar al siguiente
proyecto y no estar disponible para soportar dificultades en el funcionamiento
medio ambiente . Superar este desafío requiere que la Operación del Servicio
plan para su personal a participar activamente en los proyectos de diseño, a los recursos del
actividades de transición y participar en los servicios de soporte vital temprano
introducido en el entorno operativo.
• Las dos etapas del ciclo de vida tienen métricas diferentes , lo que fomenta
Diseño de servicio para completar el proyecto a tiempo, según las especificaciones y en
presupuesto . En muchos casos, es difícil pronosticar cómo se verá el servicio.
como y cuánto costará después de que se haya implementado y operado para
a veces. Cuando no se ejecuta como se esperaba, Gestión de operaciones de TI
se hace responsable. Si bien este desafío siempre será una realidad en Service
Gestión , esto se puede abordar mediante la participación activa en el Servicio.
Etapa de transición del ciclo de vida. El objetivo de la Transición del servicio es
garantizar que los servicios diseñados funcionarán como se espera y que
Operations Manager puede proporcionar el conocimiento necesario para el servicio
Transición para evaluar y solucionar problemas antes de que se conviertan en problemas en
el entorno operativo .
• Transición del servicio que no se utiliza de manera eficaz para gestionar la transición.
entre las fases de Diseño y Operación. Por ejemplo, algunos
Las organizaciones solo pueden utilizar la Gestión de cambios para programar la
implementación de cambios que ya se han realizado, en lugar de probar
para ver si el cambio hará con éxito la transición entre
Diseño y Operación. Es imperativo que las prácticas de Servicio
Se siguen las políticas de transición y organización para prevenir problemas
Se han implementado prácticas de cambio gestionado. Operación, Cambio y
Los gerentes de transición deben tener la autoridad para denegar cualquier cambio en el
entorno operativo, sin excepción, que no se hayan probado a fondo.
Estos desafíos solo se pueden abordar si el personal de Operaciones de servicio está involucrado en
Diseño y transición del servicio, y esto requerirá que se les asigne una tarea formal
y medido para hacer esto. Los roles identificados en los procesos de diseño del servicio deben
incluirse en el mismo Técnicos y de Gestión de Aplicaciones personal descripción de las funciones s
y su tiempo asignado proyecto por proyecto.
Otro conjunto de desafíos se relaciona con la medición. Cada estructura alternativa

introducir diferentes combinaciones de elementos que sean fáciles o difíciles de medir. Para
ejemplo, medir el rendimiento de un dispositivo o equipo podría ser relativamente
fácil, pero determinando si ese rendimiento es bueno o malo para el equipo de TI en general
el servicio es otro asunto. Un buen proceso de gestión del nivel de servicio
Página 306
ayudará a resolver esto, pero esto significa que los equipos de operaciones de servicio deben ser un
parte integral de ese proceso (consulte la publicación Mejora continua del servicio ).
Un tercer conjunto de desafíos se relaciona con el uso de equipos virtuales. Tradicional,

Las estructuras de gestión jerárquica se están volviendo inadecuadas debido a la
complejidad y diversidad de la mayoría de las organizaciones. Un paradigma de gestión (Matrix
Gerencia) ha surgido donde los empleados informan a diferentes fuentes para
diferentes tareas. Esto ha resultado en una compleja red de rendición de cuentas y una
mayor riesgo de que las actividades se pierdan. Por otro lado, también
permite a la organización hacer que las habilidades y los conocimientos estén disponibles donde se encuentran
más necesarios para apoyar el negocio. Gestión del conocimiento y mapeo
de las estructuras de autoridad será cada vez más importante a medida que las organizaciones
expandirse y diversificarse. Esto se analiza en la publicación ITIL Service Strategy .
Uno de los desafíos más importantes que enfrentan los gerentes de operaciones de servicio es
el equilibrio de muchos internos y externos de relación s. La mayoría de las organizaciones de TI
hoy en día son complejos y, a medida que los servicios se vuelven más básicos, hay una
mayor uso de las redes de valor , las asociaciones y los modelos de servicios compartidos .
Si bien es una ventaja significativa para las necesidades comerciales en evolución dinámica,
aumenta la complejidad de la gestión de los servicios de forma cohesiva, eficiente y
proporcionando la costura invisible entre el cliente y la intrincada red de cómo
los servicios se entregan realmente. Un Gerente de Operaciones de Servicio debe invertir en
Conocimientos y habilidades de gestión de relaciones para ayudar a lidiar con la complejidad de
este desafío.
Página 307
9.2 Factores críticos de éxito
9.2.1 Soporte de gestión
Se necesita el apoyo de la alta y media dirección para todas las actividades de ITSM y
procesos, particularmente en la Operación del Servicio.
El apoyo de la alta dirección es fundamental para obtener y mantener

financiación y dotación de recursos. En lugar de ver la Operación del Servicio como un 'agujero negro'
para la inversión, la Alta Dirección debería cuantificar y defender los beneficios de
Buen funcionamiento del servicio. También deben estar plenamente informados de los nefastos resultados.
que puede ocurrir debido a un mal funcionamiento del servicio.
La alta dirección debe proporcionar un apoyo visible durante el lanzamiento de nuevos

Iniciativas de operación del servicio (como a través de apariciones en seminarios,
firmantes de memorandos y anuncios, etc.) y su apoyo continuo debe
estar igualmente bien demostrado. Se puede dar un mensaje completamente incorrecto si un
El gerente senior no se presenta a una reunión o lanzamiento de un proyecto importante.
seminario. Peor aún son los altos directivos que apoyan la iniciativa verbalmente, pero
abusar de su autoridad para alentar la elusión de la Operación del Servicio
práctica .
Los gerentes senior también deben empoderar a los gerentes intermedios que serán directamente
responsable de la operación del servicio. Apoyar la iniciativa públicamente, pero luego
los requisitos presupuestarios primordiales o los cambios necesarios, dañarán tanto el
implementación e iniciativa de Operación del Servicio en curso.
Los mandos intermedios también deben proporcionar el apoyo necesario, y en particular este
debe ser demostrado por sus acciones. Si se considera que un gerente intermedio
eludir o invalidar un procedimiento acordado (por ejemplo, implementar un cambio
que no ha pasado por el proceso de gestión del cambio ), esto le da la
Mensaje claro de que otros pueden hacer lo mismo y que el procedimiento no tiene valor.
y puede ser ignorado por todos. Los mandos intermedios deben hacer todo lo posible para hacer
su apoyo conocido, no solo por sus palabras sino también por sus acciones y
adherencia a los procesos y procedimientos acordados por la organización .
Los mandos intermedios también deben brindar su apoyo total a la contratación de personal para
proceso, en lugar de aceptar la necesidad de una Operación del Servicio formalizada y luego
simplemente aumentando la carga de trabajo del personal existente para hacerlo.
9.2.2 Apoyo empresarial
Es importante que las Unidades de Negocio también apoyen la Operación del Servicio. Este nivel
de apoyo se puede lograr mucho mejor si el personal de Operación del Servicio involucra al
negocios en todas sus actividades y están abiertos en sus informes de ambos éxitos
y fracasos - y sus esfuerzos por mejorar.
Página 308
Es igualmente importante que las Unidades de Negocio comprendan, acepten y realicen

el papel que desempeñan en la operación del servicio. ¡Un buen servicio requiere buenos clientes !
Adherirse a las políticas, procesos y procedimientos, como el uso del Servicio.
Escritorio para registrar todas las solicitudes, es una responsabilidad directa del cliente para apoyar
y promover dentro del negocio.
Comunicaciones periódicas con la empresa para comprender sus inquietudes y

aspiraciones y dar retroalimentación sobre los esfuerzos para satisfacer sus necesidades son esenciales en
construyendo las relaciones correctas y asegurando un apoyo continuo.
Además, la empresa debe acordar los costos de implementación de la operación del servicio.
y comprender el rendimiento de la inversión, a menos que ya haya sido
acordado como parte del proceso de Diseño.
9.2.3 Campeones
Proyectos de ITSM y la práctica continua resultante (realizada por Service

Personal de operaciones) suelen tener más éxito si uno o más 'campeones' son
próximos que pueden guiar a otros a través de su entusiasmo y compromiso por
ITSM.
En algunos casos, estos campeones pueden ser altos directivos que dirigen desde
la parte superior. Pero los campeones también pueden tener éxito si provienen de otros niveles de
la organización. Uno o dos miembros del personal subalterno todavía pueden tener un beneficio significativo
influencia en una conclusión exitosa.
Los campeones a menudo son creados o fuertemente influenciados a través del servicio formal .
Capacitación gerencial , particularmente en niveles más avanzados donde el potencial
beneficios para una organización y para las personas que hacen una carrera en
Gestión de servicios, se puede explorar completamente.
Cabe señalar que los campeones surgen con el tiempo. No se pueden crear ni
fijado. A menudo, son los usuarios o los clientes quienes brindan la mayor ayuda para crear
buenos procesos de gestión de servicios, ya que son muy conscientes de las necesidades
mejoras desde una perspectiva empresarial . Es importante reconocer que estos
suelen ser personal altamente motivado que a menudo asume voluntariamente los mejores
carga de trabajo s. Para que su contribución sea más eficaz, se les debe dar tiempo para trabajar como
el campeón.
9.2.4 Dotación de personal y retención
Tener el número adecuado de personal con las habilidades adecuadas es fundamental para la
éxito de la operación del servicio. Algunos desafíos que deben superarse
Página 309
• Los proyectos para nuevos servicios suelen ser bastante buenos en cuanto a especificar los requisitos
nuevas habilidades, pero a menudo subestiman la cantidad de personal requerido y cómo
para retener las nuevas habilidades. Consulte el párrafo 9.2.1 para obtener algunas ideas sobre cómo
Facilitar una mejor comunicación sobre los requisitos .
• Escasez de recursos que tienen un buen conocimiento del servicio.
Administración. Es necesario contar con buenos técnicos, pero es necesario
ser un número de personas clave que puedan moverse entre la tecnología
problemas y problemas de servicio.
• Dado que estos recursos son bastante escasos, es bastante común capacitarlos,
solo para que renuncien y se unan a otra empresa por un mejor salario.
Las trayectorias profesionales claras y los buenos incentivos deben formar parte de todos los servicios.
Iniciativa de gestión.
• Intentar asignar demasiado, demasiado pronto, al personal existente. Logrando
La operación eficiente del servicio llevará tiempo, pero si se aborda correctamente
ser logrado. Desafortunadamente, algunos gerentes intentan acelerar los ahorros
Asignar el trabajo intermedio de implementación de los nuevos procesos y herramientas a
personal existente, muy ocupado. Invariablemente, el proyecto falla o el servicio
sufre y, a veces, el personal valioso se marchará. Servicio exitoso
Los proyectos de gestión a menudo requieren una inversión a corto plazo en
personal temporal o contratistas, y esto no debe subestimarse.
9.2.5 Formación en gestión de servicios
La formación y la concienciación adecuadas pueden tener beneficios generales mucho más amplios. También
como la creación de campeones de unos pocos, se puede utilizar para ganar los 'corazones y mentes' de
muchos. El personal de operaciones de servicio debe ser consciente de las consecuencias de su
acciones, tanto buenas como malas, en la organización , y a todas se les debe inculcar un
' Cultura de gestión de servicios '.
Es posible tener las mejores prácticas y herramientas de operación de servicio en el mundo

- pero la Gestión del Servicio no tendrá éxito a menos que las personas también
en sintonía con los objetivos generales de Gestión del Servicio . Participación y apoyo de todos
por lo tanto, el personal es muy importante, y el papel de la formación y la concienciación, y
Incluso las calificaciones formales que benefician al individuo, no deben ser
subestimado.
La formación necesaria para una gestión de servicios satisfactoria incluye:
• Capacitar al personal de TI sobre los procesos implementados. Esta voluntad

incluir capacitación genérica para que comprendan los conceptos en su totalidad, también
como formación especialmente dirigida a los procesos propios de la organización
• Capacitación en habilidades 'blandas' o 'personales', especialmente para el personal del cliente :
posiciones enfrentadas
• Capacitación sobre la comprensión del negocio y la importancia de
lograr una cultura de servicio
Página 310
• Donde se han implementado herramientas, capacitación sobre cómo usar y administrar

esas herramientas
• Además, los clientes y usuarios necesitan una formación adecuada sobre cómo trabajar con
TI: acceder a servicios, solicitar cambios, enviar solicitudes, utilizar herramientas, etc.
9.2.6 Herramientas adecuadas
Muchos procesos y actividades de Operación del servicio no se pueden realizar de manera efectiva
sin las herramientas de apoyo adecuadas (como se describe en el Capítulo 7). Gerencia senior
debe garantizar que la financiación de tales herramientas se incluya en los presupuestos en curso y
apoyar su adquisición, implementación y mantenimiento continuo.
9.2.7 Validez de la prueba
La calidad de los servicios de TI que se pueden proporcionar en la operación del servicio depende
sobre la calidad de los sistemas y componentes entregados en la operación
medio ambiente .
El nivel de calidad se mejorará significativamente si se realizan pruebas adecuadas y completas

de nuevos componentes y lanzamientos se lleva a cabo a su debido tiempo. Documentación
también debe probarse su integridad y calidad.
Esto requiere que exista un entorno de prueba completo y realista para

todos los sistemas / componentes, lo que refleja el entorno operativo en términos de
volumen así como características. Debería haber probadores independientes dondequiera que
posible. La financiación para estos entornos de prueba es esencial si se trata de entornos de alta calidad.
se van a lograr los servicios.
Además, se necesita tiempo y esfuerzo suficientes para garantizar que las pruebas sean
debidamente planificado y diseñado, y se incluye el tiempo adecuado para las pruebas, y
volver a probar si algunas piezas fallan. La mejor manera de asegurarse de esto es siguiendo las
orientación en la publicación Transición del servicio .
9.2.8 Medición e informes
Se necesita una definición clara de cómo se medirán e informarán las cosas (como
delineado en el Apéndice B) para que todo el personal tenga objetivos claros a los que apuntar y TI y
Los gerentes comerciales pueden revisar el progreso e identificar de manera rápida y sencilla
cualquier área de atención.
Página 311
9.3 Riesgos
No cumplir con los desafíos ya descritos en la sección 9.1 o no abordar los
Los factores críticos de éxito descritos en la sección 9.2 son riesgos obvios , pero otros son
descrito como se establece a continuación.
9.3.1 Pérdida de servicio
El riesgo final para el negocio de las debilidades en la operación del servicio es la pérdida
de servicios de TI críticos con el consiguiente impacto adverso en sus empleados,
clientes y finanzas. En casos extremos, puede haber una posible pérdida de la vida y
extremidad donde los servicios de TI afectados se utilizan para fines críticos de salud o seguridad
- como despliegue de vehículos de emergencia o escaneo de salud, etc.
9.3.2 Riesgos para la operación exitosa del servicio
Los riesgos para lograr una Operación del Servicio exitosa son numerosos, y en muchos
Los casos son opuestos a los factores críticos de éxito descritos anteriormente, pero
también incluir:
• Financiación y recursos inadecuados: la financiación debe estar justificada, asignada

y mantenido en reserva para su propósito original.
• Pérdida de impulso: donde el personal ve la gestión de servicios como
el mes 'en lugar de cambiar permanentemente la forma en que trabajan para el
futuro, cualquier ímpetu se pierde como resultado: debe quedar claro desde el
Desde el principio se requiere una nueva forma de trabajar. Además, los mecanismos deben ser
implementado para asegurar que la iniciativa sobreviva a los cambios organizacionales.
• Pérdida de personal clave: a veces, la pérdida de uno o dos miembros del personal clave
puede tener un impacto severo : para tratar de minimizar este efecto, las organizaciones
debe tratar de capacitar al personal y reducir la dependencia de
individuos. Esto es especialmente cierto en organizaciones menos maduras donde
el conocimiento aún no se ha formalizado en procesos, documentos y
instrumentos. Estas organizaciones tienden a depender de los esfuerzos 'heroicos' de un
pocas personas informadas, y se sienten devastadas cuando se van.
• Resistencia al cambio : a veces las personas se oponen a las cosas nuevas y son
reacios a llevarlos a bordo. Educación, formación, comunicación y
destacar los beneficios ayudará.
• Falta de apoyo de la gerencia: esto ocurre a menudo entre
Gerentes que pueden no ver la visión general o no obtener la práctica
beneficios que puede obtener el personal más subalterno. Consulte el párrafo 9.2.1 para obtener más
información sobre esto, pero los gerentes deben respaldar la gestión de servicios
y participar en las fases y procesos apropiados del Servicio.
Diseño , Transición y Operación para brindar soporte tangible.
• Si el diseño inicial es defectuoso , una implementación exitosa nunca dará
los resultados requeridos y, en última instancia, será necesario un rediseño.
Página 312
• En algunas organizaciones, la Gestión de servicios se puede ver con

sospecha tanto de TI como de la empresa. El personal de TI lo ve como un intento de
controlarlos
más , mientras
financiación que la nada.
sin mejorar empresaLoslobeneficios
percibe como un intento de TI de ganar
del servicio
La gestión debe estar claramente articulada para todas las partes interesadas .
• Diferentes expectativas de los clientes . Si bien se alienta al personal operativo
para ejecutar en contra de los estándares , las expectativas del cliente y del usuario a veces
diferir de. En otros casos, un cliente puede haber pagado más por un producto superior.
servicio, pero cuando un usuario de un área diferente ve el servicio superior,
se sienten engañados. Este problema debe resolverse mediante un SLM claro
y comunicación cuidadosa durante el Diseño del Servicio. Quejas de este
la naturaleza debe asumirse mediante la mejora continua del servicio
procesos y no debe involucrar simplemente la Operación del Servicio automáticamente
aumentando el servicio a pedido.
Página 313
Epílogo
Una simple verdad debe guiarnos a todos en el funcionamiento del servicio. Negocios y tecnología
seguirá evolucionando hacia el futuro. Lo que fue innovador el año pasado es común
este año. Las mejores prácticas de hoy serán comunes mañana. Logrando
la excelencia en la operación del servicio requiere flexibilidad, equilibrio y buen juicio
en el uso de las prácticas de ITIL . La guía de esta publicación es clave para lograr
conocimiento, sabiduría, visión de futuro y la capacidad de equilibrar los negocios de hoy
necesidades y demanda de mañana.
Las prácticas comunes, buenas, mejores y futuras contribuyen al objetivo del servicio.
excelencia. ITIL los proporciona como base para guiarlo hacia este objetivo.
La estabilidad en un mundo cambiante es la realidad para los proveedores de servicios . Los que sobresalen,
y seguir siendo el mejor de la raza, entienda esto y sepa que la forma de lograr
es adaptarse, aprender, innovar y liderar.
La publicación Service Operation es una parte integral de un ciclo de vida general de ITSM
práctica, utilizada en conjunto, la práctica de ITIL para la gestión de servicios forma una
poderosa herramienta en manos de cualquier Proveedor de Servicios.
Página 314
Apéndice A: Orientación complementaria de la industria

Cuando ITIL se introdujo por primera vez en la década de 1980, había poco más disponible en
términos de la guía no propietaria sobre las mejores prácticas de ITSM .
Hoy en día existen otros marcos o metodologías que tienen aportes válidos
hacer en esta área, que se complementen y tengan sinergia con ITIL y que puedan
ser de ayuda para la Operación del Servicio.
Página 315
A1 COBIT
El marco COBIT , elaborado por Auditoría y Control de Sistemas de Información

Asociación (ISACA) y administrado por el Instituto de Gobernanza de TI, proporciona una
marco de orientación muy útil para el personal de seguridad y auditoría de TI .
La versión actual de COBIT, edición 4, incluye 34 controles de alto nivel

Objetivos , 13 de los cuales se agrupan bajo el 'Dominio de entrega y soporte',
que se relaciona bastante de cerca con la fase de Operación del Servicio de ITIL . Estos son
intitulado:
• DS1 Definir y administrar los niveles de servicio .

• DS2 Gestionar servicios de terceros.
• DS3 Gestionar el rendimiento y la capacidad .
• DS4 Garantiza un servicio continuo.
• DS5 Garantiza la seguridad de los sistemas.
• DS6 Identificar y asignar costos .
• DS7 Educar y capacitar a los usuarios .
• DS8 Gestionar la mesa de servicio y los incidentes.
• DS9 Gestionar la configuración .
• DS10 Gestionar problemas .
• DS11 Gestionar datos.
• DS12 Gestionar el entorno físico .
• DS13 Gestionar operaciones.
Algunos aspectos de la Operación del Servicio también se tocan en algunos de los de control
objetivos dentro de otros dominios, pero la gran mayoría de lo que COBIT tiene que decir
sobre la fase de ' operación en vivo ' de TI está contenida en el control antes mencionado
objetivos.
COBIT está dirigido principalmente a auditores, por lo que tiene un énfasis en lo que debería ser
auditado y cómo, en lugar de incluir una guía detallada para aquellos que son
operar los procesos que serán auditados, pero tiene mucho material válido
qué organizaciones pueden resultar útiles.
Cabe señalar que COBIT e ITIL no son 'competitivos' ni son mutuamente

exclusivo - por el contrario, se pueden utilizar en conjunto como parte de un
el marco general de gestión y gobernanza de la organización . ITIL proporciona una
organización con orientación sobre las mejores prácticas sobre cómo gestionar y mejorar su
proceso para brindar servicios de TI rentables y de alta calidad . COBIT proporciona
orientación sobre cómo estos procesos deben ser auditados y evaluados para determinar
si están operando según lo previsto y dando un beneficio óptimo para el
organización.
Página 316
Para obtener una imagen general más completa, las organizaciones pueden querer leer y convertirse en
familiarizados con lo que COBIT tiene que decir junto con su lectura y comprensión de
ITIL. Se pueden encontrar más detalles del estándar a través de ISACA en www.isaca.org
Página 317
A2 ISO / IEC 20000
En diciembre de 2005, la Organización Internacional de Normalización lanzó una

estándar internacional , ISO / ISE 20000, contra el cual las organizaciones pueden buscar
acreditación independiente para ITSM. Esto fue precedido por un estándar británico,
BS15000, que se introdujo originalmente en 2000 y bajo la cual algunos
organizaciones se acreditaron , pero fueron reemplazadas por ISO / ISE 20000 y
las acreditaciones fueron prorrogadas.
Mientras que ISO / IEC 20000 se asignó inicialmente al Servicio de soporte y servicio anterior
Publicación de entrega de ITIL, el estándar continúa mapeando bien a ITIL hoy y
también cubre seguridad de TI, gestión de relaciones comerciales y proveedores
Gestión .
Para organizaciones que buscan una acreditación formal según ISO / IEC 20000, con el fin de obtener
reconocimiento externo e internacional por el éxito de sus procesos ITSM,
será una participación significativa por parte del personal de Operaciones de Servicio en la preparación y
someterse a la vigilancia formal necesaria para lograr el estándar.
Se pueden encontrar más detalles del estándar a través del itSMF en www.itsmf.com o
la ISO en www.iso.org
Página 318
A3 CMMI
La Integración Capability Maturity Model® (CMMI) es una mejora del proceso

enfoque desarrollado por el Instituto de Ingeniería de Software (SEI) de Carnegie
Universidad de Mellon. CMMI proporciona a las organizaciones los elementos esenciales de
procesos efectivos. Se puede utilizar para guiar la mejora de procesos en un
proyecto , una división o toda una organización. CMMI ayuda a integrarse tradicionalmente
separar las funciones organizativas , establecer objetivos y prioridades de mejora de procesos,
proporcionar orientación para los procesos de calidad y proporcionar un punto de referencia para
evaluar los procesos actuales. Para más información, ver
http://www.sei.cmu.edu/cmmi/
Varias organizaciones de consultoría de TI han incorporado el modelo de madurez en sus

Los servicios de evaluación de ITSM como una forma de ayudar a las organizaciones a prepararse y
juzgar las mejoras del proceso, incluidas las del área de Operaciones de servicio .
Las organizaciones pueden desear utilizar alguna forma del modelo para ayudar a impulsar su camino.
hacia la acreditación independiente ISO / ISE 20000
Cuadro de mando integral A4
Un nuevo enfoque de la gestión estratégica fue desarrollado a principios de la década de 1990 por
Drs. Robert Kaplan (Harvard Business School) y David Norton. Ellos nombraron
este sistema el ' Cuadro de Mando Integral '. Reconociendo algunas de las debilidades y
vaguedad de los enfoques de gestión anteriores, el cuadro de mando integral
El enfoque proporciona una prescripción clara sobre lo que las empresas deben medir en
para "equilibrar" las perspectivas financieras. El Cuadro de Mando Integral sugiere
que la organización es vista desde cuatro perspectivas, y es valioso para
desarrollar métricas , recopilar datos y analizarlos en relación con cada uno de estos
perspectivas:
• La perspectiva de aprendizaje y crecimiento

• La perspectiva del proceso empresarial
• La perspectiva del cliente
• Las perspectivas financieras.
Algunas organizaciones pueden optar por utilizar el método de Cuadro de Mando Integral como
forma de evaluar y reportar su desempeño de calidad de TI en general y su
Rendimiento de la operación del servicio en particular.
Más detalles están disponibles a través de la Comunidad de usuarios del Cuadro de Mando Integral en
www.scorecardsupport.com
Página 319
A5 Gestión de la calidad
Existen distintas ventajas de vincular los procesos ITSM de una organización, y

Procesos de Operación del Servicio, en particular, a su sistema de gestión de la calidad . Si
una organización tiene un sistema formal de gestión de la calidad como ISO9000, Six
Sigma, TQM, etc., esto se puede utilizar para evaluar el progreso con regularidad e impulsar
Remitir iniciativas de mejora del servicio acordadas mediante revisiones periódicas y
informes.
Muchas organizaciones han utilizado una auditoría anual periódica o una evaluación externa como
una forma de determinar las mejoras necesarias, y luego su calidad
Sistema de gestión para impulsar los programas específicos de trabajo.
A6 ITIL y el marco OSI
Aproximadamente en el momento en que se estaba escribiendo ITIL v1, los Estándares Internacionales
La organización lanzó una iniciativa que resultó en los sistemas abiertos
Marco de interconexión (OSI). Dado que esta iniciativa cubrió muchos de los mismos
áreas como hizo el equipo de ITIL, no es sorprendente que cubrieran gran parte de las
mismo terreno.
Sin embargo, tampoco es sorprendente que clasificaran sus procesos de manera diferente,
usó terminología diferente, o usó la misma terminología de diferentes maneras. A
confunden aún más las cosas, es común que los diferentes grupos de una organización
utilizar terminología tanto de ITIL como del marco OSI.
Aunque no está dentro del alcance de esta publicación explorar el marco OSI,
ha hecho contribuciones significativas a la definición y ejecución de ITSM
programas y proyectos en todo el mundo. También ha causado una gran cantidad de
debate entre equipos que no se dan cuenta de los orígenes de la terminología que
están usando.
Por ejemplo, algunas organizaciones tienen dos departamentos de Gestión de cambios :

uno siguiendo el proceso de gestión de cambios de ITIL y el otro utilizando el
OSI de instalación, movimientos, adiciones y cambios (IMAC) modelo . Cada
departamento está convencido de que es completamente diferente al otro, y que
realizan diferentes roles . Un examen más detenido revelará que hay varios
áreas comunes.
En la operación de servicio , la gestión de los errores conocidos se puede asignar a la falla.

Administración. También hay una sección relacionada con la capacidad operativa
Gestión , que puede relacionarse con el concepto de Desempeño de OSI
Gestión .
Página 320
Apéndice B: Comunicación en la operación del servicio
B1 Comunicación operativa de rutina
La mayor parte de la comunicación en la operación del servicio tiene que ver con garantizar que todos los equipos
y los departamentos pueden ejecutar las actividades estándar involucradas en la entrega
Servicios de TI y gestión de la infraestructura de TI.
Página 321
Se debe considerar seriamente durante el Diseño del Servicio para definir el

contenido, tipo y formato de comunicación que se requiere para operar los servicios de TI.
Objetivo • Coordinar las actividades regulares de Operación del Servicio en todos los niveles.
• Asegurar que todo el personal esté al tanto de la actividad programada en todo momento y
que conocen los cambios o iniciativas que puedan afectar a la normalidad
funcionamiento del entorno de TI
Frecuencia Este tipo de comunicación es regular y se comunica en forma diaria, semanal y

ciclos mensuales
Papel • Todos los gerentes y el personal involucrado en la Operación del Servicio

Jugadores • Todos los gerentes de proceso para los procesos ejecutados por el personal de Operación del Servicio -
especialmente Gestión de Cambios, Incidentes y Problemas
• Cliente s y el usuario s
• Personal del proveedor involucrado en la operación del servicio
Contenido • Resuma los eventos desde la comunicación anterior para asegurarse de que
todos están al tanto de cualquier seguimiento que deba realizarse. También para asegurar
que todos los lotes se hayan completado y los equipos o departamentos estén listos
para actividad operativa estándar
• Un informe sobre la salud de los principales sistemas
• Informar al personal de la Gerencia de Operaciones de cualquier noticia o evento que pueda
Efectuar operaciones ese período
• Discuta cualquier problema o incidente pendiente y asegúrese de que una acción
el plan está en su lugar para cada
• Discuta el cronograma de cambios que se espera que se realicen durante la
día, junto con una sesión informativa de posibles incidentes que pueden ocurrir como un
resultado y la acción apropiada a tomar. Esto no debe confundirse
con la reunión del CAB. Esta es una oportunidad para comprobar si los cambios
que fueron acordados y programados por el CAB, o mediante un Modelo de Cambio ,
todavía están en camino
• Cualquier mantenimiento planificado u otras interrupciones que se hayan programado para
el próximo período operativo
• Anuncio de los resultados de cualquier reunión post mortem o de crisis que
se llevaron a cabo desde la comunicación anterior
• Anuncio o recordatorio de capacitación que puede estar disponible durante el próximo
semana o mes para dar tiempo al personal y a sus supervisores para programar la
capacitación en el programa de operaciones
Contexto / • Registros de operaciones

fuentes • Informes de incidentes
• Informes de problemas
• Programas de mantenimiento
• Cambiar horario
Tabla B.1 Requisitos de comunicación en servicios de TI
Página 322
B2 Comunicación entre turnos
No todas las organizaciones trabajan en turnos , pero para aquellas que lo hacen, la Tabla B.2
resumir la comunicación que debe tener lugar entre turnos.
Objetivo Esta comunicación asegura que el traspaso entre saliente y entrante

turnos es suave y también hace que el nuevo turno sea consciente de cualquier dificultad potencial.
También se aseguran de que el nuevo turno esté al tanto de cualquier tarea que deba ser
terminado.
Frecuencia Al traspaso de cada turno
Papel • Líderes de turno de cada turno

Jugadores • Personal de cada turno que realiza tareas similares ·
Contenido • Un informe resumido de las operaciones realizadas durante el turno anterior.

• Un resumen de todas las excepciones y alertas que se resolvieron durante el turno.
• Detalles de las excepciones y alertas pendientes, con información sobre
todas las acciones tomadas hasta el punto actual y cualquier información sobre anticipada
Acciones futuras (por ejemplo, se espera que un proveedor esté en el sitio para brindar soporte
durante las próximas cuatro horas) ·
Contexto / La comunicación entre turnos generalmente se basará en las siguientes fuentes: ·

fuentes
• Registros de turnos
• Informe del líder de turno
• Comunicación interpersonal verbal o electrónica de 'chat' donde cambia
el personal se encuentra en diferentes instalaciones
Tabla B.2 Requisitos de comunicación entre turnos
Página 323
Informes de rendimiento B3
Los informes de desempeño en el contexto de la comunicación se refieren a tres

áreas, como se establece a continuación. Además, las Tablas B.3-B.5 ilustran respectivamente la
tres enfoques.
Rendimiento del servicio de TI
Esta categoría de informes de rendimiento se realiza generalmente como parte de SLM y se

cubierto en la publicación Mejoramiento continuo del servicio . Sin embargo, hay una
aspecto muy importante de los informes de servicio que se refiere a la operación del servicio ,
es decir, que son los equipos o departamentos de Operación del Servicio los que deben
registrar y comunicar la información que se incluye en estos informes.
Sin embargo, el personal de Operaciones de servicio no está en la mejor posición para decidir sobre el contenido,
formato y frecuencia de los informes de rendimiento del servicio. Los requisitos para este tipo
de comunicación deben definirse claramente durante el Diseño del servicio y refinarse
durante la mejora continua del servicio.
Finalidad Proporcionar información a los grupos responsables de los informes de servicios de TI.
a los clientes y usuarios , que pueden utilizar para demostrar el
logro de los objetivos del servicio y como aportación a la revisión del nivel de servicio
reuniones La información también se puede utilizar como base para cobrar por TI
servicio s
Frecuencia Según se define en los SLA y OLA. Esta información suele ser
comunicados regularmente sobre una base diaria, mensual y trimestral.
Papel • Equipos y departamentos de operaciones de servicio, generalmente operaciones de TI

Jugadores personal
• Personal de SLM
•
Los equiposade
y refinarlos diseño
través de propio (quecontinua
la mejora ayudan del
a definir las)normas de rendimiento s
servicio
• Equipos de mejora continua del servicio, especialmente aquellos encargados
con informes de servicio
Contenido Ejemplos del tipo de información sobre el rendimiento del servicio que debe
comunicados para permitir la presentación de informes sobre el rendimiento del servicio son:
• Realización de actividades específicas tal como se definen en los OLA

• Logro de las metas para la entrega de productos específicos
• Logros de disponibilidad del servicio o del sistema
• Capacidad para cumplir con los objetivos de mantenimiento del servicio dentro de los
tiempos y niveles de impacto
Página 324
Contexto / • Herramientas de seguimiento y generación de informes

fuentes • Registros de eventos
• Registros de turnos
Tabla B.3 Requisitos de informes de desempeño: servicio de TI
Página 325
Equipo de operación de servicio o desempeño del departamento
Esta es una comunicación 'interna' en el sentido de que tiene lugar entre los miembros de
un equipo o departamento y su gerente, o un gerente de proceso y el equipo
que ejecuta el proceso . Las personas ajenas a estos equipos o departamentos deben
No participar en este tipo de comunicación ya que está dirigido a la gestión de personas.
en lugar de medir la calidad de un servicio .
Sin embargo, es un error común que los departamentos de TI comuniquen este tipo de
información a los clientes como si fuera lo mismo que informar sobre la calidad del servicio.
Por ejemplo, un gerente puede informar que su departamento resuelve el 80% de todos
problema s. Sin embargo, en lo que respecta al usuario medio , esta información es
irrelevante. Están más preocupados por si su servicio de TI se desempeñó como
acordado. Además, la divulgación de información interna a clientes y usuarios podría
avergonzar a los equipos y departamentos de operaciones de servicio y podría
resultar en altos niveles de interferencia de la empresa para 'corregir' la percepción
problemas.
Objetivo Hay tres propósitos principales del equipo o departamento de operación de servicio
Comunicación de desempeño:
• De forma proactiva, para garantizar que el personal de Operaciones del servicio esté ejecutando
actividades necesarias para ofrecer servicios de TI s y para apoyar la TI
Infraestructura
• Para detectar problemas potenciales con los niveles de recursos , la capacidad y
elusión del procedimiento s
• Para asegurar que la acción correctiva se haya implementado correctamente y
adherido a
Frecuencia No hay una frecuencia establecida para este tipo de comunicación. A pesar de que algunos
Los informes de rendimiento se pueden producir diariamente, semanalmente o mensualmente, la mayoría de los gerentes
están involucrados en la comunicación continua con sus equipos o departamentos como el
la situación lo requiere.
En situaciones de funcionamiento normales, esta comunicación tenderá a ser menos

frecuentes que en situaciones donde hay un alto grado de cambio o donde el
la organización está experimentando un gran número y gravedad de incidentes
Papel • Gerentes de operaciones de servicio
Jugadores • Personal de operación de servicio
• Los problemas de rendimiento se pueden escalar al administrador de servicios o al CIO
Contenido • Comparación entre rendimiento requerido y real

• Tendencias de rendimiento a lo largo del tiempo
• Informes específicos de mala conducta o incumplimiento de una acción requerida
Contexto / • Informes de evaluación periódicos, por ejemplo Incidente registros, mantenimiento de registro es,
Página 326
fuentes métrica de proceso s

• Comunicación interpersonal y verbal durante situaciones laborales.
• Reuniones de equipo o departamento
• Coaching por parte de un líder o gerente de equipo
• La investigación posterior a un informe de servicio deficiente puede iniciar una serie de
comunicaciones en la operación del servicio
• Evaluaciones de desempeño individual, generalmente utilizando (KPI) documentados en
la descripción del trabajo del individuo
Tabla B.4 Requisitos de informes de desempeño: equipo o departamento de operación del servicio
Página 327
Rendimiento de la infraestructura o del proceso
Al igual que con el desempeño del equipo o departamento, esta es una comunicación 'interna' que
tiene lugar entre los miembros de un equipo o departamento que son responsables
para gestionar un componente o sistema de infraestructura , o los miembros de un
equipo de proceso. Las personas ajenas a estos equipos no deberían participar en este tipo
de la comunicación, ya que está dirigido a la gestión de personas en lugar de medir el
calidad de un servicio.
Finalidad Existen al menos tres finalidades de este tipo de comunicación: ·
• Para asegurar el funcionamiento normal de la infraestructura o un proceso

• Para detectar problemas potenciales con la infraestructura o el proceso en cuestión.
• Para garantizar que se hayan tomado medidas correctivas y que hayan sido efectivas.
Frecuencia La frecuencia de este tipo de comunicación variará dependiendo de la naturaleza de

el (los) sistema (s) que se administran o el proceso que se está ejecutando.
Algunos componentes de la infraestructura son más volátiles y requerirán frecuentes

comunicaciones e incluso reuniones para garantizar que funcione de manera predecible. Más
Los componentes estables simplemente requerirán una confirmación de que todo sigue funcionando.
como se esperaba.
Algunos procesos tienen el requisito de informes y comunicaciones frecuentes.

Por ejemplo, la gestión de incidentes puede requerir actualizaciones cada cinco minutos para un
incidente de alto impacto . Otros procesos no necesitan comunicarse con tanta frecuencia.
Por ejemplo, Capacity Planning necesita comunicar los cambios de forma mensual o
incluso de forma trimestral.
Papel • Personal que gestiona IC clave

Jugadores • Personal que ejecuta procesos
• Propietarios de procesos y gerentes de tecnología
• Posible escalada a más gerentes senior, el Gerente de Servicio
Contenido • Comparación entre rendimiento requerido y real

• Tendencias de rendimiento a lo largo del tiempo
• Informes específicos de objetivos incumplidos o niveles inesperados de desempeño.
Contexto / • Registros de eventos

fuentes • Registro de rendimiento del sistema s
• Informes de rendimiento de procesos
• Incidente y Registro de problema s
•• Informes de excepción e informes de auditoría
Revisión con el proveedor
• Los informes de servicio pueden indicar un problema con una o más tecnologías
áreas o procesos
Tabla B.5 Requisitos de informes de desempeño: infraestructura o proceso
Página 328
B4 Comunicación en proyectos
El personal de Operación del Servicio a menudo está involucrado en los proyectos . Esto puede ser para proporcionar
entrada a un nuevo diseño , o para ayudar a verificar la utilización o las tasas de rendimiento , o para
ayudar en la realización de pruebas de servicios nuevos o modificados. En otros casos los proyectos
puede afectar a los OLA existentes y se requerirá su retroalimentación. Debe ser
reconoció que esta participación se sumará al nivel de comunicación que estos
las personas recibirán y transmitirán. Esto requerirá tiempo adicional y
enfoque, que deben permitir los gerentes que asignan recursos a los proyectos
a tiempo parcial.
Propósito La comunicación del proyecto tiene múltiples propósitos, que incluyen:
• Para obtener el apoyo de las partes interesadas del proyecto , esta comunicación se centrará
sobre el alcance , costo y beneficios del proyecto y buscará demostrar
un retorno general de la inversión del proyecto
• Asegurar que todos los miembros del equipo del proyecto comprendan y estén alineados
a los objetivos del proyecto
• Asignar trabajo a personas o equipos
• Para programar actividades y asegurarse de que los recursos estén listos para comenzar su
etapa del proyecto
• Para verificar e informar el progreso del proyecto.
• Para detectar y escalar posibles excepciones o retrasos en el proyecto.
• Preparar a los clientes y al público del proyecto para el despliegue de la solución.
siendo construido
Frecuencia La frecuencia, el papel de los jugadores y el contenido de la comunicación dependerá de la

la naturaleza del proyecto y el tipo de metodología de gestión de proyectos que se utiliza
Tabla B.6 Comunicación dentro de los proyectos
La comunicación formal del proyecto tiende a seguir el ciclo de las reuniones del proyecto. Para
ejemplo:
• Se llevarán a cabo reuniones semanales o mensuales del proyecto con el Project Manager.
y los líderes de equipo individuales
• Se enviará una actualización de estado mensual al patrocinador ejecutivo del proyecto.
y posiblemente otras claves de interesados s
• Las excepciones y el resultado de los controles de garantía de calidad se informan en
Equipos de aseguramiento del proyecto, quienes a su vez comunicarán la necesidad de
acción correctiva según sea necesario.
Dentro de cada equipo, la comunicación estará más enfocada a completar sus tareas.
y generalmente será más frecuente que la comunicación de todo el proyecto.
Es probable que haya un alto nivel de comunicación menos formal dentro de cada equipo.
y también entre equipos para garantizar que las tareas se completen a tiempo y
Página 329
los recursos prometidos están disponibles cuando y donde se supone que deben estar.
También se requiere una amplia comunicación como parte del traspaso de un equipo
a otra a medida que el proyecto pasa de una etapa o fase a otra. Un
Una regla general importante es documentar cualquier comunicación que pueda potencialmente
afectar el resultado o el costo del proyecto.
Papel • Jefe de proyecto y personal administrativo y de coordinación del proyecto

Jugadores • Patrocinador de proyecto
• Partes interesadas clave del proyecto (por ejemplo, clientes , gerentes de TI, miembros de la junta,
usuario s, etc.)
• Equipos de proyecto y colaboradores individuales
• Vendedores de personal técnico y de ventas donde la compra de servicios o
las soluciones son parte del proyecto
Contenido • Recopilación de requisitos para la solución que está construyendo el proyecto.

• Programación de proyectos
• Información de 'marketing' del proyecto, incluido el retorno de la inversión o
Información de Business Case
• Actualizaciones de estado
• Recopilar información para completar una tarea
• Eventos que podrían afectar el alcance , el costo o la finalización oportuna del proyecto.
• Informes de progreso dentro de los equipos o entre equipos
• Información sobre los resultados de las pruebas.
• Notificaciones a equipos o individuos de que el proyecto se acerca a 'su'
etapa o actividad y que deben realizar los preparativos adecuados
• Informar sobre la finalización satisfactoria de las actividades.
• Revisión del éxito general del proyecto ·
Contexto / • Carta del proyecto

fuentes • Presupuesto del proyecto
• Declaración de requisitos
• Cronograma del proyecto
• Reuniones de proyectos
• Reuniones de equipo
• Informes de estado y progreso
• Informes de prueba
• Documentación de firma del cliente
• Revisión posterior a la implementación ·
Cuadro B.7 Comunicación sobre traspaso de proyectos
Página 330
B5 Comunicación relacionada con cambios
La gestión de cambios se trata en detalle en la transición del servicio ITIL.

publicación e incluye información sobre la comunicación de cambios. Sin embargo lo és
necesario subrayar la naturaleza de la comunicación operativa sobre los cambios.
Propósito Apoyar el proceso de Gestión del Cambio mediante: ·
• Evaluar el impacto potencial y los recursos necesarios para el cambio.

• Asegurarse de que cada equipo conozca la naturaleza y el cronograma de los cambios.
que les han sido asignados
• Construyendo, probando e implementando cambios en su entorno
• Asegurarse de que cada equipo informe sobre el progreso de cada cambio.
• Notificación a la gestión de cambios de que un cambio está listo para su implementación
• Retirar los cambios que no tuvieron éxito y comunicar el
resultados a la gestión del cambio
• Ayudar en la evaluación de cambios para asegurar que se hayan
implementado correctamente
Frecuencia La frecuencia de la comunicación relacionada con los cambios está determinada por la naturaleza de
el cambio y los tiempos establecidos en el Programa de cambios .
La mayoría de los equipos o departamentos revisarán los cambios diaria o semanalmente. Cada
día ellos discutirán y priorizarán todos los cambios nuevos que se les asignen e informarán
sobre el progreso de los cambios en los que están trabajando. Después de cada cambio, informarán
sobre el éxito de cada cambio y asegurarse de que cualquier acción correctiva requerida sea
iniciado.
Papel • Change Manager, administradores y coordinadores

Jugadores • Equipo-líderes, jefes de departamento, jefes de turno o del proyecto Los gerentes
• Personal de operaciones de servicio involucrado en la construcción, prueba y despliegue
cambios (por lo general, gestión técnica, de aplicaciones y de operaciones de TI
equipos o departamento)
• Gerentes de entornos de prueba y equipos
• Cambiar o Release equipos de implementación
Contenido • Solicitudes y autorización de cambios

• Informes sobre la viabilidad de un cambio.
• Informes sobre los recursos necesarios para crear , probar o implementar un cambio.
• Cambiar la programación de actividades
• Descripciones detalladas del cambio y las actividades requeridas de cada
equipo o departamento
• Informes de progreso y estado de la actividad de cambio
• Resultados de la prueba
• Informes de excepción , incluidos los detalles de la ejecución de los planes de retroceso
Contexto / • RFC
Página 331
fuentes • Comunicación de control de cambios (durante la operación diaria o semanal).

reuniones, o por e-mail, conferencia de llamada o el uso de la Gestión del Cambio
instrumentos)
• Reuniones de la Junta Asesora de Cambios
• Planes de lanzamiento
• Informes de disponibilidad de servicios proyectados ·
• Cambiar revisión s
Tabla B.8 Comunicación sobre cambios
Página 332
B6 Comunicación relacionada con excepciones
En este contexto, una excepción se refiere a cualquier suceso que esté fuera de lo normal o
actividad o rendimiento esperado . La forma más común de excepción es una
Incidente (que se trata en detalle en la sección 4.2 de esta publicación). Existen
otras excepciones que no necesariamente pasan por la Gestión de incidentes, como
como una excepción de proceso (que será manejada en el contexto de ese proceso o por
un proceso de aseguramiento de la calidad ); un equipo, departamento o individuo cuyo
el rendimiento no está a la altura del estándar (que se manejará a través de disciplinas de recursos humanos
procedimiento s); o una excepción al desempeño contractual de un proveedor. Aunque
éstos no están directamente relacionados con la Gestión de Servicios , que se sumará aéreas s
al nivel de comunicación requerido del personal durante la Operación del Servicio
fase.
Objetivo La comunicación durante o después de las excepciones tiene como objetivo:
• Informar a las personas adecuadas de la excepción

• Evaluar la importancia, la gravedad y el impacto de la excepción
• Asegurarse de que los recursos con las habilidades y la antigüedad adecuadas sean
involucrados en resolver la excepción y tomar acciones para prevenir futuros
reaparición
• Proporcionar actualizaciones a las partes interesadas que se ven afectadas por la excepción
Frecuencia Este tipo de comunicación es reactiva y ad hoc, ya que no ocurre

a menos que haya una excepción identificada o el riesgo de una excepción. los
Por tanto, la frecuencia es directamente proporcional a la frecuencia de las excepciones.
Una vez que se detecta una excepción, la frecuencia y el contenido de la comunicación

vendrá determinado por el impacto, la urgencia y la gravedad de la excepción.
Jugadores de roles Los jugadores de roles exactos dependerán del tipo y alcance de la excepción, pero
podría incluir:
• Administracion de incidentes
• El Service Desk
• Gestión de problemas
• Propietarios del proceso (si la excepción se relaciona con el desempeño del proceso )
• Gerentes departamentales o jefes de equipo
• SLM
• Gestión de recursos humanos
• Gerentes y expertos en tecnología
• Personal de gestión de cuentas de proveedores
• Expertos técnicos de proveedores
Contenido • Descripción y valoración de la excepción

• Evaluación del impacto . Por lo general, esto implicará comunicación.
con las partes interesadas que se ven afectadas por la excepción
Página 333
• Estimación y luego confirmación del costo de resolución

• Una decisión sobre qué acción se tomará.
• Comunicación de la decisión tomada. Es probable que esto ocurra en varios
de formatos. Por ejemplo, es probable que la comunicación con los clientes
contener una disculpa y una descripción general de alto nivel de lo que se está haciendo para
resolver la excepción. Una comunicación a las personas que están
se espera que resuelva la excepción será más detallado y
contener acciones y cronogramas claros
• Confirmación de que la excepción se ha resuelto
Contexto / fuentes • Revisión de proceso s

• Cambiar opiniones
• Revisiones de nivel de servicio
• Evento s
• Análisis de tendencias de procesos, dispositivos, rendimiento del equipo , etc.
• Incidentes, problemas y cambio de registro s
• Encuestas de satisfacción del cliente .
Tabla B.9 Comunicación durante las excepciones
Página 334
B7 Comunicación relacionada con emergencias
Aunque ITIL especifica cómo lidiar con situaciones urgentes de alto impacto como
desastres ( Gestión de la continuidad del servicio de TI ) e Incidentes mayores ( Incidentes
Management ), los gerentes en la fase de Operación del Servicio se encontrarán
tratar con varios tipos y escalas de emergencia no cubiertos en estos
Procesos. Es importante señalar que este no es un proceso separado , más bien es un
visión de varios procesos y situaciones desde la perspectiva de la comunicación.
La comunicación durante las emergencias es similar en propósito y contenido a

comunicación durante las excepciones. Las principales diferencias están en el nivel de
urgencia e impacto de la excepción.
Las comunicaciones de emergencia suelen ser iniciadas por el administrador de incidentes (ver
párrafo 4.2.5 para una discusión sobre incidentes mayores) o por un gerente senior de TI
que ha sido designado como el punto de escalada para todas esas emergencias.
En el caso de que se invoque un plan de continuidad del servicio de TI , este incluirá un

Plan de comunicación detallado a ser ejecutado por la autoridad competente.
El gerente de incidentes o el gerente designado a menudo formará un equipo de respuesta,

y la comunicación es iniciada y coordinada por este equipo.
Propósito El propósito de la comunicación en una emergencia es investigar y

confirmar el impacto y la gravedad del incidente para confirmar que se trata de un
situación de emergencia. También debe confirmar que este Incidente no representa un
desastre o cualquier contingencia cubierta en los planes de continuidad del servicio de TI.
Tan pronto como se haya identificado el alcance de la emergencia, el equipo responsable

para manejar la situación asignará recursos para crear un plan de acción y para
comenzar a resolver la emergencia y restablecer el servicio.
Frecuencia Este tipo de comunicación no ocurre a menos que haya un Incidente Mayor o
situación de emergencia.
Una vez que se detecta una excepción, la frecuencia y el contenido de la comunicación

ser determinado por el impacto y la gravedad de la excepción, y potencialmente por un
Plan de recuperación de servicios .
Papel • Gerente de incidentes

Jugadores • Altos gerentes de grupos responsables del personal de TI que se requerirá
para resolver la situación
• Gerentes y ejecutivos comerciales (posiblemente incluido el personal legal si el
la organización está expuesta a posibles acciones legales como resultado del incidente )
• Cliente s y el usuario s
• Gerente de continuidad del servicio de TI y equipo de coordinación central
• El personal y los gerentes de proveedores superiores (según el alcance y la naturaleza de
la situación)·
Página 335
• Gerentes y personal de Gerencia Técnica

• Personal y gerentes de gestión de aplicaciones
• Personal y gerentes de gestión de operaciones de TI
Contenido • La naturaleza y el alcance de la emergencia.

• Evaluación del impacto . Normalmente, esto implicará la comunicación con
las partes interesadas que se ven afectadas por la excepción
• Estimación y luego confirmación del costo de resolución
• Una decisión sobre qué acción se tomará.
• Comunicación de la decisión tomada. Es probable que esto ocurra en varios
formatos. Por ejemplo, es probable que la comunicación con el cliente contenga
una disculpa y una descripción general de alto nivel de lo que se está haciendo para resolver el
excepción. Una comunicación a las personas que se espera que resuelvan el
La excepción será más detallada y contendrá acciones y cronogramas claros.
• Confirmación de que la excepción se ha resuelto ·
Contexto / • Registro de incidentes para centro de investigaciones s

fuentes • Evento s
• Reuniones de crisis o emergencia convocadas por el Gerente de Incidentes, el
gerente designado, o el gerente de continuidad del servicio de TI
Tabla B.10 Comunicación durante emergencias
Página 336
B8 Comunicación con usuarios y clientes
Esta sección aparece en último lugar, no porque sea la menos importante, sino porque
incorpora varias de las áreas discutidas anteriormente. Un principio importante en
comunicarse con los clientes es que la comunicación no debe centrarse en
aspectos internos de la Operación del Servicio . La atención se centra en el cliente o el usuario s'
requisitos y qué está haciendo TI para cumplirlos. Esto no debería involucrar
descripciones técnicas e información detallada sobre procesos internos.
Propósito Hay una serie de razones para la comunicación del usuario y el cliente en el Servicio
Operación. Éstos incluyen:
• Asegurarse de que los servicios se hayan prestado según lo acordado

• Comunicación alrededor cumplimiento de Solicitud de Servicio s
• Informar incidentes y mantener a los usuarios y clientes actualizados sobre sus
estado hasta que se resuelva
• Notificar a los usuarios y clientes de los cambios que puedan afectarlos.
• Brindar acceso a los servicios
• Hacer frente a posibles problemas de seguridad
• Programación de actividades que involucran a usuarios o clientes , por ejemplo, mantenimiento.
• Notificación de eventos comerciales especiales que requieran soporte adicional o
prioridades cambiadas
• Revisión de la satisfacción de clientes y usuarios
• Coordinación en situaciones de contingencia
Frecuencia La comunicación con usuarios y clientes es continua. El formato y contenido de

La comunicación estará definida por los procesos que se estén ejecutando. Para
ejemplo, la comunicación sobre un Incidente será determinada por el Incidente
Proceso de gestión .
Algunas comunicaciones serán formales y programadas, por ejemplo, proporcionar informes sobre el
desempeño de un servicio durante una reunión de revisión . Otra comunicación será
formal, pero ad hoc, por ejemplo, comunicación sobre el estado de un incidente
Papel La identidad de los jugadores de rol y su número dependerá de qué proceso se

Jugadores ejecutado, el tipo de situación que ha ocurrido y el alcance de lo que se
ser comunicado, por ejemplo, proporcionando una actualización sobre el estado de un Servicio
La solicitud tendrá una audiencia muy diferente a la de participar en un Servicio.
Reunión de revisión de nivel
Contenido El contenido de esta comunicación variará según el contexto. De todos modos, eso
Es importante orientar la comunicación hacia la audiencia. Esto significa usar el servicio
nombres en lugar de nombres de servidores o aplicaciones , ser profesional, evitar
jerga técnica, no ser condescendiente y tratar a los clientes y usuarios con
el respeto
Contexto / El contexto de esta comunicación es la ejecución del día a día de operaciones

fuentes actividades y la prestación y apoyo de servicios. Los equipos de operaciones de servicio deben
no comunicarse con los clientes o usuarios sobre cuestiones de planificación , estrategia ,
diseño o prueba, a menos que hayan sido asignados a un equipo de proyecto que
Página 337
lidiar con una de estas áreas
Tabla B.11 Comunicación con usuarios y clientes
Página 338
Apéndice C: Kepner y Tregoe
Charles Kepner y Benjamin Tregoe desarrollaron un método útil para analizar
problema s. En este apéndice, su método se presenta como un ejemplo de
Método de análisis de problemas.
Kepner y Tregoe afirman que el análisis de problemas debe ser un proceso sistemático
de resolución de problemas y debe aprovechar al máximo el conocimiento y
experiencia. Distinguen las siguientes cinco fases para el análisis de problemas.
(descrito más adelante):
• Definiendo el problema
• Describir el problema con respecto a la identidad, la ubicación, la hora y el tamaño.
• Establecer posibles causas
• Prueba de la causa más probable
• Verificación de la verdadera causa.
Dependiendo del tiempo y la información disponible, estas fases se pueden realizar a un

en mayor o menor medida. Incluso en situaciones en las que solo una cantidad limitada de
la información está disponible, o la presión de tiempo es alta, vale la pena adoptar un
enfoque estructurado del análisis de problemas para mejorar las posibilidades de éxito
Página 339
C1 Definiendo el problema
Debido a que la investigación se basa en la definición del problema , esta definición

tiene que indicar con precisión qué desviaciones de los niveles de servicio acordados han
ocurrió.
A menudo, durante la definición de un problema, la causa más probable del problema ya es

indicado. Tenga cuidado de no sacar conclusiones precipitadas, que pueden orientar la
investigación en la dirección equivocada desde el principio.
En la práctica, la definición de problemas es a menudo una tarea difícil debido a un complicado sistema de TI.
Infraestructura y acuerdos no transparentes sobre niveles de servicio
C2 Describiendo el problema
Los siguientes aspectos se utilizan para describir el problema, es decir, cuál ES el problema:
• Identidad. ¿Qué parte no funciona bien? ¿Cuál es el problema?

• Localización. ¿Dónde ocurre el problema?
• Hora. ¿Cuándo empezó a ocurrir el problema? ¿Con qué frecuencia ha
Ocurrió el problema?
• Tamaño. ¿Cuál es el tamaño del problema? ¿Cuántas partes se ven afectadas?
La situación de 'SI' está determinada por las respuestas a estas preguntas. El siguiente paso
es investigar qué partes similares en un entorno similar están funcionando
adecuadamente. Con esto, se formula una respuesta a la pregunta '¿Qué PODRÍA SER sino
¿NO ES?' (¿Qué partes podrían estar mostrando el mismo problema pero no?).
Entonces es posible buscar de manera efectiva las diferencias relevantes en ambas situaciones.
Además, los cambios pasados, que podrían ser la causa de estas diferencias, pueden
ser identificado
C3 Establecimiento de posibles causas
Es muy probable que la lista de diferencias y cambios mencionados anteriormente contenga la causa
del problema, por lo que las posibles causas se pueden extraer de esta lista.
C4 Prueba de la causa más probable
Es necesario evaluar cada posible causa para determinar si podría ser la causa
causa de todos los síntomas del problema.
Página 340
C5 Verificación de la verdadera causa
Las posibles causas restantes deben verificarse como la fuente de la

problema . Esto solo se puede hacer demostrando esto de una forma u otra, por
ejemplo implementando un cambio o reemplazando una pieza. Abordar lo posible
causas que se pueden verificar de forma rápida y sencilla primero
Página 341
Apéndice D: Diagramas de Ishikawa
El diagrama de Ishikawa , también conocido como espina de pescado, causa y efecto o árbol
Diagrama, es una herramienta que se utiliza para identificar y presentar sistemáticamente todos los
posibles causas de un problema particular en un gráfico. La técnica lleva el nombre
su desarrollador, Kaoru Ishikawa (1915-1989), líder en control de calidad japonés . Un
A continuación se muestra un ejemplo.
El objetivo principal está representado por la columna vertebral o el tronco del diagrama y el
los factores se representan como ramas. Los factores secundarios se agregan luego como
tallos, etc. La creación del diagrama estimula la discusión y, a menudo, conduce a
mayor comprensión de un problema complejo. Estos diagramas son extensamente
Se utiliza para identificar soluciones a problemas sistémicos, como identificar la causa.
de pérdida de productividad en las líneas de montaje, o niveles más bajos de satisfacción del cliente en un
organización de servicios .
La técnica básica de desarrollo de estos diagramas, junto con una muy simple
ejemplo, se muestra aquí. Un equipo de resolución de problemas utilizará el diagrama de Ishikawa
como sigue:
• 1.- Elaborar un diagrama en blanco en un formato que pueda ser visto por todo el
grupo. Esto podría ser un rotafolio, una pizarra, un proyecto ed a través de un proyector de datos.
desde una PC, etc.
• 2.- Definir el problema que el grupo está tratando de resolver de forma clara y específica.
términos y escríbalo en el cuadro en el cuadro "cabeza de pez" del diagrama.
• 3.- Escribe las categorías de causa en las puntas de las 'espinas de pescado'. Estos
deberían ser categorías bastante amplias ya que aún no se conocen las causas exactas.
En la Figura D.1 se muestra un ejemplo en el que el grupo está tratando de encontrar
causa de niveles inaceptables de tiempo de inactividad de la red .
Figura D.1 Ejemplo de inicio de un diagrama de Ishikawa
Página 342
• 4.-Utilice técnicas de lluvia de ideas para que los participantes sugieran posibles
causas, y anótelas en la rama correspondiente del diagrama. Un simple
El diagrama se ha completado en la Figura D.2.
Figura D.2 Muestra de un diagrama de Ishikawa completo
• 5.- Interpretar el diagrama. Esto podría hacerse clasificando las principales causas
basado en la experiencia y los datos disponibles. Una vez que las principales causas han sido
seleccionado, cada uno será investigado más a fondo de acuerdo con su rango y
prioridad
Página 343
Apéndice E: Descripción detallada de la gestión de instalaciones
El propósito de este apéndice no es proporcionar una explicación detallada de todos

aspectos de la Gestión de Instalaciones . Más bien, destacará los más importantes
actividades para ayudar a posicionar algunas de las otras funciones y a identificar
donde procesos específicos impactan en la buena Gestión de Instalaciones y viceversa.
La gestión de instalaciones proporcionará información a la gestión de la configuración.

con respecto a la ubicación y el estado de las IC, y también será una parte integral de
Gestión de cambios , planificación de la capacidad y disponibilidad y continuidad del servicio
Gestión .
Los principales componentes de la gestión de instalaciones son los siguientes
Página 344
E1 Gestión de edificios
Aunque muchas actividades de gestión de edificios se subcontratan o se contratan

otros proveedores , siguen siendo responsabilidad de la Gestión de Instalaciones. Típico
actividades incluidas:
• Limpieza. Esto lo pueden hacer empleados o terceros. Es muy

importante aquí para garantizar que el personal de limpieza cumpla con todos los controles de acceso
y políticas de confidencialidad .
• Eliminación de desechos , incluida la separación de elementos para reciclaje,
elementos (por ejemplo, baterías, líquidos y gases como refrigerante para el aire
acondicionadores), documentación confidencial.
• Instalación de instalaciones físicas , como cableado, energía, pisos elevados,
sistemas seguros de entrada y salida, oficinas, mobiliario, etc.
• Estacionamiento. Esto debe incluir la asignación de estacionamiento para el personal y el contratista,
estacionamiento para visitantes y estacionamiento para personal discapacitado o visitantes. Instalaciones
La gestión también incluirá la documentación y el cumplimiento de las políticas.
alrededor de quién debe estacionar dónde.
• Control de acceso y vigilancia de la seguridad. Esto se cubre con más detalle
en la sección E6 a continuación y también en el Apéndice F.
• Señalización , es decir, garantizar que se pueda encontrar el edificio, pero que obviamente no sea un
ubicación clave digna de ataque.
Página 345
Alojamiento de equipos E2
Las instalaciones no se gestionan simplemente porque existen y son propiedad de un

organización . Se gestionan de forma que las personas y los equipos que contienen
se puede utilizar para fines específicos. En el caso de instalaciones de TI, como datos
Centros, esto agrega algunas demandas muy específicas al administrador de esa instalación.
Uno de ellos es el alojamiento de equipos de TI. Este no es solo un caso de proporcionar una
sala y permitiendo a los equipos de Gestión Técnica instalar y gestionar
equipo. Los diferentes tipos de equipos tienen requisitos muy específicos del
instalación en la que se encuentra, por ejemplo:
• El equipo enfriado por agua necesita acceso a agua fría, que debe ser
suministrado por la instalación
• El peso del equipo varía y debe distribuirse de manera que no se
poner demasiada tensión en el suelo
• El suministro eléctrico puede variar para diferentes tipos de equipos.
Si el equipo simplemente se coloca en el centro de datos en el orden en que se

recibido, será muy difícil encontrar algo y es posible que el personal tenga que cruzar el
piso varias veces para atender equipos similares. Este tráfico pone en peligro la
integridad y seguridad de otros equipos en el piso.
Esto significa que la Gestión de Instalaciones debe asumir la responsabilidad de planificar

y diseñar el diseño del centro de datos para un acceso y seguridad óptimos de
el equipo que se alojará allí. Al mismo tiempo, debería ser
recordó que este equipo se está utilizando para brindar servicios de TI , y cualquier
los requisitos para ese servicio deben tenerse en cuenta al hospedar el
equipo. Por ejemplo, es posible que los estándares del centro de datos deban cambiarse en
para acomodar un servidor no estándar .
Además, la mayoría de los centros de datos también ofrecen las siguientes actividades de alojamiento:
• Recepción de equipos nuevos

• Desembalaje, configuración e instalación de equipos estándar
• Producir y mantener diagramas de distribución del centro de datos.
• Gestionar el cronograma de cualquier actividad de mantenimiento a los equipos alojados
en el centro de datos
• Eliminación de retirarse equipos d.
De esta lista de actividades, está claro que la Gestión de Instalaciones no debe ser
vista como una función separada , pero en gran parte del funcionamiento general de TI en
la organización .
Página 346
Gestión de energía E3
La gestión de energía se refiere a la gestión del suministro y la utilización de la energía.

fuentes que se utilizan para mantener la instalación funcional. Esta definición de poder
La gestión tiene una serie de implicaciones, que se analizan a continuación.
La primera tarea de la administración de instalaciones en la administración de energía es determinar la energía

requisitos para la instalación. Esto incluye definir:
• Para qué se necesitará la energía, por ejemplo, espacio de oficina, equipo en

el Data Center, la cafetería, etc.
• Cuándo se va a necesitar ese poder. Algunas operaciones requieren
Suministro constante de electricidad las 24 horas del día. Otros, como oficina
espacio, utilizará más electricidad durante el día y muy poca por la noche.
Otros solo necesitan electricidad en un momento específico
• Cuánta energía se necesitará
• Qué tipo de energía se utilizará. Aunque la mayoría de las organizaciones utilizan
electricidad, en muchos lugares los sistemas de calefacción dependen de
gas natural.
La Dirección de Instalaciones también será responsable de establecer un contrato con

empresas de servicios públicos o, en muchos casos, la autoridad local o el municipio que
proporciona ese servicio. Esto incluirá una tarifa acordada y un nivel de disponibilidad .
Esto se ha vuelto muy importante en lugares donde el suministro de electricidad es
variable debido a la falta de infraestructura o debido a la sobreutilización por general
consumidores.
La administración de las instalaciones será responsable de establecer la energía de reserva.

fuentes de apagones , desastres y otras contingencias. Esto es generalmente en
la forma de fuentes de alimentación ininterrumpida (UPS) para equipos clave, y también
generadores alimentados por una fuente de energía alternativa (generalmente diesel). Instalaciones
La gerencia es responsable no solo de suministrar estas alternativas, sino también de
probándolos, conservando los suministros de combustible y manteniéndolos.
Es necesario decir que cualquier fuente de energía alternativa debe ser modelada y
probado para asegurar que es capaz de manejar la demanda requerida y también que
se activará automáticamente después de un corte de energía.
Otra actividad clave de la gestión de instalaciones es gestionar la utilización de

poder. Tradicionalmente, la función de la gestión de instalaciones era solo garantizar que
el poder estaba disponible. Sin embargo, a medida que los recursos naturales se vuelven más escasos y
caro, se está prestando más atención a las técnicas para gestionar la utilización
más responsablemente.
Uno de estos enfoques es la gestión dinámica de la energía en los centros de datos. los
El principio es que durante los períodos pico de procesamiento, se utilizarán más computadoras para
Página 347
Haz el trabajo. A medida que se reduce la carga de trabajo , el trabajo se centraliza en menos
computadoras, mientras que las que no se utilizan se apagan o se colocan
en modo de espera. Esto requiere una integración significativa entre las actividades de
Gestión de Operaciones de TI, Gestión Técnica y todo el Diseño de Servicios
Procesos. Esto se discute con más detalle en la sección sobre Centro de datos.
estrategias.
Página 348
E4 Sistemas de alerta y acondicionamiento ambiental
La gestión de instalaciones asegura que las condiciones físicas dentro de los centros de datos
o las salas de informática se mantienen en los niveles correctos para optimizar las operaciones de TI .
Estas condiciones incluyen:
• Temperatura
• Humedad
• Calidad del aire
• Libre de riesgos ambientales , como incendios, inundaciones, etc.
La temperatura se mantiene mediante sistemas de calefacción y refrigeración, así como

disposición del equipo en la instalación. Esto requerirá las siguientes actividades:
• Determinar la producción de calor de los CI y su funcionamiento óptimo.

la temperatura.
• Identificar el requisito de refrigeración total para todos los equipos de la instalación como
así como para artículos específicos. Por ejemplo, un acondicionador de aire puede
mantener un centro de datos a una temperatura constante, pero puede haber
equipo que necesita mantenerse a una temperatura más baja.
• Modelar los requisitos generales de calefacción y refrigeración, así como
mapear áreas específicas en la instalación que pueden ser naturalmente más cálidas o
enfriador. Esta información se utiliza para identificar dónde está la mejor ubicación para
equipo específico. Es importante tener en cuenta que cuando se instala un nuevo equipo
instalado en una instalación, cambiará el mapeo de más frío y más cálido
áreas en la instalación, de ahí el requisito de más sofisticados
técnicas de mapeo y modelado. Estos modelos también necesitarán tomar
en cuenta las variaciones estacionales de temperatura. Por ejemplo, algunos
Es posible que sea necesario calentar las instalaciones en invierno y enfriarlas en verano.
• Compra y mantenimiento
capacidad de unidades
y el mantenimiento de aire
de estas acondicionado
unidades con suficiente
con regularidad.
• Invertir en unidades de aire acondicionado de respaldo que se puedan usar si una unidad principal
falla, o para proporcionar capacidad de enfriamiento adicional en días excepcionalmente calurosos
(aunque esto debería ser una rara excepción, si la unidad de respaldo también se usa
con frecuencia esto implica que la planificación inicial fue inadecuada).
• Monitoreo continuo de la temperatura y ajuste de la configuración de enfriamiento.
según los cambios en la temporada y la distribución del equipo. Estos monitores
podría estar vinculado al Puente de Operaciones , que podría responder
a cualquier desviación significativa de las temperaturas normales.
• Identificar y evitar errores 'obvios' , como localizar la salida de calor
de un servidor principal cerca de la entrada de una unidad de aire acondicionado; o
evitando el flujo de aire apilando los manuales en un espacio "libre".
Se deben tomar pasos similares para identificar los niveles ideales de humedad y especificar
si se requiere equipo deshumidificador.
Página 349
El equipo de detección de humo generalmente se instala como parte del control general de incendios.
estrategia de la instalación y está vinculado a sistemas automatizados de extinción de incendios. Sin embargo,
La gerencia de las instalaciones no debe asumir que una respuesta automatizada al incendio
Las amenazas serán adecuadas. Las unidades de detección de humo deben estar conectadas a la
Se debe investigar Operations Bridge y cualquier excepción.
Las unidades de detección de movimiento deben instalarse en todas las áreas de operación desatendidas.
Esto garantizará que se detecte el acceso no autorizado y se informe a las instalaciones.
Seguridad y posiblemente también el Puente de Operaciones. Esto ayudará a hacer cumplir las
programación de actividades de mantenimiento o instalación.
La detección de polvo y partículas puede ayudar a mantener la calidad del aire alrededor de los sistemas.
que son particularmente sensibles. Nuevamente, los monitores deben enrutarse a las operaciones
Puente de modo que las desviaciones se puedan investigar y corregir antes de cualquier
se produce el daño.
También hay varios otros tipos de monitoreo de instalaciones, que se basan

sobre la ubicación de la instalación. Por ejemplo, monitores de movimiento de edificios instalados
en lugares con altos niveles de actividad sísmica . Estos actúan como alerta temprana
sistemas para indicar que un sistema debe apagarse o fallar a un
sitio alternativo antes de que un temblor de tierra significativo o un terremoto afecte a los
equipo. También se están instalando monitores y salvaguardias similares en las instalaciones.
donde hay una gran actividad de tormenta eléctrica.
Estos sistemas se denominan colectivamente sistemas de gestión de edificios.

(BMS), aunque como estas herramientas están integradas, el término se está utilizando para referirse a
un único sistema de gestión integrado , en lugar de una colección suelta de herramientas
realizar funciones similares s. Se debe pensar en el uso de herramientas de monitoreo.
que están integrados en, o al menos consistentes con, herramientas de monitoreo existentes. (Ver
Capítulo 7 para obtener más detalles sobre las herramientas).
Página 350
E5 Seguridad
Una de las principales preocupaciones de la Gestión de Instalaciones es la seguridad de las personas que trabajan en
el edificio. Por lo tanto, la administración de instalaciones es responsable de comprender
y hacer cumplir las normas y la legislación de seguridad pertinentes .
La seguridad se aplica en las siguientes áreas:
• Edificio de diseño y construcción

• Disposición de las salas y equipos de la instalación
• Educación de todo el personal sobre las normas de seguridad vigentes en la instalación.
• Definición de procedimientos y rutas de evacuación y puntos de reunión en el
caso de incendio u otra situación potencialmente mortal
• Publicar avisos e información sobre cualquier información de seguridad de la cual
el personal debe estar al tanto.
Control de acceso físico E6
Esta es una parte muy importante de la gestión de instalaciones y se ha convertido en un

campo especializado. Como tal, el contenido se resume aquí por conveniencia, pero
discutido en detalle en el Apéndice F.
Los componentes principales del control de acceso físico (como se analiza en el Apéndice F)
son:
• Asistencia para definir y mantener controles de acceso físico como parte de

las políticas de seguridad de la organización
• Mantenimiento de planos de planta indicando qué áreas están restringidas
• Instalación y mantenimiento de dispositivos de control de acceso físico
Seguimiento y control de acceso a instalaciones
• Personal de seguridad
• Instalación y mantenimiento de equipos de vigilancia
• Protección contra la ingeniería social
E7 Envío y recepción
Las grandes instalaciones requieren áreas especiales donde se pueda realizar la entrega de muebles,
equipo informático, bastidores, etc. Esta área debe asegurarse para que la entrega
el personal no tiene acceso al resto de la instalación. También debe haber un
tienda segura cerca del área de recepción donde los artículos se pueden almacenar hasta que puedan ser
trasladado a su ubicación final.
Página 351
Es necesario que exista un proceso para garantizar que se contabilicen los artículos que se enviarán.
para y que solo esos artículos sean retirados por el contratista de entrega o despacho.
Siempre que sea posible, estos elementos deben guardarse en el almacén seguro en el
área de envío y entrega antes de ser enviado. Esto evitará
acceso no autorizado a la instalación.
La documentación de entrega y envío debe completarse, inspeccionarse y firmarse

por cada envío que se entregue o despache. Un registro central de todos
Los envíos también deben mantenerse como control.
E8 Participación en la gestión de contratos
La mayoría de las instalaciones son suministradas, gestionadas y atendidas por varias entidades.
Aunque los contratos reales con estas entidades normalmente se gestionarían
por los departamentos comerciales y legales apropiados, la Gestión de Instalaciones
juegan un papel clave en la especificación y negociación de estos contratos. Contratos típicos
incluir:
• Gestión de arrendamientos de inmuebles arrendados. Esto es bastante raro, ya que la mayoría

las organizaciones ven su centro de datos como un activo clave . Arrendamiento de tales
instalaciones se verían como un riesgo debido al potencial de que el edificio
se vende, el arrendador cierra el negocio o el arrendador no cumple con el
contrato en términos de mantenimiento adecuado.
• Arrendamiento o mantenimiento de equipos ambientales , como aire
unidades de acondicionamiento, monitoreo y alerta ambiental (por ejemplo, humo
equipos de detección y extinción o extinción de incendios).
• Contratos de mantenimiento de edificios. Estos incluyen el mantenimiento de ascensores,
pisos, fontanería y suministro eléctrico.
• Instalaciones de telecomunicaciones. Aunque las telecomunicaciones suelen
administrado por un equipo o departamento dedicado o como parte de Wide Area
Redes, a menudo dependen de terceros para el suministro y
Mantener el equipo de telecomunicaciones ubicado dentro o fuera de los Datos.
Centrar. En muchos países, estos son proporcionados por gobiernos o paraestatales.
organizaciones de telecomunicaciones. Manejo de este tipo de
Los contratos requieren un conjunto de habilidades especiales.
• Servicios de seguridad para la prestación de control de acceso físico y armado
servicios de respuesta.
Una parte muy importante de la gestión de contratos es garantizar que todos los terceros
el personal conoce y cumple las políticas de seguridad de la organización .
Esto incluye control de acceso físico, confidencialidad y uso no autorizado del
las instalaciones o el equipo de la organización. Regulares de auditoría s deben mantenerse para asegurar
que esto se está haciendo cumplir.
E9 Mantenimiento
Página 352
La administración de las instalaciones es responsable de coordinar todo el mantenimiento de rutina.

actividad dentro del edificio. Esto se refiere tanto al mantenimiento de edificios como a
el mantenimiento de equipos en el Data Center.
La razón para incluir el mantenimiento del equipo es simplemente para evitar que el edificio
estar expuesto a demasiada actividad inusual en un momento dado. Varios equipos
trabajar en diferentes lugares del centro de datos al mismo tiempo representa un
riesgo de seguridad y protección .
Es importante tener en cuenta que el mantenimiento real de los equipos de TI se realiza

por el personal de la Gerencia Técnica, pero bajo la coordinación de Cambio
Gestión y Gestión de Instalaciones.
El Gerente de Instalaciones debe mantener un cronograma maestro de todos los planes

actividad de mantenimiento para garantizar que la actividad de mantenimiento esté debidamente coordinada.
Este cronograma forma parte del cronograma general de cambios de la gestión de cambios.
y se utiliza para garantizar que no haya conflictos entre el mantenimiento de rutina
actividad y despliegue de cambios.
Página 353
Apéndice F: Control de acceso físico

La Sección 5.12 y el Apéndice E introdujeron el área de Control de acceso físico como
parte de la Gestión de Instalaciones. Esta sección proporciona una discusión más detallada
de esta zona.
La Gestión de Seguridad de la Información es responsable de definir y documentar todos

políticas de control de acceso. Estas políticas identificarán todas las medidas de seguridad física.
que deben tomarse y qué grupos de empleados deben tener acceso a qué
tipo de instalación. La administración de instalaciones se asegurará de que estas políticas sean
en vigor. Las políticas deben incluir:
• Qué áreas están restringidas y para quién

• Qué controles de acceso se implementarán
• ¿Bajo qué circunstancias se permitirá el acceso a restricciones específicas?
áreas. Por ejemplo, evitar todo acceso a un piso del centro de datos a menos que un
El número RFC autorizado se escribe en un teclado.
• Cómo se supervisará el control de acceso
• Una declaración de políticas de privacidad y qué información debe conocerse en
para permitir el acceso
• Políticas relativas a la vigilancia del personal, por ejemplo, lo que puede
registrado, dónde y si hay excepciones.
La mayoría de las organizaciones utilizan varios niveles de control de acceso, comenzando con el acceso a
la propiedad, luego moverse para acceder a áreas específicas en el edificio y luego a
funciones , equipos o salas específicas . Cada nivel de seguridad se aplica mediante
diferentes mecanismos y personal, proporcionando así una seguridad adicional.
Todas las instalaciones deben tener un plano de planta actualizado y documentado que indique exactamente
qué áreas están restringidas y cuáles no. Este plan también indicará qué
se implementan las medidas de seguridad y dónde. Esto ayudará en las auditorías de seguridad .
y también para el mantenimiento de equipos de control de acceso.
Los dispositivos de control de acceso deben instalarse en todas las entradas y salidas. El objetivo
de estos dispositivos es para asegurar que solo el personal autorizado tenga acceso
área restringida. Aunque esto parece a primera vista ser bastante sencillo
tema, hay una serie de elementos que deben tenerse en cuenta (ver
Cuadro F.1).
Acceso Ejemplo Ventajas Desventajas

control
Mecánico Cerradura y llave Estable y confiable Requiere control de llave
Barato Las cerraduras tienen que ser
reemplazado cada vez
alguien deja el
Página 354
organización
Puede ser fácilmente
comprometido por cualquiera
con conocimiento de unos pocos
técnicas simples
Código Mecánico (por ejemplo, un Estable Alguien observando

acceso dispositivo de pulsador montado Relativamente barato personal que utiliza el
en la puerta) dispositivo puede obtener el
Electrónico (por ejemplo, un teclado codificar fácilmente
utilizado para armar o desarmar un El código debe cambiarse
alarma de seguridad ) cada vez que alguien
deja la organización
La gente tiende a escribir el
codificar abajo ··
Electrónico Tarjetas clave Fácil de usar Relativamente caro,

acceso Puede usarse para rastrear aunque los costos tienen
acceso del personal disminuido, y a menudo
Puede cancelarse o más barato que usar
cambiado centralmente a recursos humanos para
traje cambiado proteger físicamente cada uno
requisito s punto de acceso
Puede cancelarse incluso Depende del poder
donde el personal no disponibilidad
devolver su tarjeta Puede verse comprometido por
personas que usan especializadas
equipo de copia
Biométrico Escáner de retina o voz Muy fiable Dependiendo del

análisis mecanismo para disponibilidad de poder
identificando específicos Requiere más
individuos acceso sofisticado
Difícil de forjar el acceso sistemas de control
Más eficaz en Relativamente caro
contrarrestar las redes sociales
Ingenieria ·
Múltiple Puerta con tarjeta llave. Uno Fácil de mover de uno Difícil de controlar
acceso persona abre la puerta y lugar a otro, 'Tailgating'
permite el acceso a cualquier especialmente donde Dependiendo del
número de personas los grupos están trabajando conciencia de seguridad de
acompañándolos juntos personal autorizado
Extremadamente vulnerable a
Ingeniería social
No debe usarse en
áreas altamente seguras
Único El torniquete permite solo uno Más fácil de controlar Podría convertirse en un
acceso persona para entrar. Lo mismo acceso cuello de botella en las horas pico
La tarjeta de acceso no se puede utilizar para Previene social Requiere más intensivo
entrar una segunda persona ingeniería más vigilancia y dotación de personal
efectivamente
Uni- Puerta giratoria que permite Bueno para situaciones Requiere más
direccional solo acceso o solo salida. donde no hay necesidad monitoreo para asegurar que
Página 355
acceso Usado típicamente en aeropuertos para monitorear lo que la gente la gente no intenta
donde el personal de seguridad sacar, pero donde pasar por el mal
solo están preocupados por cosas que toman dirección
personas que ingresan al aeropuerto, podría causar significativo Normalmente unidireccional;
pero no sobre los que salen daño también implica adicional
equipo de escaneo y
vigilancia
Bi- Puerta con control de acceso Bueno para general La gente que sale puede
direccional acceso a restringido proporcionar acceso a
acceso áreas · personal no autorizado
mudándose
Podría ser un cuello de botella
(p. ej. en bidireccional
torniquetes, gente que va
tengo que esperar
gente entrando)
Activo Requiere acción por Más fácil de controlar Requiere personal para
personal para acceder, acceso recordar un código o
por ejemplo, deslizar una tarjeta de acceso o Más seguro · traer una tarjeta de acceso
perforando un código
Pasivo El detector pasivo desbloquea un Proporciona una salida más segura en

Fácil para no autorizados
salir del interior siempre que el caso de un incendio personal para acceder
alguien se acerca No requiere llave simplemente esperando afuera
tarjetas para la gente la puerta
moviéndose a no seguro Puede activarse desde
áreas · el exterior insertando
algo debajo del
puerta y moviéndola dentro
rango del sensor
Tabla F.1 Dispositivos de control de acceso
Como la mayoría de los mecanismos de control de acceso físico no son infalibles, es importante
asegurarse de que el acceso pueda ser monitoreado y controlado. Esto lo hacen especialistas
personal de seguridad y por equipos de vigilancia electrónica.
Dado que la seguridad se trata de administrar el acceso de las personas a una instalación, es apropiado
que se utiliza a las personas para hacer cumplir las medidas de seguridad. Organizaciones más grandes
a veces proporcionan su propio personal de seguridad, pero la mayoría tiende a subcontratar servicios físicos
control de acceso a empresas especializadas. Esto suele ser para lo siguiente
razones:
• Los guardias de seguridad requieren capacitación especializada y generalmente están sujetos a un

código disciplinario diferente (casi militar) de la mayoría de las empresas
empleados. Esto a menudo entra en conflicto con el tipo más comercial de
código disciplinario y es mejor administrado por un grupo diferente de gerentes
utilizando una cultura de gestión diferente .
Página 356
• Es menos probable que las empresas externas se vean influenciadas por la ingeniería social
situaciones, ya que tienen una formación especializada y es poco probable que comprendan
algunos de los matices internos de la organización que podrían ser utilizados por un
ingeniero social experimentado.
El equipo de vigilancia se utiliza para ampliar la eficacia tanto de la física

Mecanismos de control de acceso y personal de seguridad. Es importante tener en cuenta
que ningún equipo de vigilancia puede reemplazar la presencia de un personal capacitado y
guardia de seguridad, simplemente amplíe su eficacia. Ejemplos de uso común
El equipo de vigilancia incluye:
• Cámaras de video para monitorear puntos de acceso clave y también en accesos menos utilizados
puntos, lo que permite que un guardia de seguridad controle varias ubicaciones a la vez.
Por lo general, estos se graban y los videos se almacenan durante algún tiempo antes de ser
usado de nuevo. Esto es para asegurar que si se descubre alguna irregularidad, el
Las cintas se pueden utilizar en la investigación. Esto significa que la calidad de
Las imágenes deben ser lo suficientemente buenas para facilitar la identificación de las personas, pero
también debe estar en un formato que facilite el almacenamiento de grandes cantidades de
datos visuales.
• Acceda a los registros de eventos. Por lo general, registran cada entrada y salida por
personal que utiliza mecanismos de acceso electrónico.
• Unidades de detección pasiva para detectar la presencia de personal en un área que
no debe tener personal.
• Alarmas que notificarán al personal de seguridad sobre accesos o salidas no autorizados, a menudo
vinculado a una alarma sonora.
No importa cuán seguro sea el entorno , depende de la seguridad

conciencia de los empleados y contratistas que trabajan en la instalación. Social
La ingeniería sigue siendo una de las violaciones más comunes de la seguridad física. Social
La ingeniería se refiere a la práctica de acceder a una instalación mediante el uso de
habilidades interpersonales y de comunicación para convencer a alguien de que permita
acceso no autorizado a un edificio, área restringida, equipos y datos restringidos;
oa gabinetes que contienen documentos confidenciales s.
Los ejemplos de ingeniería social incluyen:
• Haciéndose pasar por un contratista o empleado legítimo de la organización. los

La técnica habitual es acercarse al personal de seguridad y declarar que han
olvidado su tarjeta de acceso. Se firma un registro de acceso y una tarjeta de visitante
producido. A menudo no existe una verificación real de si la persona es un
empleado legítimo, especialmente en áreas de recepción concurridas.
• Haciéndose pasar por alguien que tiene una razón para obtener acceso no autorizado a la
instalación, por ejemplo, un trabajador de servicios públicos o un inspector de incendios.
• Un ex empleado o contratista que se acerca a las personas con las que está
familiar para permitirles el acceso.
Página 357
• 'Tailgating', donde una persona simplemente sigue a un empleado autorizado

a través de una entrada que han abierto.
La ingeniería social es el más contrarrestada mediante la aplicación de un estricto cumplimiento con acceso
procedimientos de control , programas de educación continua , sesiones informativas periódicas de
personal de seguridad y auditorías rigurosas s.
Un número creciente de empresas ofrecen servicios para probar el rigor del control de acceso.
con personas que se especializan en el uso de técnicas de ingeniería social.
Página 358
Glosario
Lista de acrónimos
ACD Distribución automática de llamadas
SOY Administración de disponibilidad
AMIS Sistema de información de gestión de disponibilidad
ÁSPID Proveedor de servicios de aplicaciones
BCM Gestión de la capacidad empresarial
BCM Gestión de la continuidad del negocio
BCP Plan de negocios continuo
BIA Análisis de Impacto del Negocio
BRM Gerente de Relaciones Comerciales
BSI Institución de estándares británicos
BSM Gestión de servicios empresariales
TAXI Consejo Asesor de Cambios
CAB / EC Consejo Asesor de Cambios / Comité de Emergencias
CAPEX Gastos de capital
CCM Gestión de la capacidad de los componentes
CFIA Análisis de impacto de fallas de componentes
CI Elemento de configuración
CMDB Base de datos de gestión de la configuración
CMIS Sistema de información de gestión de capacidad
CMM Modelo de Capacidad de Madurez
CMMI Integración del modelo de madurez de capacidad
CMS Sistema de gestión de la configuración
Cunas Comercial fuera de la estantería
LCR Factor crítico de éxito
CSI servicio de Mejoramiento contínuo
CSIP Plan de mejora continua del servicio
CSP Paquete de servicios básicos
Página 359
CTI Integración de telefonía informática
DIKW Datos-a-información-a-conocimiento-a-sabiduría
ELS Soporte vital temprano
Modelo de capacidad de eSourcing eSCM-CL para organizaciones clientes
eSCM – SP Modelo de capacidad de eSourcing para proveedores de servicios
FMEA Análisis de modos y efectos de falla
TLC Análisis del árbol de fallos
TIR Tasa interna de retorno
ISG Grupo de dirección de TI
ISMO Gestión de la seguridad de la información
SGSI Sistema de gestión de seguridad de la información
YO ASI Organización Internacional de Normalización
ISP Proveedor de servicios de Internet
ESO Tecnologías de la información
ITSCM Gestión de la continuidad del servicio de TI
ITSM Gestión de servicios de TI
itSMF Foro de gestión de servicios de TI
IVR Respuesta de Voz Interactiva
KEDB Base de datos de errores conocidos
KPI Indicador clave de rendimiento
LOS Linea de servicio
M_o_R Gestión de Riesgos
MTBF Tiempo medio entre fallos
MTBSI Tiempo medio entre incidentes de servicio
MTRS Tiempo medio para restaurar el servicio
MTTR Tiempo estimado o promedio para reparar
VPN Valor presente neto
OGC Oficina de Comercio Gubernamental
OLA Acuerdo de nivel operativo
OPEX Gastos operativos
Página 360
OPSI Oficina de Información del Sector Público
PBA Patrón de actividad empresarial
PIR Revisión posterior a la implementación
PFS Requisito previo para el éxito
PSO Interrupción del servicio proyectada
QA Seguro de calidad
SGC Sistema de manejo de calidad
RCA Análisis de raíz de la causa
RFC Solicitud de cambio
ROI Retorno de la inversión
RPO Objetivo de punto de recuperación
RTO Objetivo de tiempo de recuperación
SoC Separación de intereses
SACO Criterios de aceptación del servicio
SACM Gestión de activos y configuración del servicio
SCD Base de datos de proveedores y contratos
SCM Gestión de la capacidad del servicio
partido socialdemócrata Paquete de diseño de servicios
SFA Análisis de fallas del servicio
sorbo Plan de mejora del servicio
SKMS Sistema de gestión del conocimiento del servicio
SLA Acuerdo de nivel de servicio
SLM Gestión del nivel de servicio
SLP Paquete de nivel de servicio
SLR Requisito de nivel de servicio
SMO Objetivo de mantenimiento del servicio
COMPENSACIÓN Estándar de Procedimientos Operativos
SOR Declaración de requisitos
SPI Interfaz del proveedor de servicios
SPM Gestión de la cartera de servicios
Página 361
SPO Optimización del aprovisionamiento de servicios
SPoF Punto único de fallo
A Observación técnica
COLINA Términos de referencia
TCO Costo total de la propiedad
TCU Costo total de utilización
TQM Gestión de la calidad total
UC Contrato subyacente
HASTA Perfil del usuario
VBF Función empresarial vital
VOI Valor de la inversión
WIP Trabajo en progreso
Página 362
Lista de definiciones
Los nombres de las publicaciones incluidos entre paréntesis después del nombre de un término identifican
donde un lector puede encontrar más información sobre ese término. Esto es porque
el término es usado principalmente por esa publicación o porque es útil adicional
la información sobre ese término se puede encontrar allí. Términos sin publicación
El nombre asociado con ellos puede ser utilizado generalmente por varias publicaciones, o
no puede definirse con mayor detalle que el que se puede encontrar en el glosario, es decir,
solo indicamos a los lectores un lugar al que pueden esperar ampliar su
conocimiento o para ver un contexto mayor. Los términos con varios nombres de publicación son
ampliado en múltiples publicaciones.
Cuando la definición de un término incluye otro término, esos términos relacionados son
resaltado en un segundo color. Esto está diseñado para ayudar al lector con su
comprensión al señalarles definiciones adicionales que son parte de la
término original en el que estaban interesados. Se usa la forma ' Ver también Término X, Término Y'
al final de una definición donde un término relacionado importante no se usa con el texto
de la propia definición.
Aceptación Acuerdo formal de que un servicio, proceso, plan u otro producto de TI

es completo, preciso, confiable y cumple con los requisitos especificados.
La aceptación suele estar precedida por una evaluación o prueba y, a menudo,
requerido antes de pasar a la siguiente etapa de un Proyecto o Proceso.
Consulte también Criterios de aceptación del servicio .
Contabilidad (Estrategia de servicio) El proceso responsable de identificar los costos reales

de la prestación de servicios de TI, comparándolos con los costos presupuestados, y
gestionar la variación del presupuesto.
Actividad Un conjunto de acciones diseñadas para lograr un resultado particular. Las actividades son
generalmente se define como parte de procesos o planes, y se documentan en
Procedimientos.
Servicio acordado (Diseño de servicio) Un sinónimo de horas de servicio, comúnmente utilizado en forma
Hora cálculos de disponibilidad. Consulte también Tiempo de inactividad.
Convenio Un documento que describe un entendimiento formal entre dos o más

fiestas. Un Acuerdo no es legalmente vinculante, a menos que forme parte de un
Contrato. Consulte también Acuerdo de nivel de servicio , Nivel operativo
Convenio.
Alerta (Operación de servicio) Una advertencia de que se ha alcanzado un umbral,

algo ha cambiado o ha ocurrido una falla. Las alertas son a menudo
creado y gestionado por herramientas de gestión del sistema y se gestionan
por el proceso de gestión de eventos.
Modelado analítico (estrategia de servicio) (diseño de servicio) (mejora continua del servicio) A
técnica que utiliza modelos matemáticos para predecir el comportamiento de un
Elemento de configuración o servicio de TI. Los modelos analíticos se utilizan comúnmente
en Gestión de Capacidad y Gestión de Disponibilidad. Ver también
Página 363
Modelado.
Solicitud Software que proporciona funciones requeridas por un servicio de TI.

Cada Aplicación puede formar parte de más de un Servicio de TI. Un
La aplicación se ejecuta en uno o más servidores o clientes. Ver también Aplicación
Gestión, Portafolio de Aplicaciones .
Solicitud (Diseño del servicio) (Operación del servicio) La función responsable de

administración la gestión de aplicaciones a lo largo de su ciclo de vida.
Solicitud (Diseño de servicio) Una base de datos o documento estructurado que se utiliza para gestionar
portafolio Aplicaciones a lo largo de su ciclo de vida. La carpeta de aplicaciones contiene
Atributos clave de todas las aplicaciones. La carpeta de aplicaciones es a veces
implementado como parte de la cartera de servicios, o como parte de la
Sistema de gestión de la configuración.
Servicio de aplicación (Diseño de servicio) Un proveedor de servicios externos que proporciona servicios de TI
proveedor utilizando Aplicaciones que se ejecutan en las instalaciones del proveedor de servicios. Usuarios
acceder a las Aplicaciones mediante conexiones de red al proveedor de servicios.
Tamaño de la aplicación (Diseño de servicio) La actividad responsable de comprender el

Requisitos de recursos necesarios para admitir una nueva aplicación o una
Cambie a una aplicación existente. El tamaño de la aplicación ayuda a garantizar que
el Servicio de TI puede cumplir con sus objetivos de nivel de servicio acordados para Capacidad y
Rendimiento.
Arquitectura (Diseño de servicio) La estructura de un sistema o servicio de TI, incluida la

Relaciones de los componentes entre sí y con el entorno que
están en. La arquitectura también incluye los Estándares y Directrices que
orientar el diseño y la evolución del Sistema.
Evaluación Inspección y análisis para verificar si una Norma o un conjunto de Directrices

se está siguiendo, que los registros son precisos, o que la eficiencia y
Se están cumpliendo los objetivos de eficacia. Consulte también Auditoría.
Activo (Estrategia de servicio) Cualquier recurso o capacidad. Activos de un servicio

proveedor, incluido todo lo que pueda contribuir a la entrega de un
Servicio. Los activos pueden ser de uno de los siguientes tipos: Gestión,
Organización, Proceso, Conocimiento, Personas, Información, Aplicaciones,
Infraestructura y Capital Financiero.
Gestión de activos (Transición del servicio) La gestión de activos es el proceso responsable de

seguimiento y presentación de informes sobre el valor y la propiedad de los activos financieros
a lo largo de su ciclo de vida. La gestión de activos forma parte de un
Activo de servicio y proceso de gestión de la configuración.
Atributo (Transición del servicio) Información sobre un elemento de configuración.

Algunos ejemplos son: nombre, ubicación, número de versión y costo. Atributos de
Los CI se registran en la base de datos de gestión de la configuración (CMDB).
Consulte también Relación.
Auditoría Inspección y verificación formales para verificar si una Norma o un conjunto de

Se siguen las pautas, que los registros son precisos o que
Se están cumpliendo los objetivos de eficiencia y eficacia. Una auditoría puede ser
realizadas por grupos internos o externos. Ver también Certificación,
Evaluación.
Página 364
Llamada automática (Operación del servicio) Uso de la tecnología de la información para dirigir un
Distribución llamada telefónica a la persona más adecuada en el menor tiempo posible
hora. A ACD a veces se le llama distribución automatizada de llamadas.
Disponibilidad (Diseño de servicio) Capacidad de un elemento de configuración o servicio de TI para realizar

su Función acordada cuando sea necesario. La disponibilidad está determinada por
Fiabilidad, mantenibilidad, facilidad de servicio, rendimiento y seguridad.
La disponibilidad generalmente se calcula como un porcentaje. Este cálculo es a menudo
basado en el tiempo de servicio acordado y el tiempo de inactividad. Es una buena práctica
calcular la disponibilidad utilizando mediciones de la producción comercial de la
Servicio de TI.
Disponibilidad (Diseño de Servicio) El Proceso responsable de definir, analizar,

administración Planificación, medición y mejora de todos los aspectos de la disponibilidad de TI.
servicios. La gestión de disponibilidad es responsable de garantizar que todos los equipos de TI
La infraestructura, los procesos, las herramientas, los roles, etc.son apropiados para el
objetivos de nivel de servicio acordados para la disponibilidad.
Disponibilidad (Diseño de servicio) Un repositorio virtual de todos los datos de gestión de disponibilidad,
administración generalmente almacenado en múltiples ubicaciones físicas. Consulte también Conocimientos sobre el servicio
Sistema de informacion Sistema de gestión.
Plan de disponibilidad (Diseño de servicio) Un plan para garantizar que la disponibilidad actual y futura
Los requisitos para los servicios de TI se pueden proporcionar de forma rentable.
Retirarse Ver remediación.
Respaldo (Diseño del servicio) (Operación del servicio) Copia de datos para proteger contra
pérdida de integridad o disponibilidad del original.
Cuadro de mando integral (mejora continua del servicio) Una herramienta de gestión desarrollada por los Dres.
Robert Kaplan (Harvard Business School) y David Norton. Un equilibrado
El cuadro de mando permite desglosar una estrategia en rendimiento clave
Indicadores. El rendimiento frente a los KPI se utiliza para demostrar cómo
Bueno, la Estrategia se está logrando. Un Cuadro de Mando Integral tiene cuatro
áreas principales, cada una de las cuales tiene una pequeña cantidad de KPI. Los mismos cuatro
Las áreas se consideran en diferentes niveles de detalle a lo largo de la
Organización.
Base (Mejora continua del servicio) Un punto de referencia utilizado como referencia
punto. Por ejemplo:
• Una línea de base ITSM se puede utilizar como punto de partida

punto para medir el efecto de un servicio
Plan de mejora
• Se puede utilizar una línea de base de rendimiento para
medir los cambios en el rendimiento a lo largo del
vida útil de un servicio de TI
• Una línea de base de gestión de la configuración se puede
utilizado para permitir que la infraestructura de TI sea
restaurado a una configuración conocida si un cambio o
La liberación falla.
Punto de referencia (Mejora continua del servicio) El estado registrado de algo en un
Página 365
punto específico en el tiempo. Se puede crear un Benchmark para una Configuración, un

Proceso, o cualquier otro conjunto de datos. Por ejemplo, un punto de referencia puede ser
utilizado en:
• Mejora continua del servicio, para establecer la

estado actual para la gestión de mejoras
• Gestión de capacidad, para documentar
características de rendimiento durante normal
operaciones.
Consulte también Benchmarking, Baseline.
Benchmarking (Mejora continua del servicio) Comparación de un punto de referencia con un

Línea de base o con las mejores prácticas. El término Benchmarking también se utiliza para
significa crear una serie de puntos de referencia a lo largo del tiempo y comparar los
resultados para medir el progreso o la mejora.
Mejores prácticas Actividades o procesos comprobados que han sido utilizados con éxito por
múltiples Organizaciones. ITIL es un ejemplo de mejores prácticas.
Lluvia de ideas (Diseño de servicios) Una técnica que ayuda a un equipo a generar ideas. Ideas
no se revisan durante la sesión de lluvia de ideas, sino en una etapa posterior.
La gestión de problemas suele utilizar la lluvia de ideas para identificar posibles
causas.
Presupuesto Una lista de todo el dinero que una organización o unidad de negocios planea recibir,
y planea pagar, durante un período de tiempo específico. Ver también
Elaboración de presupuestos, planificación.
Presupuesto La actividad de predecir y controlar el gasto de dinero.

Consiste en un ciclo de negociación periódica para establecer presupuestos futuros (generalmente
anual) y el seguimiento y ajuste diario de los Presupuestos vigentes.
Construir (Transición del servicio) La actividad de ensamblar una serie de

Elementos de configuración para crear parte de un servicio de TI. El término Construir también es
se utiliza para hacer referencia a una versión autorizada para su distribución. Por ejemplo
Compilación de servidor o compilación de computadora portátil. Consulte también Configuración de línea base.
Negocio (Estrategia de servicio) Una entidad corporativa u organización general formada por un
número de Unidades de Negocio. En el contexto de ITSM, el término Negocios
incluye el sector público y organizaciones sin fines de lucro, así como
empresas. Un proveedor de servicios de TI proporciona servicios de TI a un cliente
dentro de una empresa. El proveedor de servicios de TI puede ser parte del mismo
Negocio como su Cliente (proveedor de servicios internos), o como parte de otro
Empresa (proveedor de servicios externo).
Capacidad empresarial (Diseño de servicios) En el contexto de ITSM, Gestión de la capacidad empresarial

administración es la Actividad responsable de comprender los negocios futuros
Requisitos para su uso en el Plan de capacidad. Ver también Capacidad de servicio
Gestión .
Caso de negocio (Estrategia de servicio) Justificación de un gasto significativo.

Incluye información sobre costos, beneficios, opciones, problemas, riesgos y
Posibles problemas. Consulte también Análisis de costes y beneficios.
Continuidad del negocio (diseño del servicio) El proceso empresarial responsable de gestionar los riesgos.
Página 366
administración que podría afectar gravemente al negocio. BCM salvaguarda los intereses de
partes interesadas clave, reputación, marca y actividades de creación de valor. los
El proceso BCM implica reducir los riesgos a un nivel aceptable y
planificación para la recuperación de los procesos de negocio en caso de que se produzca una interrupción
el negocio ocurra. BCM establece los objetivos, el alcance y los requisitos
para la gestión de la continuidad del servicio de TI.
Continuidad del negocio (Diseño de servicio) Un plan que define los pasos necesarios para restaurar el negocio.
Plan Procesos posteriores a una interrupción. El plan también identificará los desencadenantes
para Invocación, personas involucradas, comunicaciones, etc. Servicio de TI
Los planes de continuidad forman una parte importante de los planes de continuidad del negocio.
Cliente comercial (estrategia de servicio) Un destinatario de un producto o un servicio del
Negocio. Por ejemplo,
Cliente comercial si la empresa
es alguien es ununfabricante
que compra de automóviles, la
automóvil.
Impacto de negocios (Estrategia de servicio) BIA es la actividad en la gestión de la continuidad del negocio
Análisis que identifica Vital Business Functions y sus dependencias. Estos
Las dependencias pueden incluir Proveedores, personas, otros Procesos comerciales,
Servicios de TI, etc. BIA define los requisitos de recuperación para los Servicios de TI.
Estos requisitos incluyen Objetivos de tiempo de recuperación, Punto de recuperación
Objetivos y metas de nivel de servicio mínimo para cada Servicio de TI.
Objetivo de negocio (Estrategia de servicio) El objetivo de un proceso empresarial, o del

Negocio en su conjunto. Los objetivos comerciales apoyan la visión comercial,
proporcionan orientación para la estrategia de TI y, a menudo, cuentan con el apoyo de TI
Servicios.
Negocio (Estrategia de servicio) La ejecución, el seguimiento y la

Operaciones gestión de Procesos de Negocio.
Negocio (Mejora continua del servicio) Comprensión del servicio

Perspectiva proveedor y Servicios de TI desde el punto de vista del Negocio, y un
Comprensión del Negocio desde el punto de vista del Servicio.
proveedor.
Procesos de negocio Un proceso que es propiedad y es llevado a cabo por la empresa. Un negocio
El proceso contribuye a la entrega de un producto o servicio a una empresa.
Cliente. Por ejemplo, un minorista puede tener un proceso de compra que
ayuda a prestar servicios a sus clientes comerciales. Muchos negocios
Los procesos dependen de los servicios de TI.
Negocio (Estrategia de servicio) El proceso o función responsable de mantener un

Relación Relación con la empresa. Gestión de relaciones comerciales
administración generalmente incluye:
• Gestión de relaciones personales con empresas

gerentes
• Proporcionar información para la gestión de la cartera de servicios
• Asegurarse de que el proveedor de servicios de TI
satisfaciendo las necesidades comerciales de los clientes
Este proceso tiene fuertes vínculos con la gestión del nivel de servicio.
Servicio empresarial Un servicio de TI que respalda directamente un proceso empresarial, en lugar de
Página 367
un servicio de infraestructura, que es utilizado internamente por el servicio de TI

proveedor y no suele ser visible para la empresa.
El término Servicio comercial también se utiliza para referirse a un Servicio que

entregado a Clientes Comerciales por Unidades de Negocio. Por ejemplo,
prestación de servicios financieros a Clientes de un banco, o bienes al
Clientes de una tienda minorista. Entrega exitosa de servicios comerciales
a menudo depende de uno o más servicios de TI.
Servicio empresarial (Estrategia de servicio) (Diseño de servicio) Un enfoque para la gestión de

administración Servicios de TI que consideran los Procesos de Negocio soportados y el
Valor comercial proporcionado.
Este término también significa la gestión de los Servicios comerciales prestados a

Clientes comerciales.
Unidad de negocio (Estrategia de servicio) Un segmento del negocio que tiene sus propios planes,
Métricas, ingresos y costos. Cada Unidad de Negocio posee Activos y utiliza
estos para crear valor para los Clientes en forma de bienes y Servicios.
Llamada (Operación del servicio) Una llamada telefónica a la mesa de servicio de un usuario. A
La llamada podría dar lugar a que se registre un incidente o una solicitud de servicio.
Centro de llamadas (Operación de servicio) Una organización o unidad de negocios que maneja grandes
números de llamadas telefónicas entrantes y salientes. Ver también Servicio
Escritorio.
Capacidad (Estrategia de servicio) La capacidad de una organización, persona, proceso,

Aplicación, Elemento de Configuración o Servicio de TI para realizar una Actividad.
Las capacidades son activos intangibles de una organización. Ver también
Recurso.
Capacidad (Diseño de servicio) El rendimiento máximo que un elemento de configuración o

El servicio de TI puede cumplir con los objetivos de nivel de servicio acordados. Para
algunos tipos de CI, la capacidad puede ser el tamaño o el volumen, por ejemplo, un
disco duro.
Capacidad (Diseño del servicio) El proceso responsable de garantizar que la capacidad

administración de los servicios de TI y la infraestructura de TI es capaz de brindar el servicio acordado
objetivos de nivel de manera rentable y oportuna. Capacidad
La gerencia considera todos los recursos necesarios para brindar el servicio de TI,
y planes para Requerimientos Comerciales a corto, mediano y largo plazo.
Capacidad (Diseño de servicio) Un repositorio virtual de todos los datos de Gestión de capacidad,
administración generalmente almacenado en múltiples ubicaciones físicas. Consulte también Conocimientos sobre el servicio
Sistema de informacion Sistema de gestión.
Plan de capacidad (Diseño de servicio) Se utiliza un plan de capacidad para administrar los recursos
necesarios para prestar servicios de TI. El Plan contiene escenarios para diferentes
predicciones de la demanda empresarial y opciones de costos para entregar el
objetivos de nivel de servicio acordados.
Planificación de capacidad (Diseño de servicios) La actividad dentro de la gestión de la capacidad responsable

para crear un plan de capacidad.
Categoría Un grupo con nombre de cosas que tienen algo en común. Categorias
Página 368
se utilizan para agrupar cosas similares. Por ejemplo, los tipos de costo son
se utiliza para agrupar tipos similares de costo. Las categorías de incidentes se utilizan para
agrupar tipos similares de incidentes, los tipos de CI se utilizan para agrupar tipos similares
del elemento de configuración.
Certificación Emitir un certificado para confirmar el cumplimiento de un estándar. Certificación

incluye una Auditoría formal por parte de un organismo independiente y acreditado. los
El término Certificación también se utiliza para significar la concesión de un certificado para verificar
que una persona ha logrado una calificación.
Cambio (Transición del servicio) La adición, modificación o eliminación de cualquier cosa

que podría tener un efecto en los servicios de TI. El alcance debe incluir todas las TI
Servicios, elementos de configuración, procesos, documentación, etc.
Aviso de cambio (Transición del servicio) Un grupo de personas que asesora al Administrador de cambios
Junta en la Evaluación, priorización y programación de Cambios. Este tablero
generalmente está compuesto por representantes de todas las áreas dentro del Servicio de TI
proveedor, representantes de la Empresa y Terceros como
Proveedores.
cambia la historia (Transición del servicio) Información sobre todos los cambios realizados en un
Elemento de configuración durante su vida. El historial de cambios consta de todos aquellos
Cambie los registros que se aplican al elemento de configuración.
Cambio (Transición del servicio) El proceso responsable de controlar el ciclo de vida

administración de todos los cambios. El objetivo principal de la Gestión del Cambio es
Permitir que se realicen cambios beneficiosos, con una interrupción mínima de TI
Servicios.
Solicitud de cambio Consulte Solicitud de cambio.
Cambiar horario (Transición del servicio) Un documento que enumera todos los cambios y
sus fechas de implementación planificadas. Un horario de cambio es a veces
denominada Programación de cambios futuros, aunque también contiene
información sobre los cambios que ya se han implementado.
Cambiar ventana (Transición del servicio) Un momento regular y acordado en el que los cambios o las versiones
puede implementarse con un impacto mínimo en los Servicios. Cambiar ventanas
generalmente se documentan en SLA.
Cargando (Estrategia de servicio) Exigir el pago de los servicios de TI. Cobrando por TI
Los servicios son opcionales y muchas organizaciones optan por tratar su TI
Proveedor de servicios como centro de costos.
Clasificación El acto de asignar una categoría a algo. La clasificación se utiliza para

Asegurar una gestión y presentación de informes coherentes. IC, incidentes, problemas,
Los cambios, etc. generalmente se clasifican.
Cliente Un término genérico que significa un Cliente, la Empresa o una Empresa.

Cliente. Por ejemplo, Client Manager puede usarse como sinónimo de
Gerente de cuentas.
El término cliente también se usa para significar:
• Una computadora que es utilizada directamente por un Usuario, para

ejemplo, una PC, computadora de mano o
Página 369
Puesto de trabajo
• La parte de una aplicación cliente-servidor que el
El usuario interactúa directamente con. Por ejemplo, un e-
Cliente de correo.
Cerrado (Operación del servicio) El estado final en el ciclo de vida de un incidente,

Problema, cambio, etc. Cuando el estado está cerrado, no se realizan más acciones.
tomado.
Cierre (Operación del servicio) El acto de cambiar el estado de un incidente,

Problema, cambio, etc. a cerrado.
COBIT (Mejora continua del servicio) Objetivos de control para la información y

Tecnología relacionada (COBIT) proporciona orientación y mejores prácticas para la
Gestión de Procesos de TI. COBIT es publicado por el Gobierno de TI
Instituto. Visite www.isaca.org para obtener más información.
Espera fría Consulte Recuperación gradual.
Comercial Off (Diseño de servicios) Software de aplicación o Middleware que se puede

El estante comprado a un tercero.
Cumplimiento Asegurarse de que se siga un Estándar o un conjunto de Directrices, o que
se están empleando prácticas contables u otras prácticas coherentes.
Componente Un término general que se usa para significar una parte de algo más
complejo. Por ejemplo, un sistema informático puede ser un componente de una TI.
Servicio, una Aplicación puede ser un Componente de una Unidad de Liberación.
Los componentes que deben administrarse deben ser elementos de configuración.
Componente (Diseño del servicio) (Mejora continua del servicio) El proceso

Capacidad responsable de comprender la capacidad, la utilización y el rendimiento
administración de elementos de configuración. Los datos se recopilan, registran y analizan para su uso
en el Plan de capacidad. Consulte también Gestión de la capacidad del servicio .
Componente CI (Transición de servicio) Un elemento de configuración que forma parte de un ensamblado. Para
Por ejemplo, una CPU o un CI de memoria pueden ser parte de un CI de servidor.
Fallo de componente (Diseño de servicios) Una técnica que ayuda a identificar el impacto de CI
Análisis de impacto falla en los servicios de TI. Se crea una matriz con servicios de TI en un borde
y CI en el otro. Esto permite la identificación de CI críticos (que
podría causar la falla de varios servicios de TI) y de servicios de TI frágiles
(que tienen múltiples puntos únicos de falla).
Concurrencia Una medida del número de usuarios que participan en la misma operación en el
Mismo tiempo.
Confidencialidad (Diseño de servicio) Un principio de seguridad que requiere que los datos solo
Ser accedido por personas autorizadas.
Configuración (Transición de servicio) Término genérico que se utiliza para describir un grupo de
Elementos de configuración que trabajan juntos para brindar un servicio de TI, o un
parte reconocible de un servicio de TI. La configuración también se utiliza para describir
la configuración de los parámetros para uno o más CI.
Página 370
Configuración (Transición del servicio) Una línea de base de una configuración que ha sido formalmente
Base acordado y se gestiona a través del proceso de Gestión del Cambio. A
La línea de base de configuración se utiliza como base para futuras compilaciones, versiones y
Cambios.
Configuración (Transición del servicio) La actividad responsable de garantizar que la adición,

Control la modificación o eliminación de un elemento de configuración se gestiona correctamente, por ejemplo,
enviar una solicitud de cambio o solicitud de servicio.
Configuración (Transición del servicio) La actividad responsable de recopilar información

Identificación sobre los elementos de configuración y sus relaciones, y cargando este
información en la CMDB. La identificación de la configuración también es
responsable de etiquetar los propios EC, de modo que el correspondiente
Se pueden encontrar registros de configuración.
Elemento de configuración (Transición del servicio) Cualquier componente que deba gestionarse para
para entregar un servicio de TI. La información sobre cada CI se registra en un
Registro de configuración dentro del sistema de gestión de la configuración y
se mantiene durante todo su ciclo de vida mediante la gestión de la configuración. CI
están bajo el control de Change Management. Los CI suelen incluir TI
Servicios, hardware, software, edificios, personas y formales
documentación como la documentación del proceso y los SLA.
Configuración (Transición del servicio) El proceso responsable de mantener la información

administración sobre los elementos de configuración necesarios para prestar un servicio de TI, incluidos
sus relaciones. Esta información se gestiona durante todo el ciclo de vida
de la CI. La gestión de la configuración es parte de un activo general del servicio
y proceso de gestión de la configuración.
Configuración (Transición del servicio) Un conjunto de herramientas y bases de datos que se utilizan para
administración administrar los datos de configuración de un proveedor de servicios de TI. El CMS también
Sistema incluye información sobre incidentes, problemas, errores conocidos, cambios
y lanzamientos; y puede contener datos sobre empleados, proveedores,
Ubicaciones, Unidades de Negocio, Clientes y Usuarios. El CMS incluye
herramientas para recopilar, almacenar, administrar, actualizar y presentar datos
sobre todos los elementos de configuración y sus relaciones. El CMS es
mantenido por Configuration Management y es utilizado por todos los servicios de TI
Procesos de gestión. Consulte también Gestión del conocimiento del servicio
Sistema.
Servicio continuo (Mejora continua del servicio) Una etapa en el ciclo de vida de una TI
Mejora Servicio y el título de una de las publicaciones de Core ITIL. Continuo
Service Improvement es responsable de gestionar las mejoras de TI.
Procesos de gestión de servicios y servicios de TI. El rendimiento de
el proveedor de servicios de TI se mide continuamente y se mejoran
realizados a Procesos, Servicios de TI e Infraestructura de TI con el fin de aumentar
Eficiencia, eficacia y rentabilidad. Consulte también Planificar – Hacer–
Verificar – Actuar.
Continuo (Diseño de servicio) Un enfoque o diseño para lograr el 100% de disponibilidad. A

Disponibilidad El servicio de TI continuamente disponible no tiene planificado o no planificado
Falta del tiempo.
Continuo (Diseño de servicio) Un enfoque o diseño para eliminar el tiempo de inactividad planificado
Operación de un servicio de TI. Tenga en cuenta que los elementos de configuración individuales pueden estar inactivos
aunque el Servicio de TI esté disponible.
Página 371
Contrato Un acuerdo legalmente vinculante entre dos o más partes.
Control Un medio de gestionar un riesgo, asegurando que un objetivo empresarial es

logrado, o asegurarse de que se sigue un proceso. Controles de ejemplo
incluir políticas, procedimientos, roles, RAID, cerraduras de puertas, etc.
a veces denominada contramedida o salvaguardia. Control también significa
para gestionar la utilización o el comportamiento de un elemento de configuración, sistema o
Servicio de TI.
Perspectiva de control (estrategia de servicio) Un enfoque para la gestión de servicios de TI,

Procesos, funciones, activos, etc. Puede haber varios controles diferentes
Perspectivas sobre el mismo Servicio, Proceso, etc. de TI, permitiendo diferentes
individuos o equipos para centrarse en lo que es importante y relevante para sus
Rol específico. Ejemplos de perspectivas de control incluyen reactivo y
Gestión proactiva dentro de las operaciones de TI o una vista del ciclo de vida para un
Equipo de proyecto de aplicación.
Costo La cantidad de dinero gastada en una Actividad, Servicio de TI o

Unidad de negocio. Los costos consisten en el costo real (dinero), el costo teórico como
tiempo de las personas y depreciación.
Coste-beneficio Una actividad que analiza y compara los costos y los beneficios
Análisis involucrado en uno o más cursos de acción alternativos. Ver también Negocios
Caso, retorno de la inversión.
Rentabilidad Una medida del equilibrio entre la eficacia y el costo de un

Servicio, proceso o actividad. Un proceso rentable es aquel que
logra sus Objetivos al mínimo Costo. Consulte también KPI, Retorno de
Inversión, Valor por Dinero .
Contramedida Puede usarse para referirse a cualquier tipo de Control. El término Contramedida es
se utiliza con más frecuencia cuando se hace referencia a medidas que aumentan la resiliencia,
Tolerancia a fallas o confiabilidad de un servicio de TI.
Gestión de crisis (Gestión de la continuidad del servicio de TI) La gestión de crisis es el proceso
responsable de gestionar las implicaciones más amplias de la continuidad del negocio.
Un equipo de gestión de crisis es responsable de cuestiones estratégicas como
gestionar las relaciones con los medios y la confianza de los accionistas, y decide
cuándo invocar planes de continuidad del negocio.
Éxito crítico Algo que debe suceder si un proceso, proyecto, plan o servicio de TI es
Factor para triunfar. Los KPI se utilizan para medir el logro de cada CSF.
Por ejemplo, un CSF de 'proteger los servicios de TI al realizar cambios' podría
ser medidos por KPI como 'reducción porcentual de fallidos
Cambios ',' reducción porcentual de Cambios que provocan Incidencias ', etc.
Cultura Un conjunto de valores que comparte un grupo de personas, que incluye

expectativas sobre cómo deben comportarse las personas, sus ideas, creencias y
prácticas. Consulte también Visión .
Cliente Alguien que compra bienes o servicios. El cliente de un servicio de TI

proveedor es la persona o grupo que define y acepta el nivel de servicio
objetivos. El término Clientes también se usa a veces de manera informal para significar
Usuarios, por ejemplo, "esta es una organización centrada en el cliente".
Tablero (Operación del servicio) Una representación gráfica del servicio de TI general
Página 372
Rendimiento y disponibilidad. Las imágenes del tablero pueden actualizarse en formato real.
tiempo, y también se puede incluir en informes de gestión y páginas web.
Los paneles se pueden utilizar para respaldar la gestión del nivel de servicio, eventos
Manejo o Diagnóstico de Incidencias.
Entregables Algo que se debe brindar para cumplir con un compromiso en un Servicio
Acuerdo de nivel o contrato. El entregable también se utiliza en una
forma informal para significar un resultado planificado de cualquier proceso.
Demanda Actividades que comprenden e influyen en la demanda de Servicios por parte del Cliente
administración y la provisión de capacidad para satisfacer estas demandas. En un estratégico
La gestión de la demanda a nivel puede implicar el análisis de patrones de negocio.
Actividad y perfiles de usuario. A nivel táctico, puede implicar el uso de
Cargo diferencial para alentar a los clientes a utilizar los servicios de TI a menos
tiempos ocupados. Consulte también Gestión de la capacidad.
Dependencia La dependencia directa o indirecta de un proceso o actividad en otro.
Despliegue (Transición del servicio) La actividad responsable del movimiento de nuevos o

cambiado hardware, software, documentación, proceso, etc. a Live
Ambiente. La implementación es parte de la versión y la implementación
Proceso de gestión.
Diseño (Diseño de servicio) Una actividad o proceso que identifica los requisitos y
luego define una solución que puede cumplir con estos requisitos. Ver
también Diseño de Servicios .
Detección (Operación del servicio) Una etapa en el ciclo de vida del incidente. La detección da como resultado
el Incidente sea conocido por el Proveedor del Servicio. La detección puede ser
automático, o puede ser el resultado de un usuario que registra un incidente.
Desarrollo (Diseño de servicio) El proceso responsable de crear o modificar una TI.

Servicio o Aplicación. También se usa para referirse al rol o grupo que lleva
trabajo de desarrollo.
Desarrollo (Diseño de servicio) Un entorno utilizado para crear o modificar Servicios de TI o

Ambiente Aplicaciones. Los entornos de desarrollo no suelen estar sujetos a
el mismo grado de control que los entornos de prueba o los entornos en vivo.
Consulte también Desarrollo.
Diagnóstico (Operación del servicio) Una etapa en los ciclos de vida de incidentes y problemas. los
El propósito del diagnóstico es identificar una solución alternativa para un incidente o
Causa raíz de un problema.
Diferencial Una técnica utilizada para respaldar la gestión de la demanda mediante el cobro de diferentes
Cargando importes para la misma función de servicio de TI en diferentes momentos.
Documento Información en forma legible. Un documento puede ser en papel o electrónico.

Por ejemplo, una declaración de política, un acuerdo de nivel de servicio, un incidente
Registro, diagrama de distribución de la sala de ordenadores. Consulte también Grabar.
Falta del tiempo (Diseño del servicio) (Operación del servicio) El momento en que una configuración
El artículo o servicio de TI no está disponible durante el tiempo de servicio acordado. los
La disponibilidad de un servicio de TI a menudo se calcula a partir del tiempo de servicio acordado
y tiempo de inactividad.
Conductor Algo que influya en Estrategia, Objetivos o Requisitos. Para
Página 373
ejemplo, nueva legislación o acciones de competidores.
Economías de escala (estrategia de servicio) La reducción del costo promedio que es posible
aumentar el uso de un activo o servicio de TI.
Eficacia (Mejora continua del servicio) Una medida de si los Objetivos

de un Proceso, Servicio o Actividad. Una efectiva
El proceso o actividad es aquel que logra sus Objetivos acordados. Ver también
KPI.
Eficiencia (Mejora continua del servicio) Una medida de si la cantidad correcta

de recursos se ha utilizado para entregar un Proceso, Servicio o Actividad. Un
Efficient Process logra sus objetivos con la mínima cantidad de
tiempo, dinero, personas u otros recursos. Consulte también KPI.
Ambiente (Transición del servicio) Un subconjunto de la infraestructura de TI que se utiliza para una
Propósito particular. Por ejemplo: Live Environment, Test Environment,
Entorno de construcción. Es posible que varios entornos compartan un
Elemento de configuración, por ejemplo, los entornos de prueba y en vivo pueden usar
diferentes particiones en una sola computadora central. También se utiliza en el
término Entorno físico para significar el alojamiento, aire acondicionado,
sistema de energía, etc.
El medio ambiente también se utiliza como término genérico para referirse a la

condiciones que influyen o afectan algo.
Error (Operación de servicio) Un defecto de diseño o mal funcionamiento que causa una falla
uno o más elementos de configuración o servicios de TI. Un error cometido por un
persona o un Proceso defectuoso que afecte a un CI o Servicio de TI también es un Error.
Escalada (Operación de servicio) Una actividad que obtiene recursos adicionales cuando
estos son necesarios para cumplir con los objetivos de nivel de servicio o
Expectativas. Es posible que sea necesario escalar dentro de cualquier servicio de TI
Proceso de gestión, pero se asocia más comúnmente con el incidente.
Gestión, gestión de problemas y gestión de clientes
quejas.
EscaladaHay dos tipos de escalada, escalada funcional y
jerárquica.
eSourcing (Estrategia de servicio) Un marco para ayudar a los proveedores de servicios de TI a desarrollar sus
Modelo de capacidad para Capacidades de gestión de servicios de TI a partir de una contratación de servicios
Proveedores de servicio perspectiva. eSCM – SP fue desarrollado por Carnegie Mellon University,
NOSOTROS.
Estimacion El uso de la experiencia para proporcionar un valor aproximado de una métrica o

Costo. La estimación también se utiliza en la gestión de la capacidad y la disponibilidad.
como el método de modelado más barato y menos preciso.
Evaluación (Transición del servicio) El proceso responsable de evaluar un nuevo o

Se modificó el servicio de TI para garantizar que los riesgos se hayan gestionado y
ayudar a determinar si se debe continuar con el cambio.
La evaluación también se usa para significar comparar un Resultado real con el

Resultado previsto, o comparar una alternativa con otra.
Evento (Operación del servicio) Un cambio de estado que tiene importancia para el
Página 374
gestión de un elemento de configuración o servicio de TI.
El término Evento también se usa para referirse a una Alerta o notificación creada por
cualquier servicio de TI, elemento de configuración o herramienta de supervisión. Eventos típicamente
requieren que el personal de operaciones de TI tome medidas y, a menudo,
Se registran incidentes.
Gestión de eventos (Operación del servicio) El proceso responsable de la gestión de eventos

a lo largo de su ciclo de vida. La gestión de eventos es una de las principales
Actividades de las operaciones de TI.
Informe de excepciones Un documento que contiene detalles de uno o más KPI u otro importante
objetivos que han superado los umbrales definidos. Los ejemplos incluyen SLA
objetivos que no se cumplen o están a punto de perderse, y una métrica de rendimiento
indica un problema de capacidad potencial.
Incidente ampliado (Gestión de la disponibilidad) Etapas detalladas en el ciclo de vida de un incidente.

Ciclo vital Las etapas son Detección, Diagnóstico, Reparación, Recuperación, Restauración. los
El ciclo de vida ampliado de incidentes se utiliza para ayudar a comprender todas las contribuciones
al impacto de los incidentes y planificar cómo se podrían controlar o
reducido.
Servicio externo (Estrategia de servicio) Un proveedor de servicios de TI que forma parte de un

proveedor Organización a su Cliente. Un proveedor de servicios de TI puede tener ambos
Clientes internos y clientes externos.
Abastecimiento externo Ver subcontratación.
Instalaciones (Operación del servicio) La función responsable de administrar el

administración Entorno donde se ubica la Infraestructura de TI. Instalaciones
La gestión incluye todos los aspectos de la gestión del entorno físico,
por ejemplo, energía y refrigeración, gestión de acceso a edificios y
monitoreo ambiental.
Falla (Operación del servicio) Pérdida de capacidad para operar según la especificación, o para
entregar la salida requerida. El término Falla se puede usar al referirse
a los servicios de TI, procesos, actividades, elementos de configuración, etc.
a menudo causa un incidente.
Rápida recuperación (Diseño de servicio) Una opción de recuperación que también se conoce como Hot Standby.
Se prevé la Recuperación del Servicio de TI en un corto período de tiempo:
normalmente menos de 24 horas. La recuperación rápida suele utilizar un
Instalación fija con sistemas informáticos y software configurado listo para
ejecutar los servicios de TI. La recuperación rápida puede tardar hasta 24 horas si hay una
necesita restaurar los datos de las copias de seguridad.
Culpa Ver error.
Tolerancia a fallos (Diseño de servicio) La capacidad de un elemento de configuración o servicio de TI para

continúe funcionando correctamente después de la falla de una pieza del componente. Ver también
Resiliencia, contramedida.
Análisis del árbol de fallos (Diseño de servicio) (Mejora continua del servicio) Una técnica que puede
utilizarse para determinar la cadena de eventos que conduce a un problema. Culpa
El análisis de árbol representa una cadena de eventos usando notación booleana en un
diagrama.
Página 375
Financiero (Estrategia de servicio) La función y los procesos responsables de

administración Gestión de presupuestos, contabilidad y facturación de un proveedor de servicios de TI.
Requerimientos.
Adecuado para el propósito Término informal utilizado para describir un proceso, elemento de configuración, TI
Servicio, etc. que sea capaz de cumplir sus objetivos o niveles de Servicio.
Ser apto para un propósito requiere un diseño, implementación y control adecuados
y mantenimiento.
Cumplimiento Realización de actividades para satisfacer una necesidad o requisito. Por ejemplo, por
proporcionar un nuevo servicio de TI o satisfacer una solicitud de servicio.
Función Un equipo o grupo de personas y las herramientas que utilizan para llevar a cabo una o
más Procesos o Actividades. Por ejemplo, el Service Desk.
El término función también tiene otros dos significados:
• Un propósito previsto de un elemento de configuración,

Persona, equipo, proceso o servicio de TI. Para
ejemplo, una función de un servicio de correo electrónico puede
ser para almacenar y reenviar correos salientes, uno
La función de un proceso empresarial puede ser
enviar mercancías a los Clientes.
• Para realizar correctamente el propósito previsto, 'El
la computadora está funcionando '.
Gobernancia Asegurar que las políticas y la estrategia se implementen realmente, y que

Los procesos requeridos se siguen correctamente. La gobernanza incluye definir
Funciones y responsabilidades, medición y presentación de informes y adopción de medidas
para resolver cualquier problema identificado.
Recuperación gradual (Diseño de servicio) Una opción de recuperación que también se conoce como Cold Standby.
Se hace provisión para Recuperar el Servicio de TI en un período de tiempo mayor
de 72 horas. La recuperación gradual suele utilizar un dispositivo portátil o fijo.
Instalación que tiene soporte ambiental y cableado de red, pero no
Sistemas informáticos. El hardware y el software se instalan como parte de
el Plan de continuidad del servicio de TI.
Guía Un documento que describe las mejores prácticas, que recomienda lo que debería
estar hecho. Normalmente no se hace cumplir una directriz. Ver también
Estándar.
Alta disponibilidad (Diseño de servicio) Un enfoque o diseño que minimiza u oculta la

efectos de la falla del elemento de configuración en los usuarios de un servicio de TI. Alto
Las soluciones de disponibilidad están diseñadas para lograr un nivel acordado de
Disponibilidad y uso de técnicas como Fault Tolerance,
Resiliencia y recuperación rápida para reducir el número de incidentes y la
Impacto de los incidentes.
Espera en caliente Consulte Recuperación rápida o Recuperación inmediata.
Recuperación inmediata (diseño de servicio) Una opción de recuperación que también se conoce como Hot Standby.
Se hace una disposición para recuperar el servicio de TI sin pérdida de servicio.
La recuperación inmediata suele utilizar duplicación, equilibrio de carga y división.
Página 376
Tecnologías del sitio.
Impacto (Operación del servicio) (Transición del servicio) Una medida del efecto de un
Incidencia, problema o cambio en los procesos comerciales. El impacto es a menudo
en función de cómo se verán afectados los niveles de servicio. El impacto y la urgencia son
utilizado para asignar prioridad.
Incidente (Operación del servicio) Una interrupción no planificada de un servicio de TI o

Reducción de la Calidad de un Servicio de TI. Fallo de un elemento de configuración
que aún no ha afectado al Servicio también es un Incidente. Por ejemplo, fracaso
de un disco de un juego de espejos.
Incidente (Operación del servicio) El proceso responsable de administrar el ciclo de vida

administración de todos los Incidentes. El objetivo principal de la gestión de incidentes es
devolver el Servicio de TI a los Clientes lo antes posible.
Registro de incidentes (Operación del servicio) Un registro que contiene los detalles de un incidente. Cada
El registro de incidentes documenta el ciclo de vida de un solo incidente.
Costo indirecto (Estrategia de servicio) Un costo de proporcionar un servicio de TI, que no se puede
asignado en su totalidad a un cliente específico. Por ejemplo, el costo de
proporcionando servidores compartidos o licencias de software. También conocido como Overhead.
Seguridad de información (Diseño de Servicio) El Proceso que asegura la Confidencialidad, Integridad

administración y disponibilidad de los activos, la información, los datos y la TI de una organización
Servicios. La gestión de la seguridad de la información suele formar parte de un
Enfoque organizativo de la gestión de la seguridad que tiene un alcance más amplio
que el proveedor de servicios de TI, e incluye el manejo de papel, la construcción
acceso, llamadas telefónicas, etc., para toda la Organización.
Seguridad de información (Diseño de servicios) El marco de políticas, procesos, estándares,

administración Directrices y herramientas que garantizan que una organización pueda lograr su
Sistema Objetivos de gestión de la seguridad de la información.
Seguridad de información (Diseño de servicios) La política que rige el enfoque de la Organización para
Política Gestión de la seguridad de la información.
Información El uso de tecnología para el almacenamiento, comunicación o procesamiento de

Tecnología información. La tecnología generalmente incluye computadoras,
telecomunicaciones, aplicaciones y otro software. La información
puede incluir datos comerciales, voz, imágenes, video, etc. Información
La tecnología se utiliza a menudo para respaldar los procesos comerciales a través de TI.
Servicios.
Infraestructura Un servicio de TI que no es utilizado directamente por la empresa, pero que es requerido por
Servicio el proveedor
ejemplo, de servicios
servicios de TI para
de directorio, que puedan
servicios proporcionar
de nombres otros
o servicios deservicios de TI. Para
comunicación.
Insourcing Consulte Abastecimiento interno.
Integridad (Diseño de servicios) Un principio de seguridad que garantiza los datos y la configuración.
Los artículos son modificados solo por personal y actividades autorizados. Integridad
considera todas las posibles causas de modificación, incluido el software y
Falla de hardware, eventos ambientales e intervención humana.
Intermedio (Diseño de servicio) Una opción de recuperación que también se conoce como Warm
Recuperación Apoyar. Se hace provisión para recuperar el servicio de TI en un período de tiempo
Página 377
entre 24 y 72 horas. La recuperación intermedia normalmente utiliza un

Instalación portátil o fija que tiene sistemas informáticos y red
Componentes. Será necesario configurar el hardware y el software, y
será necesario restaurar los datos, como parte del Plan de continuidad del servicio de TI.
Servicio interno (Estrategia de servicio) Un proveedor de servicios de TI que forma parte del mismo
proveedor Organización como su Cliente. Un proveedor de servicios de TI puede tener ambos
Clientes internos y clientes externos.
Abastecimiento interno (Estrategia de servicio) Uso de un proveedor de servicios interno para administrar TI
Servicios.
Internacional La Organización Internacional de Normalización (ISO) es la organización mundial

Organización para mayor desarrollador de estándares. ISO es una organización no gubernamental
Estandarización que es una red de los institutos nacionales de normalización de 156 países.
Consulte www.iso.org para obtener más información sobre ISO.
ISO 9000 Un término genérico que se refiere a una serie de normas internacionales y
Directrices para los sistemas de gestión de la calidad. Visite www.iso.org para más
información. Consulte también ISO.
ISO 9001 Un estándar internacional para los sistemas de gestión de la calidad. Ver también
ISO 9000, estándar.
ISO / IEC 20000 Especificación ISO y Código de prácticas para la gestión de servicios de TI.
ISO / IEC 20000 está alineado con las mejores prácticas de ITIL.
ISO / IEC 27001 (Diseño de servicio) (Mejora continua del servicio) Especificación ISO para
Gestión de la seguridad de la información. El Código de Práctica correspondiente
es ISO / IEC 17799. Consulte también Estándar.
Esa infraestructura Todo el hardware, software, redes, instalaciones, etc.que se requieren para
desarrollar, probar, entregar, monitorear, controlar o dar soporte a los servicios de TI. El término
La infraestructura de TI incluye toda la tecnología de la información, pero no la
personas asociadas, Procesos y documentación.
Operaciones de TI (Operación del servicio) Actividades realizadas por el Control de operaciones de TI,
incluida la gestión de la consola, la programación de trabajos, la copia de seguridad y la restauración,
y Gestión de impresiones y salidas. Las operaciones de TI también se utilizan como
sinónimo de operación de servicio.
Servicio de TI Un 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 Tecnología de la Información y
apoya los procesos comerciales del cliente. Se compone un servicio informático
de una combinación de personas, procesos y tecnología y debe ser
definido en un Acuerdo de nivel de servicio.
Servicio de TI (Diseño del servicio) El proceso responsable de gestionar los riesgos que podrían
Continuidad afectar seriamente a los Servicios de TI. ITSCM garantiza que el proveedor de servicios de TI
administración siempre puede proporcionar niveles de servicio mínimos acordados, reduciendo el riesgo
a un nivel aceptable y planificación para la recuperación de los servicios de TI.
ITSCM debe diseñarse para respaldar la gestión de la continuidad del negocio.
Servicio de TI (Diseño de servicio) Un plan que define los pasos necesarios para recuperar uno o
Plan de continuidad más servicios de TI. El Plan también identificará los desencadenantes de la Invocación,
personas involucradas, comunicaciones, etc. La continuidad del servicio de TI
Página 378
El plan debe ser parte de un plan de continuidad comercial.
Servicio de TI La implementación y gestión de servicios de TI de calidad que cumplan

administración las necesidades del negocio. La gestión de servicios de TI es realizada por TI
Proveedores de servicios a través de una combinación adecuada de personas, procesos y
Tecnologías de la información. Consulte también Gestión de servicios .
Proveedor de servicios de TI (Estrategia de servicio) Un proveedor de servicios que proporciona servicios de TI a

Clientes internos o clientes externos.
Grupo de dirección de TI Un grupo formal que es responsable de garantizar que el negocio y la TI

Las estrategias y planes de los proveedores de servicios están estrechamente alineados. Una dirección de TI
El grupo incluye representantes senior del negocio y la TI.
Proveedor de servicio.
ITIL Un conjunto de guías de mejores prácticas para la gestión de servicios de TI. ITIL es
propiedad de la OGC y consta de una serie de publicaciones que brindan
orientación sobre la prestación de servicios de TI de calidad y sobre los procesos
e instalaciones necesarias para apoyarlos. Visite www.itil.co.uk para más
información.
Descripción del trabajo Un documento que define los roles, responsabilidades, habilidades y conocimientos
requerido por una persona en particular. Una descripción de trabajo puede incluir varios
Roles, por ejemplo los Roles de Configuration Manager y Change
El administrador puede ser realizado por una sola persona.
Programación de trabajos (Operación del servicio) Planificación y gestión de la ejecución de software

tareas que se requieren como parte de un servicio de TI. Se realiza la programación de trabajos
la gestión de operaciones de TI y, a menudo, se automatiza utilizando
herramientas de software que ejecutan tareas por lotes o en línea en momentos específicos del día,
semana, mes o año.
Desempeño clave (Diseño de servicio) (Mejora continua del servicio) Una métrica que se utiliza
Indicador para ayudar a gestionar un proceso, un servicio de TI o una actividad. Muchas métricas pueden ser
medidos, pero solo los más importantes se definen como KPI y
utilizado para gestionar activamente e informar sobre el proceso, el servicio de TI o
Actividad. Los KPI deben seleccionarse para garantizar que la eficiencia, la eficacia,
y la eficacia en función de los costos se gestionan. Consulte también Éxito crítico
Factor.
Base de conocimientos (Transición del servicio) Una base de datos lógica que contiene los datos utilizados por el
Sistema de gestión del conocimiento del servicio.
Conocimiento (Transición del servicio) El proceso responsable de recopilar, analizar,

administración almacenar y compartir conocimientos 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 también Servicio
Sistema de gestión del conocimiento.
Error conocido (Operación del servicio) Un problema que tiene una causa raíz documentada y un
Solución alterna. Los errores conocidos se crean y gestionan a lo largo de su
Ciclo de vida por gestión de problemas. También se pueden identificar errores conocidos
por Desarrollo o Proveedores.
Ciclo vital Las diversas etapas de la vida de un servicio de TI, elemento de configuración,
Incidente, Problema, Cambio, etc. El ciclo de vida define las Categorías para
Página 379
Estado y las transiciones de estado permitidas. Por ejemplo:
• El ciclo de vida de una aplicación incluye

Requisitos, diseñar, construir, implementar, operar,
Optimizar
• El ciclo de vida ampliado de incidentes incluye
Detectar, responder, diagnosticar, reparar, recuperar,
Restaurar
• El ciclo de vida de un servidor puede incluir:
Recibido, En Prueba, Vivo, Eliminado, etc.
Linea de servicio (Estrategia de servicio) Un servicio principal o servicio de soporte que tiene múltiples
Paquetes de nivel de servicio. Una línea de servicio está gestionada por un producto
Manager y cada paquete de nivel de servicio está diseñado para admitir un
segmento de mercado particular.
Vivir (Transición de servicio) Se refiere a un elemento de configuración o servicio de TI que

que se utiliza para prestar el Servicio a un Cliente.
Entorno vivo (Transición del servicio) Un entorno controlado que contiene Live
Elementos de configuración utilizados para brindar servicios de TI a los clientes.
Mantenibilidad (Diseño de servicio) Una medida de la rapidez y eficacia de un

El elemento de configuración o el servicio de TI se pueden restaurar al funcionamiento normal después
un fracaso. La mantenibilidad a menudo se mide y se informa como MTRS.
La capacidad de mantenimiento también se utiliza en el contexto de software o servicio de TI.

Desarrollo para significar la capacidad de ser cambiado o reparado fácilmente.
Incidente mayor (Operación de servicio) La categoría de impacto más alta para un incidente. A
Un Incidente Mayor da como resultado una interrupción significativa del Negocio.
Servicios gestionados (Estrategia de servicio) Una perspectiva de los servicios de TI que enfatiza el hecho
que se gestionan. El término Servicios Gestionados también se utiliza como
sinónimo de servicios de TI subcontratados.
administración Información que se utiliza para apoyar la toma de decisiones por parte de los gerentes.
Información La información de gestión a menudo se genera automáticamente mediante herramientas.
apoyando los diversos procesos de gestión de servicios de TI. administración
La información a menudo incluye los valores de KPI como 'Porcentaje de
Cambios que conducen a incidentes ', o' tasa de reparación a la primera '.
Gestión de Riesgos La metodología OGC para la gestión de Riesgos. M_o_R incluye todos los
Actividades necesarias para identificar y controlar la exposición al riesgo, que
puede tener un impacto en el logro de los negocios de una organización
Objetivos. Visite www.mor.org para obtener más detalles.
administración El marco de Política, Procesos y Funciones que asegura una

Sistema La organización puede lograr sus objetivos.
Solución alternativa manual Una solución alternativa que requiere intervención manual. La solución manual es
también se utiliza como el nombre de una opción de recuperación en la que la empresa
El proceso funciona sin el uso de servicios de TI. Este es un temporal
medida y generalmente se combina con otra opción de recuperación.
Página 380
Madurez (Mejora continua del servicio) Una medida de confiabilidad, eficiencia

y efectividad de un proceso, función, organización, etc.
Los procesos y funciones maduros están formalmente alineados con el negocio.
Objetivos y Estrategia, y están respaldados por un marco de trabajo continuo
mejora.
Tiempo medio entre (Diseño de servicio) Una métrica para medir y reportar la confiabilidad. MTBF
Fracasos es el tiempo medio que puede realizar un elemento de configuración o un servicio de TI
su Función acordada sin interrupción. Esto se mide a partir de
El servicio de TI o CI comienza a funcionar hasta que falla la próxima vez.
Tiempo medio entre (Diseño de servicio) Métrica utilizada para medir y reportar la confiabilidad.
Incidentes de servicio MTBSI es el tiempo medio desde que falla un sistema o servicio de TI, hasta que
siguiente falla. MTBSI es igual a MTBF + MTRS.
Tiempo medio hasta El tiempo promedio que se tarda en reparar un elemento de configuración o un servicio de TI después
Reparar un fracaso. El MTTR se mide desde que falla el servicio de CI o TI hasta que
está reparado. MTTR no incluye el tiempo necesario para recuperarse o
Restaurar. MTTR a veces se usa incorrectamente para referirse al tiempo medio para
Servicio de restauración.
Tiempo medio para El tiempo promedio que se tarda en restaurar un elemento de configuración o un servicio de TI
Servicio de restauración después de una falla. MTRS se mide desde que falla el servicio de TI o CI
hasta que esté completamente restaurado y entregue su funcionalidad normal. Ver también
Mantenibilidad, tiempo medio de reparación.
Métrico (Mejora continua del servicio) Algo que se mide y

informados para ayudar a gestionar un proceso, un servicio de TI o una actividad. Consulte también KPI.
Middleware (Diseño de servicio) Software que conecta dos o más software

Componentes o aplicaciones. El middleware generalmente se compra a un
Proveedor , en lugar de desarrollado dentro del proveedor de servicios de TI . Ver también
Fuera de la plataforma.
Modelo Una representación de un sistema, proceso, servicio de TI, elemento de configuración,

etc. que se utiliza para ayudar a comprender o predecir el comportamiento futuro.
Modelado Una técnica que se utiliza para predecir el comportamiento futuro de un sistema,
Proceso, servicio de TI, elemento de configuración, etc. El modelado es comúnmente
utilizado en gestión financiera, gestión de capacidad y disponibilidad
Administración.
Supervisión (Operación del servicio) Observación repetida de un elemento de configuración, TI

Servicio o proceso para detectar eventos y garantizar que el estado actual
es conocida.
Objetivo El propósito u objetivo definido de un proceso, una actividad o una organización.

como un todo. Los objetivos generalmente se expresan como metas mensurables.
El término Objetivo también se usa informalmente para referirse a un Requisito. Ver
también Resultado.
Fuera de la plataforma Consulte Comercial listo para usar.
Oficina de OGC posee la marca ITIL (derechos de autor y marca registrada). OGC es un Reino Unido
Gobierno Departamento de gobierno que apoya la entrega de los
Comercio agenda de adquisiciones a través de su trabajo en adquisiciones colaborativas y
Página 381
en elevar los niveles de habilidades y capacidad de adquisiciones dentro de los departamentos.

También brinda apoyo para proyectos complejos del sector público.
Costa afuera (Estrategia del Servicio) Pro visión de Servicios desde un lugar fuera de la
país donde tiene su sede el Cliente, a menudo en un continente diferente. Esta
puede ser la prestación de un servicio de TI o de funciones de apoyo como
una mesa de servicio. Consulte también en tierra.
En tierra (Estrategia del Servicio) Pro visión de servicios desde una ubicación dentro de la
país donde se encuentra el Cliente. Consulte también Off-shore.
Funcionar Para realizar como se esperaba. Se dice que un elemento de proceso o configuración
Opere si está entregando las salidas requeridas. Operar también significa
realizar una o más operaciones. Por ejemplo, operar una computadora es
para realizar las operaciones diarias necesarias para que funcione como se espera.
Operación (Operación del servicio) Gestión diaria de un servicio, sistema,

u otro elemento de configuración. Operación también se usa para significar cualquier
Actividad o Transacción definida. Por ejemplo, cargar una cinta magnética,
aceptar dinero en un punto de venta o leer datos de una unidad de disco.
Operacional El más bajo de los tres niveles de planificación y ejecución (estratégico, táctico,
Operacional). Las actividades operativas incluyen el día a día o a corto plazo
Planificación o entrega de un proceso empresarial o gestión de servicios de TI
Proceso. El término Operational también es sinónimo de Live.
Costo operacional Costo resultante de la ejecución de los servicios de TI. Pagos a menudo repetidos.
Por ejemplo, costos de personal, mantenimiento de hardware y electricidad (también
conocido como 'gasto corriente' o 'gasto de ingresos').
Nivel operacional (Diseño de servicio) (Mejora continua del servicio) Un acuerdo

Convenio entre un proveedor de servicios de TI y otra parte del mismo
Organización. Un OLA respalda la entrega de TI por parte del proveedor de servicios de TI.
Servicios a Clientes. La OLA define los bienes o servicios como
siempre y las responsabilidades de ambas partes. Por ejemplo, podría
ser un OLA:
• Entre el proveedor de servicios de TI y un

departamento de adquisiciones para obtener hardware en
tiempos acordados
• Entre la mesa de servicio y un grupo de soporte
para brindar Resolución de Incidencias en los tiempos acordados.
Consulte también Acuerdo de nivel de servicio .
Optimizar Revisar, Planificar y solicitar Cambios, con el fin de obtener el máximo

Eficiencia y efectividad de un proceso, elemento de configuración,
Aplicación, etc.
Organización Una empresa, entidad legal u otra institución. Ejemplos de organizaciones

que no son empresas incluyen la Organización Internacional de Estándares o
itSMF. El término Organización a veces se usa para referirse a cualquier entidad.
que tiene Personas, Recursos y Presupuestos. Por ejemplo, un proyecto o
Unidad de negocio.
Salir El resultado de la realización de una Actividad; siguiendo un proceso; entregando un
Página 382
Servicio de TI, etc. El término Resultado se utiliza para referirse a los resultados previstos, como
así como a los resultados reales. Ver también Objetivo.
Subcontratación (Estrategia de servicio) Uso de un proveedor de servicios externo para administrar TI

Servicios.
Gastos generales Ver costo indirecto.
Camaradería Una relación entre dos Organizaciones que implica trabajar en estrecha colaboración
juntos por objetivos comunes o beneficio mutuo. El proveedor de servicios de TI
debe tener una asociación con la empresa y con terceros que
son fundamentales para la prestación de servicios de TI. Consulte también Value Network .
Monitoreo pasivo (Operación del servicio) Monitoreo de un elemento de configuración, un servicio de TI o

un proceso que se basa en una alerta o notificación para descubrir el
estado.
Patrón de negocio (Estrategia de servicio) Un perfil de carga de trabajo de una o más actividades comerciales.
Actividad Los patrones de actividad empresarial se utilizan para ayudar al proveedor de servicios de TI
comprender y planificar los diferentes niveles de actividad empresarial.
Rendimiento Una medida de lo que logra o entrega un Sistema, persona, equipo,

Proceso o Servicio de TI.
Rendimiento (Mejora continua del servicio) El proceso responsable del día a día
administración Actividades de gestión de la capacidad. Estos incluyen monitoreo, umbral
detección, análisis y ajuste del rendimiento, e implementación de cambios
relacionados con el rendimiento y la capacidad.
Piloto (Transición del servicio) Una implementación limitada de un servicio de TI, una versión o
un proceso para el entorno vivo. Se utiliza un piloto para reducir el riesgo y
obtener retroalimentación y aceptación del usuario. Consulte también Prueba, Evaluación.
Plan Una propuesta detallada que describe las actividades y los recursos necesarios.
para lograr un Objetivo. Por ejemplo, un plan para implementar una nueva TI
Servicio o proceso. ISO / IEC 20000 requiere un plan para la gestión
de cada proceso de gestión de servicios de TI.
Planificar – Hacer – Verificar – Actuar (Mejora Continua del Servicio) Un ciclo de cuatro etapas para el Proceso
gestión, atribuida a Edward Deming. Planificar – Hacer – Verificar – Actuar también es
llamado el ciclo de Deming.
PLANIFICAR: Diseñar o revisar Procesos que apoyen los Servicios de TI.
HACER: Implementar el Plan y gestionar los Procesos.
COMPROBAR: Medir los procesos y los servicios de TI, comparar con

Objetivos y elaborar informes.
ACTUAR: Planificar e implementar Cambios para mejorar los Procesos.
Tiempo de inactividad planificado

(Diseño del servicio) Momento acordado en el que un servicio de TI no estará disponible.
El tiempo de inactividad planificado se utiliza a menudo para mantenimiento, actualizaciones y pruebas.
Consulte también Cambiar ventana, Tiempo de inactividad.
Planificación Una actividad responsable de crear uno o más planes. Por ejemplo,
Página 383
Planificación de capacidad.
PMBOK Un Estándar de gestión de proyectos mantenido y publicado por el

Instituto de manejo proyectos. PMBOK son las siglas de Project Management
Cuerpo de conocimientos. Visite www.pmi.org para obtener más información. Ver también
PRINCE2.
Política Expectativas e intenciones de la gerencia formalmente documentadas. Políticas

se utilizan para dirigir las decisiones y para garantizar una coherencia y
desarrollo e implementación de Procesos, Estándares, Roles,
Actividades, Infraestructura de TI, etc.
Instalación portátil (Diseño de servicio) Un edificio prefabricado, o un vehículo grande, proporcionado por
un tercero y trasladado a un sitio cuando lo necesite un servicio de TI
Plan de continuidad. Consulte también Opción de recuperación.
Correo- Una revisión que tiene lugar después de que se haya realizado un cambio o un proyecto.
Implementación implementado. Un PIR determina si el Cambio o Proyecto fue exitoso,
Revisar e identifica oportunidades de mejora.
Práctica Una forma de trabajar, o una forma de trabajar. Las prácticas pueden
incluyen Actividades, Procesos, Funciones, Estándares y Pautas. Ver
también las mejores prácticas.
Requisito previo para Una actividad que debe completarse o una condición que debe completarse
Éxito cumplido, para permitir la implementación exitosa de un Plan o Proceso. Un PFS es
a menudo una salida de un proceso que es una entrada requerida a otro
Proceso.
Precios (Estrategia de servicio) La actividad para establecer la cantidad de clientes

ser cargado.
PRINCE2 La metodología estándar del gobierno del Reino Unido para la gestión de proyectos.
Consulte www.ogc.gov.uk/prince2 para obtener más información. Consulte también PMBOK.
Prioridad (Transición del servicio) (Operación del servicio) Una categoría utilizada para identificar el
importancia relativa de un incidente, problema o cambio. La prioridad se basa
sobre Impacto y Urgencia, y se utiliza para identificar los tiempos requeridos para las acciones
ser tomado. Por ejemplo, el SLA puede establecer que los incidentes de prioridad 2
debe resolverse dentro de las 12 horas.
Problema (Operación del servicio) Una causa de uno o más Incidentes. La causa no es
generalmente conocido en el momento en que se crea un registro de problema, y el problema
El proceso de gestión es responsable de una mayor investigación.
Problema (Operación del servicio) El proceso responsable de administrar el ciclo de vida

administración de todos los problemas. Los objetivos principales de la gestión de problemas son
evitar que ocurran incidentes y minimizar el impacto de
Incidentes que no se pueden prevenir.
Procedimiento Un documento que contiene pasos que especifican cómo lograr una actividad.
Los procedimientos se definen como parte de los procesos. Ver también Instrucción de trabajo .
Proceso Un conjunto estructurado de actividades diseñadas para lograr un objetivo específico.

Un proceso toma una o más entradas definidas y las convierte en definidas
salidas. Un proceso puede incluir cualquiera de los roles, responsabilidades, herramientas
y los controles de gestión necesarios para entregar los productos de manera confiable. A
Página 384
El proceso puede definir Políticas, Estándares, Directrices, Actividades y Trabajo.

Instrucciones si son necesarias.
Control de procesos La actividad de planificar y regular un proceso, con el objetivo de

realizar el proceso de manera eficaz, eficiente y coherente.
Dueño del proceso Un rol responsable de garantizar que un proceso sea adecuado para su propósito. los
Las responsabilidades del propietario del proceso incluyen patrocinio, diseño, cambio
Gestión y mejora continua del Proceso y sus Métricas.
Este Rol se suele asignar a la misma persona que realiza el
Rol de administrador de procesos, pero los dos roles pueden estar separados en mayor
Organizaciones.
Proforma Una plantilla o documento de ejemplo que contiene datos de ejemplo que se
reemplazado con los valores reales cuando estos estén disponibles.
Programa Una serie de proyectos y actividades que se planifican y gestionan

juntos para lograr un conjunto general de Objetivos relacionados y otros
Resultados.
Proyecto Una organización temporal, con personas y otros activos necesarios para
lograr un objetivo u otro resultado. Cada proyecto tiene un ciclo de vida
que normalmente incluye inicio, planificación, ejecución, cierre, etc.
Los proyectos generalmente se gestionan utilizando una metodología formal como
PRINCE2.
Calidad La capacidad de un producto, servicio o proceso para proporcionar el

valor. Por ejemplo, un componente de hardware puede considerarse de
alta calidad si se desempeña como se espera y entrega el requerido
Fiabilidad. La calidad del proceso también requiere la capacidad de monitorear
Efectividad y Eficiencia, y mejorarlas si es necesario. Ver también
Sistema de manejo de calidad.
Gestión de la calidad (Mejora continua del servicio) El conjunto de procesos responsables de

Sistema Asegurar que todo el trabajo realizado por una Organización sea de un adecuado
Calidad para cumplir de forma fiable los Objetivos de Negocio o los niveles de Servicio . Ver también
ISO 9000.
RACI (Diseño de servicio) (Mejora continua del servicio) Un modelo utilizado para ayudar
definir roles y responsabilidades. RACI significa Responsable,
Responsable, Consultado e Informado.
Recíproco (Diseño de servicio) Una opción de recuperación. Un acuerdo entre dos

Arreglo Organizaciones para compartir recursos en caso de emergencia. Por ejemplo,
Espacio de sala de ordenadores o uso de una computadora central.
Registro Un documento que contiene los resultados u otra salida de un proceso o

Actividad. Los registros son evidencia del hecho de que una actividad tuvo lugar y
puede ser en papel o electrónico. Por ejemplo, un informe de auditoría, un incidente
Grabar o las actas de una reunión.
Recuperación (Diseño de servicio) (Operación de servicio) Devolución de un elemento de configuración o

un servicio de TI a un estado de trabajo. Recuperación de un servicio de TI a menudo
incluye recuperar datos a un estado consistente conocido. Después de la recuperación,
Es posible que se necesiten más pasos antes de que se pueda realizar el servicio de TI
a disposición de los Usuarios (Restauración).
Página 385
Opción de recuperación (Diseño de servicio) Una estrategia para responder a una interrupción del Servicio.
Las estrategias más utilizadas son No hacer nada, Solución manual,
Acuerdo recíproco, recuperación gradual, recuperación intermedia,
Recuperación rápida, recuperación inmediata. Las opciones de recuperación pueden hacer uso
de instalaciones dedicadas, o instalaciones de terceros compartidas por múltiples
Empresas.
Redundancia Consulte Tolerancia a fallos.
El término redundante también tiene un significado genérico de obsoleto, o no

ya se necesita.
Relación Una conexión o interacción entre dos personas o cosas. En los negocios
Gestión de relaciones es la interacción entre el servicio de TI
proveedor y la empresa. En Configuration Management es un enlace
entre dos elementos de configuración que identifican una dependencia o
conexión entre ellos. Por ejemplo, las aplicaciones pueden estar vinculadas a
los servidores en los que se ejecutan. Los servicios de TI tienen muchos enlaces a todos los CI que
contribuir a ellos.
Relación El grupo de procesos ISO / IEC 20000 que incluye relaciones comerciales
Procesos Gestión y Gestión de Proveedores.
Liberación (Transición del servicio) Una colección de hardware, software, documentación,

Procesos u otros componentes necesarios para implementar uno o más
Cambios aprobados a los servicios de TI. Los contenidos de cada lanzamiento son
administrado, probado e implementado como una sola entidad.
Liberar y (Transición del servicio) El proceso responsable tanto de la liberación

Despliegue Gestión y despliegue.
administración
Liberación (Transición del servicio) El proceso responsable de la planificación, programación

administración y controlar el movimiento de las versiones para probar y en vivo
Ambientes. El objetivo principal de la gestión de versiones es
Asegurar que la integridad del Entorno Vivo esté protegida y que el
Se liberan los componentes correctos. Release Management es parte del
Proceso de gestión de lanzamiento y despliegue.
Lanzamiento de registro (Transición de servicio) Un registro en la CMDB que define el contenido de un

Liberación. Un registro de versión tiene relaciones con toda la configuración
Elementos que se ven afectados por la versión.
Fiabilidad (Diseño de servicio) (Mejora continua del servicio) Una medida de cómo
siempre que un elemento de configuración o un servicio de TI pueda realizar su función acordada
sin interrupción. Normalmente se mide como MTBF o MTBSI. El término
La confiabilidad también se puede utilizar para establecer la probabilidad de que un Proceso,
Función, etc. entregará los resultados requeridos. Consulte también Disponibilidad.
Reparar (Operación de servicio) El reemplazo o corrección de una falla

Elemento de configuración.
Solicitud de cambio (transición del servicio) Una propuesta formal para realizar un cambio. Un RFC
incluye detalles del cambio propuesto y puede registrarse en papel
o electrónicamente. El término RFC a menudo se usa incorrectamente para significar un cambio
Registro, o el Cambio en sí.
Página 386
Solicitud de cumplimiento (Operación del servicio) El proceso responsable de administrar el ciclo de vida
de todas las solicitudes de servicio.
Requisito (Diseño de servicio) Una declaración formal de lo que se necesita. Por ejemplo, un
Requisito de nivel de servicio, un requisito del proyecto o el requisito
Entregables para un proceso. Consulte también Declaración de requisitos .
Resiliencia (Diseño de servicio) La capacidad de un elemento de configuración o servicio de TI para resistir

Fallo o Recuperarse rápidamente después de un Fallo. Por ejemplo, un
El cable blindado resistirá las fallas cuando se someta a tensión. Ver también Fallo
Tolerancia.
Resolución (Operación de servicio) Acción tomada para reparar la causa raíz de un incidente
o Problema, o para implementar una Solución. En ISO / IEC 20000,
Procesos de resolución es el grupo de Procesos que incluye Incidentes y
Gestión de problemas.
Recurso (Estrategia de servicio) Un término genérico que incluye infraestructura de TI, personas,
dinero o cualquier otra cosa que pueda ayudar a brindar un servicio de TI.
Los recursos se consideran activos de una organización. Ver también
Capacidad, activo de servicio .
Tiempo de respuesta Una medida del tiempo necesario para completar una Operación o Transacción.
Utilizado en la gestión de la capacidad como medida de la infraestructura de TI
Desempeño, y en Gestión de Incidencias como medida del tiempo
para contestar el teléfono o para iniciar el diagnóstico.
Sensibilidad Una medida del tiempo que se tarda en responder a algo. Esto podría ser
El tiempo de respuesta de una transacción, o la velocidad con la que un servicio de TI
proveedor responde a un incidente o solicitud de cambio, etc.
Restauración de Consulte Restaurar.

Servicio
Restaurar (Operación del servicio) Tomar medidas para devolver un servicio de TI a los usuarios
después de la reparación y recuperación de un incidente. Este es el objetivo principal
de Gestión de Incidencias.
Retirarse (Transición del servicio) Eliminación permanente de un servicio de TI u otro

Elemento de configuración, del entorno en vivo. Retirado es una etapa en el
Ciclo de vida de muchos elementos de configuración.
El retorno de la (Estrategia de servicio) (Mejora continua del servicio) Una medida de

Inversión el beneficio esperado de una inversión. En el sentido más simple es la red
beneficio de una inversión dividido por el valor neto de los activos invertidos.
Regresar a la normalidad (Diseño del servicio) La fase de un plan de continuidad del servicio de TI durante
que se reanudan las operaciones normales completas. Por ejemplo, si un suplente
centro de datos ha estado en uso, entonces esta fase traerá los datos primarios
centro de nuevo en funcionamiento y restaurar la capacidad de invocar el servicio de TI
Planes de continuidad nuevamente.
Revisar Una evaluación de un cambio, problema, proceso, proyecto, etc. Las revisiones son
normalmente se lleva a cabo en puntos predefinidos del ciclo de vida, y especialmente
después del cierre. El propósito de una revisión es asegurar que todos los entregables
se han proporcionado e identificar oportunidades de mejora. Ver
Página 387
también Revisión posterior a la implementación.
Derechos (Operación del servicio) Derechos o permisos otorgados a un Usuario o

Papel. Por ejemplo, el derecho a modificar datos particulares o autorizar un
Cambio.
Riesgo Un posible evento que podría causar daños o pérdidas, o afectar la capacidad de
alcanzar los objetivos. Un riesgo se mide por la probabilidad de una amenaza,
la vulnerabilidad del activo a esa amenaza y el impacto que tendría
si ocurrió.
Evaluación de riesgos Los pasos iniciales de la gestión de riesgos. Analizando el valor de los Activos para
el negocio, identificando las amenazas a esos activos y evaluando cómo
Cada Activo es vulnerable a esas Amenazas. La evaluación de riesgos puede ser
cuantitativo (basado en datos numéricos) o cualitativo.
Gestión de riesgos El Proceso responsable de identificar, evaluar y controlar los Riesgos.

Consulte también Evaluación de riesgos.
Papel Un conjunto de responsabilidades, actividades y autoridades otorgadas 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 Configuration Manager y
Change Manager puede ser realizado por una sola persona.
Causa principal (Operación del servicio) La causa subyacente u original de un Incidente o

Problema.
Correr cuesta Ver costo operativo.
Escalabilidad La capacidad de un servicio, proceso, elemento de configuración, etc. de TI para realizar

su Función acordada cuando cambia la Carga de Trabajo o el Alcance.
Alcance El límite, o el alcance, en el que un Proceso, Procedimiento, Certificación,

Se aplica contrato, etc. Por ejemplo, el alcance de la gestión del cambio
puede incluir todos los servicios de TI en vivo y los elementos de configuración relacionados, el
El alcance de un certificado ISO / IEC 20000 puede incluir todos los servicios de TI
entregado desde un centro de datos designado.
Seguridad Consulte Gestión de la seguridad de la información .
Seguridad Consulte Gestión de la seguridad de la información .

administración
Politica de seguridad Consulte la Política de seguridad de la información .
Separación de (Estrategia de servicio) Un enfoque para diseñar una solución o servicio de TI que
preocupaciones divide el problema en partes que pueden resolverse de forma independiente. Esta
El enfoque separa "qué" debe hacerse de "cómo" debe hacerse.
Servidor (Operación de servicio) Una computadora que está conectada a una red y
proporciona funciones de software que utilizan otros equipos.
Servicio Un medio de ofrecer valor a los clientes facilitando los resultados

Los clientes quieren lograr sin la propiedad de costos específicos y
Riesgos.
Aceptación del servicio (transición del servicio) Un conjunto de criterios utilizados para garantizar que un servicio de TI
Página 388
Criterios cumple con sus requisitos de funcionalidad y calidad y que el servicio de TI

El proveedor está listo para operar el nuevo servicio de TI cuando ha sido
Desplegada. Consulte también Aceptación.
Activo de servicio Cualquier capacidad o recurso de un proveedor de servicios . Consulte también Activo.
Capacidad de servicio (Diseño del servicio) (Mejora continua del servicio) La actividad
administración responsable de comprender el rendimiento y la capacidad de TI
Servicios. Los Recursos utilizados por cada Servicio de TI y el patrón de
uso a lo largo del tiempo se recopilan, registran y analizan para su uso en el
Plan de capacidad. Véase también Gestión de la capacidad empresarial, Componente
Gestión de capacidad.
Catálogo de servicios (Diseño de servicios) Una base de datos o documento estructurado con información
sobre todos los servicios de TI en vivo, incluidos los disponibles para implementación. los
El catálogo de servicios es la única parte de la cartera de servicios publicada para
Clientes, y se utiliza para respaldar la venta y prestación de servicios de TI.
El catálogo de servicios incluye información sobre entregables, precios,
Puntos de contacto, Procesos de pedidos y solicitud.
Continuidad del servicio Consulte Gestión de la continuidad del servicio de TI .

administración
Cultura de servicio Una cultura orientada al cliente. Los principales objetivos de una cultura de servicio
son la satisfacción del cliente y ayudar a los clientes a lograr su
Objetivos de negocios.
Diseño de servicio (Diseño de servicios) Una etapa en el ciclo de vida de un servicio de TI. Servicio
El diseño incluye una serie de procesos y funciones y es el título de
una de las publicaciones de Core ITIL. Consulte también Diseño.
Diseño de servicio (Diseño de servicio) Documento (s) que definen todos los aspectos de un Servicio de TI y
Paquete sus requisitos a través de cada etapa de su ciclo de vida. Un diseño de servicio
El paquete se produce para cada nuevo servicio de TI, cambio importante o TI.
Retiro del servicio.
Servicio de mesa (Operación del servicio) El único punto de contacto entre el servicio
proveedor y los Usuarios. Un Service Desk típico gestiona Incidentes y
Solicitudes de servicio, y también maneja la comunicación con los Usuarios.
Fallo de servicio (Diseño de servicio) Una actividad que identifica las causas subyacentes de uno o
Análisis más interrupciones del servicio de TI. SFA identifica oportunidades para mejorar la
Procesos y herramientas del proveedor de servicios de TI, y no solo los
Infraestructura. SFA es una actividad similar a un proyecto con limitaciones de tiempo, en lugar de
un proceso continuo de análisis.
Horas de servicio (Diseño del servicio) (Mejora continua del servicio) Un tiempo acordado
período en el que un servicio de TI en particular debería estar disponible. Por ejemplo,
"De lunes a viernes de 08:00 a 17:00 excepto festivos". Horas de servicio
debe definirse en un Acuerdo de nivel de servicio.
Servicio (Mejora continua del servicio) Un plan formal para implementar

Plan de mejora mejoras a un proceso o servicio de TI.
Conocimiento del servicio (Transición del servicio) Un conjunto de herramientas y bases de datos que se utilizan para
administración gestionar el conocimiento y la información. El SKMS incluye el
Página 389
Sistema Sistema de Gestión de la Configuración, así como otras herramientas y

bases de datos. El SKMS almacena, gestiona, actualiza y presenta todos
información que un proveedor de servicios de TI necesita para gestionar el ciclo de vida completo
de Servicios de TI.
Nivel de servicio Logro medido e informado contra uno o más niveles de servicio
objetivos. El término Nivel de servicio a veces se usa informalmente para significar
Objetivo de nivel de servicio.
Nivel de servicio (Diseño de servicio) (Mejora continua del servicio) Un acuerdo

Convenio 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 el
responsabilidades del proveedor de servicios de TI y del cliente. Un solo
El SLA puede cubrir varios servicios de TI o varios clientes. Ver también
Acuerdo de nivel operativo.
Nivel de servicio (Diseño del servicio) (Mejora continua del servicio) El proceso
administración responsable de negociar acuerdos de nivel de servicio y garantizar que
estos se cumplen. SLM es responsable de garantizar que todos los servicios de TI
Procesos de gestión, acuerdos de nivel operativo y
Contratos subyacentes, adecuados para el nivel de servicio acordado
objetivos. SLM monitorea e informa sobre los niveles de servicio, y mantiene
Opiniones de los usuarios.
Nivel de servicio (Estrategia de servicio) Un nivel definido de utilidad y garantía para un

Paquete Paquete de servicios. Cada SLP está diseñado para satisfacer las necesidades de un
Patrón particular de Actividad Empresarial. Consulte también Línea de servicio.
Nivel de servicio (Diseño de servicio) (Mejora continua del servicio) Un cliente

Requisito Requisito para un aspecto de un servicio de TI. Las SLR se basan en
Objetivos comerciales y se utilizan para negociar el nivel de servicio acordado
objetivos.
Objetivo de nivel de servicio (Diseño de servicio) (Mejora continua del servicio) Un compromiso que es
documentado en un Acuerdo de nivel de servicio. Los objetivos de nivel de servicio son
según los requisitos de nivel de servicio, y son necesarios para garantizar que
el diseño del servicio de TI es adecuado para su propósito. Los objetivos de nivel de servicio deben ser
SMART, y generalmente se basan en KPI.
Servicio La gestión de servicios es un conjunto de capacidades organizativas especializadas

administración para proporcionar valor a los Clientes en forma de Servicios.
Servicio Un enfoque de la gestión de servicios de TI que enfatiza la importancia

administración de coordinación y control a través de las diversas Funciones, Procesos,
ciclo vital y sistemas necesarios para gestionar el ciclo de vida completo de los servicios de TI. los
El enfoque del ciclo de vida de la gestión del servicio considera la estrategia, el diseño,
Transición, Operación y Mejora Continua de los Servicios de TI.
Supervisor Un gerente que es responsable de administrar el ciclo de vida de un extremo a otro de

uno o más servicios de TI. El término Administrador de servicios también se usa para
significa cualquier gerente dentro del proveedor de servicios de TI. Más comúnmente utilizado
para referirse a un Gerente de Relaciones Comerciales, un Gerente de Procesos, un
Gerente de cuentas o gerente senior con responsabilidad de servicios de TI
en general.
Operación de servicio (Operación del servicio) Una etapa en el ciclo de vida de un servicio de TI. Servicio
Página 390
La operación incluye una serie de procesos y funciones y es el título

de una de las publicaciones de Core ITIL. Consulte también Operación.
Propietario del servicio (Mejora continua del servicio) Un rol que es responsable de la
prestación de un servicio informático específico.
Portafolio de servicios (Estrategia de servicio) El conjunto completo de servicios gestionados por un

Proveedor de servicio. La cartera de servicios se utiliza para gestionar todo
Ciclo de vida de todos los servicios e incluye tres categorías: Canalización de servicios
(propuesto o en
Despliegue); desarrollo);
y servicios paraCatálogo deConsulte
jubilados. serviciostambién
(en vivolao cartera
disponible para
de servicios
Gestión .
Portafolio de servicios (Estrategia de servicio) El proceso responsable de la gestión del servicio.

administración Portafolio. La gestión de la cartera de servicios considera los servicios en términos de
el valor empresarial que proporcionan.
Proveedor de servicio (Estrategia de servicio) Una organización que proporciona servicios a uno o más
Clientes internos o clientes externos. El proveedor de servicios es a menudo
se utiliza como abreviatura de proveedor de servicios de TI.
Informes de servicio (Mejora continua del servicio) El proceso responsable de producir

y entrega de informes de logros y tendencias con respecto a los niveles de servicio.
Los informes de servicio deben acordar el formato, el contenido y la frecuencia de
informes con Clientes.
Petición de servicio (Operación del servicio) Una solicitud de un Usuario para obtener información o consejo, o
para un cambio estándar o para acceder a un servicio de TI. Por ejemplo para
restablecer una contraseña o proporcionar servicios de TI estándar para un nuevo usuario.
Las solicitudes de servicio generalmente son manejadas por un Service Desk y no
requieren que se envíe una RFC. Consulte también Solicitud de cumplimiento.
Estrategia de servicio (Estrategia de servicio) El título de una de las publicaciones principales de ITIL. Servicio
La estrategia establece una estrategia general para los servicios de TI y para las TI
Gestión De Servicios.
Transición de servicio (Transición del servicio) Una etapa en el ciclo de vida de un servicio de TI. Servicio
La transición incluye una serie de procesos y funciones y es el título
de una de las publicaciones de Core ITIL. Consulte también Transición .
Garantía de servicio (Estrategia de servicio) Garantía de que un servicio de TI cumplirá lo acordado

Requerimientos. Este puede ser un acuerdo formal, como un nivel de servicio
Acuerdo o Contrato, o puede ser un mensaje de marketing o una imagen de marca.
El valor comercial de un servicio de TI se crea mediante la combinación de
Utilidad de servicio (lo que hace el Servicio) y Garantía de servicio (qué tan bien
lo hace). Consulte también Garantía .
Utilidad (Diseño de servicio) (Mejora continua del servicio) La capacidad de un tercero

Parte Proveedor para cumplir con los términos de su Contrato. Este contrato
incluir niveles acordados de confiabilidad, mantenibilidad o disponibilidad para un
Elemento de configuración.
Cambio (Operación del servicio) Un grupo o equipo de personas que llevan a cabo una
Rol por un período de tiempo fijo. Por ejemplo, podría haber cuatro turnos de
Personal de control de operaciones de TI para respaldar un servicio de TI que se utiliza 24
horas al día.
Página 391
Simulación (Diseño de servicio) (Mejora continua del servicio) Una técnica que
modelado crea un modelo detallado para predecir el comportamiento de un elemento de configuración
o Servicio de TI. Los modelos de simulación pueden ser muy precisos pero son caros
y requiere mucho tiempo para crear. Un modelo de simulación a menudo es creado por
utilizando los elementos de configuración reales que se están modelando, con
cargas de trabajo artificiales o transacciones. Se utilizan en capacidad
Gestión cuando los resultados precisos son importantes. Un modelo de simulación es
a veces se denomina Benchmark de rendimiento.
Punto único de (Diseño de servicio) Cualquier elemento de configuración que pueda causar un incidente
Falla cuando falla, y para la cual no se ha aplicado una Contramedida
implementado. Un SPoF puede ser una persona o un paso en un proceso o
Actividad,
Falla. así como Componente de la Infraestructura de TI. Ver también
INTELIGENTE (Diseño de servicio) (Mejora continua del servicio) Un acrónimo de

ayudando a recordar que los objetivos en los acuerdos de nivel de servicio y
Los planes de proyecto deben ser específicos, medibles, alcanzables, relevantes y
Oportuno.
Especificación Una definición formal de Requisitos. Se puede utilizar una especificación para
definir requisitos técnicos u operativos, y puede ser interno o
externo. Muchas normas públicas constan de un código de prácticas y una
Especificación. La Especificación define el Estándar contra el cual un
La organización puede ser auditada.
Interesado Todas las personas que tengan interés en una Organización, Proyecto, Servicio de TI,
etc. Las partes interesadas pueden estar interesadas en las actividades, objetivos, recursos,
o Entregables. Las partes interesadas pueden incluir Clientes, Socios,
empleados, accionistas, propietarios, etc. Ver también RACI.
Estándar Un requisito obligatorio. Los ejemplos incluyen ISO / IEC 20000 (un
estándar internacional), un estándar de seguridad interno para Unix
configuración, o un estándar gubernamental sobre cómo los registros financieros
debe ser mantenido. El término Estándar también se usa para referirse a un Código.
de Práctica o Especificación publicada por una Organización de Estándares como
como ISO o BSI. Consulte también la Guía.
Apoyar (Diseño de servicio) Se utiliza para hacer referencia a los recursos que no se requieren
ofrecer los servicios de TI en vivo, pero están disponibles para respaldar el servicio de TI
Planes de continuidad. Por ejemplo, se puede mantener un centro de datos en espera
para admitir los arreglos Hot Standby, Warm Standby o Cold Standby.
Declaracion de (Diseño de servicio) Un documento que contiene todos los requisitos de un producto.
requisitos compra, o un Servicio de TI nuevo o modificado. Consulte también los Términos de referencia .
Estado El nombre de un campo obligatorio en muchos tipos de registro. Muestra el

etapa actual en el ciclo de vida del elemento de configuración asociado,
Incidente, Problema, etc.
Estratégico (Estrategia de servicio) El más alto de los tres niveles de planificación y entrega
(Estratégico, Táctico, Operacional). Las actividades estratégicas incluyen el objetivo
establecimiento y planificación a largo plazo para lograr la Visión general.
Estrategia (Estrategia de servicio) Un plan estratégico diseñado para lograr

Objetivos.
Página 392
Proveedor (Estrategia de servicio) (Diseño de servicio) Un tercero responsable de

suministro de bienes o servicios necesarios para prestar servicios de TI.
Los ejemplos de proveedores incluyen hardware y software de productos básicos.
proveedores, proveedores de redes y telecomunicaciones y organizaciones de subcontratación.
Véase también Contrato subyacente , Cadena de suministro .
Proveedor y (Diseño de servicio) Una base de datos o documento estructurado que se utiliza para gestionar
Base de datos de contratos Contratos de proveedores a lo largo de su ciclo de vida. El SCD contiene clave
Atributos de todos los Contratos con Proveedores, y deben ser parte del
Sistema de gestión del conocimiento del servicio.
Proveedor (Diseño del servicio) El proceso responsable de garantizar que todos los contratos
administración con los proveedores apoyan las necesidades del negocio, y que todos los proveedores
cumplir con sus compromisos contractuales.
Cadena de suministro (Estrategia de servicio) Las actividades en una cadena de valor llevadas a cabo por
Proveedores. Una cadena de suministro generalmente involucra a varios proveedores, cada uno
agregando valor al producto o servicio. Consulte también Value Network .
Grupo de apoyo (Operación del servicio) Un grupo de personas con habilidades técnicas. Apoyo
Los grupos brindan el soporte técnico que necesitan todos los servicios de TI.
Procesos de gestión. Consulte también Gestión técnica .
Horas de soporte (Diseño del servicio) (Operación del servicio) Las horas u horas en las que se
disponible para los Usuarios. Normalmente, estas son las horas en las que el Servicio
Escritorio está disponible. Las horas de soporte deben definirse en un nivel de servicio
Acuerdo, y puede ser diferente del horario de servicio. Por ejemplo,
Las horas de servicio pueden ser las 24 horas del día, pero las horas de soporte pueden ser
07:00 a 19:00.
Servicio de apoyo (Estrategia de servicio) Un servicio que habilita o mejora un Servicio principal.
Por ejemplo, un servicio de directorio o un servicio de respaldo.
análisis FODA (Mejora continua del servicio) Una técnica que revisa y analiza
las fortalezas y debilidades internas de una Organización y la
oportunidades y amenazas externas a las que se enfrenta FODA significa
Fortalezas, Debilidades, Oportunidades y Amenazas.
Sistema Una serie de cosas relacionadas que funcionan juntas para lograr un
Objetivo. Por ejemplo:
• Un sistema informático que incluye hardware,

Software y Aplicaciones
• Un sistema de gestión, que incluye múltiples
Procesos que se planifican y gestionan
juntos. Por ejemplo, una gestión de calidad
Sistema
• Un sistema de gestión de base de datos u operativo
Sistema que incluye muchos módulos de software
que están diseñados para realizar un conjunto de
Funciones.
Sistema La parte de la gestión de servicios de TI que se centra en la gestión de

administración Infraestructura de TI en lugar de Procesos.
Página 393
Táctico El medio de tres niveles de planificación y ejecución (estratégico, táctico,

Operacional). Las actividades tácticas incluyen los planes a medio plazo requeridos.
para lograr objetivos específicos, generalmente durante un período de semanas para
meses.
Técnico (Operación del servicio) La función responsable de proporcionar

administración habilidades en soporte de servicios de TI y 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.
Servicio tecnico Consulte Servicio de infraestructura.
Apoyo técnico Ver Gestión técnica .
Términos de referencia (Diseño de servicio) Un documento que especifica los requisitos, el alcance,
Entregables, Recursos y cronograma para un Proyecto o Actividad.
Prueba (Transición del servicio) Una actividad que verifica que un elemento de configuración, TI
El Servicio, Proceso, etc. cumple con su Especificación o Requisitos acordados.
Consulte también Aceptación.
Tercero Una persona, grupo o empresa que no forma parte del nivel de servicio.
Acuerdo para un servicio de TI, pero es necesario para garantizar el éxito
prestación de ese Servicio de TI. Por ejemplo, un proveedor de software, un hardware
empresa de mantenimiento, o un departamento de instalaciones. Requisitos para el tercero
Por lo general, las partes se especifican en los contratos subyacentes o en los
Acuerdos de nivel.
Soporte de tercera línea (Operación del servicio) El tercer nivel en una jerarquía de grupos de apoyo
involucrado en la resolución de Incidencias e investigación de Problemas.
Cada nivel contiene más habilidades especializadas, o tiene más tiempo u otras
recursos.
Amenaza Cualquier cosa que pueda aprovechar una vulnerabilidad. Cualquier causa potencial de un
El incidente puede considerarse una amenaza. Por ejemplo, un incendio es una amenaza
que podrían aprovechar la vulnerabilidad de los revestimientos de suelo inflamables. Esta
El término se usa comúnmente en Gestión de seguridad de la información y TI.
Gestión de la continuidad del servicio, pero también se aplica a otras áreas como
Gestión de problemas y disponibilidad.
Umbral El valor de una métrica que debería hacer que se genere una alerta, o
acción de gestión a tomar. Por ejemplo, 'Incidente de prioridad 1 no
resuelto en cuatro horas ',' más de cinco errores de disco blando en una hora ', o
'más de 10 cambios fallidos en un mes'.
Rendimiento (Diseño de servicio) Una medida del número de Transacciones u otra

Operaciones, realizadas en un tiempo fijo. Por ejemplo, 5.000 correos electrónicos enviados
por hora o 200 E / S de disco por segundo.
Costo total de (Estrategia de servicio) Una metodología utilizada para ayudar a realizar inversiones
Propiedad decisiones. El TCO evalúa el costo total del ciclo de vida de poseer un
Elemento de configuración, no solo el costo inicial o el precio de compra.
Transacción Una función discreta realizada por un servicio de TI. Por ejemplo, transfiriendo
dinero de una cuenta bancaria a otra. Una sola transacción puede
implican numerosas adiciones, eliminaciones y modificaciones de datos. Cualquiera
Página 394
todos estos se completan con éxito o ninguno de ellos se lleva a cabo.
Transición (Transición de servicio) Un cambio de estado, correspondiente a un movimiento de

un servicio de TI u otro elemento de configuración desde un estado del ciclo de vida hasta el
próximo.
Análisis de tendencia (Mejora continua del servicio) Análisis de datos para identificar el tiempo
patrones. El análisis de tendencias se utiliza en la gestión de problemas para identificar
Fallos comunes o elementos de configuración frágiles, y en capacidad
La gestión como herramienta de modelización para predecir comportamientos futuros. Tambien es
utilizado como herramienta de gestión para identificar deficiencias en el servicio de TI
Procesos de gestión.
Afinación La actividad responsable de la planificación cambia para hacer la más eficiente

uso de recursos. El ajuste es parte de Performance Management, que
También incluye el seguimiento del desempeño y la implementación de la
Cambios requeridos.
Apuntalando (Diseño de servicio) Un contrato entre un proveedor de servicios de TI y un tercero

Contrato partido. El tercero proporciona bienes o servicios que respaldan la entrega de
un servicio de TI para un cliente. El contrato subyacente define objetivos
y responsabilidades que se requieren para cumplir con el nivel de servicio acordado
objetivos en un SLA.
Urgencia (Transición del servicio) (Diseño del servicio) Una medida de cuánto tiempo será
hasta que un incidente, problema o cambio tenga un impacto significativo en el
Negocio. Por ejemplo, un incidente de alto impacto puede tener poca urgencia, si
el Impacto no afectará al Negocio hasta el final del año financiero.
El impacto y la urgencia se utilizan para asignar prioridad.
Usabilidad (Diseño de servicio) La facilidad con la que una aplicación, producto o TI

Se puede utilizar el servicio. Los requisitos de usabilidad a menudo se incluyen en un
Declaración de requisitos.
Caso de uso (Diseño de servicio) Una técnica utilizada para definir la funcionalidad requerida y
Objetivos y diseño de Pruebas. Los casos de uso definen escenarios realistas
que describen las interacciones entre los usuarios y un servicio de TI u otros
Sistema.
Usuario Persona que utiliza el Servicio de TI en el día a día. Los usuarios son
distinto de los Clientes, ya que algunos Clientes no utilizan el Servicio de TI
directamente.
Utilidad (Estrategia de servicio) Funcionalidad ofrecida por un Producto o Servicio para cumplir
una necesidad particular. La utilidad a menudo se resume como "lo que hace".
Validación (Transición del servicio) Una actividad que garantiza una TI nueva o modificada.
El Servicio, Proceso, Plan u otro Entregable satisface las necesidades del
Negocio. La validación garantiza que se cumplan los requisitos comerciales incluso
aunque estos pueden haber cambiado desde el diseño original. Ver también
Verificación , aceptación.
Cadena de valor (Estrategia de servicio) Una secuencia de procesos que crea un producto o
Servicio que es de valor para un Cliente. Cada paso de la secuencia se construye
en los pasos anteriores y contribuye al producto o servicio en general.
Consulte también Value Network .
Página 395
Valor por su dinero Una medida informal de rentabilidad. La relación calidad-precio es a menudo
basado en una comparación con el costo de alternativas. Ver también Costo
Análisis de beneficios.
Red de valor (Estrategia de servicio) Un conjunto complejo de relaciones entre dos o más
grupos u organizaciones. El valor se genera mediante el intercambio de
conocimiento, información, bienes o servicios. Véase también Cadena de valor ,
Camaradería.
Diferencia La diferencia entre un valor planificado y el valor medido real.

De uso común en gestión financiera, gestión de capacidad y
Gestión del nivel de servicio, pero podría aplicarse en cualquier área donde los planes estén
en su lugar.
Verificación (Transición del servicio) Una actividad que garantiza una TI nueva o modificada.
El Servicio, Proceso, Plan u otro Entregable es completo, exacto,
Confiable y coincide con sus especificaciones de diseño . Consulte también Validación ,
Aceptación.
Versión (Transición del servicio) Una versión se utiliza para identificar una línea de base específica de un
Elemento de configuración. Las versiones suelen utilizar una convención de nomenclatura que
permite identificar la secuencia o fecha de cada Línea Base. Para
ejemplo de la aplicación de nómina versión 3 contiene una funcionalidad actualizada
de la versión 2.
Visión Una descripción de lo que la Organización pretende convertirse en el futuro. A
La visión es creada por la alta dirección y se utiliza para ayudar a influir
Cultura y planificación estratégica.
Negocio vital (Diseño de servicio) Una función de un proceso empresarial que es fundamental para la
Función éxito del negocio. Las funciones comerciales vitales son importantes
consideración de la gestión de la continuidad del negocio, la continuidad del servicio de TI
Gestión y gestión de la disponibilidad.
Vulnerabilidad Una debilidad que podría ser aprovechada por una Amenaza. Por ejemplo, un abierto
puerto de firewall, una contraseña que nunca se cambia o una alfombra inflamable. A
El control faltante también se considera una vulnerabilidad.
Espera cálida Consulte Recuperación intermedia.
Garantía ( Estrategia de servicio ) Una promesa o garantía de que un producto o servicio

cumplir con los Requisitos acordados. Consulte también Garantía de servicio .
Instrucción de trabajo Un documento que contiene instrucciones detalladas que especifican exactamente qué
Pasos a seguir para realizar una Actividad. Una instrucción de trabajo contiene mucho
más detalle que un procedimiento y solo se crea si es muy detallado
se necesitan instrucciones.
Solución alterna (Operación del servicio) Reducir o eliminar el impacto de un incidente o

Problema para el que aún no se dispone de una resolución completa. Por ejemplo, por
reiniciar un elemento de configuración fallido. Las soluciones para los problemas son
documentado en los registros de errores conocidos. Soluciones provisionales para incidentes que sí
no tienen registros de problemas asociados están documentados en el incidente
Registro.
Carga de trabajo Los recursos necesarios para entregar una parte identificable de un servicio de TI.
Página 396
Las cargas de trabajo pueden clasificarse por usuarios, grupos de usuarios o funciones
dentro del Servicio de TI. Se utiliza para ayudar a analizar y gestionar
la capacidad, rendimiento y utilización de elementos de configuración y TI
Servicios. El término Carga de trabajo a veces se utiliza como sinónimo de
Rendimiento.

Servicio ITIL - 2022

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

Servicio ITIL - 2022

Cargado por

Copyright:

Formatos disponibles

7/3/2021 Operación del servicio ITIL versión 3

El ITIL Core consta de cinco publicaciones. Cada uno proporciona

ITIL V3 - Operación de servicio - Página: 2 de 396

ITIL V3 - Operación de servicio - Página: 3 de 396

3 Principios de funcionamiento del servicio .............................................. .............................. 39

ITIL V3 - Operación de servicio - Página: 4 de 396

4.2.5.4 Priorización de incidentes ............................................. .................................................. ........ 94

4.2.5.7 Investigación y diagnóstico ............................................ ................................................ 97

ITIL V3 - Operación de servicio - Página: 5 de 396

4.5.1 Propósito / meta / objetivo .......................................... ................................................ 126

Métricas ................................................. .................................................. ................................................. 164

Indicadores clave de rendimiento ............................................... .................................................. .................. 164

ITIL V3 - Operación de servicio - Página: 6 de 396

5.2.3.2 Restaurar .............................................. .................................................. ......................... 170

ITIL V3 - Operación de servicio - Página: 7 de 396

6.3.2 Objetivos de la gestión técnica ............................................ ............................ 220

ITIL V3 - Operación de servicio - Página: 8 de 396

6.6.3.4 Operadores de TI ............................................. .................................................. ................... 260

ITIL V3 - Operación de servicio - Página: 9 de 396

7.7.2.2 Scripts de diagnóstico ............................................. .................................................. ........... 291

ITIL V3 - Operación de servicio - Página: 10 de 396

B4 Comunicación en proyectos .............................................. ...................................... 328

ITIL V3 - Operación de servicio - Página: 11 de 396

Desde su creación, ITIL ha crecido hasta convertirse en el enfoque más aceptado

Director ejecutivo interino

Oficina de Comercio Gubernamental

ITIL V3 - Operación de servicio - Página: 12 de 396

Prólogo del arquitecto jefe

La guía de práctica de gestión de servicios de ITIL se estructura en torno al servicio

Cualquier persona involucrada en los servicios operativos se beneficiará de la orientación en el

Arquitecto jefe, Prácticas de gestión de servicios de ITIL

ITIL V3 - Operación de servicio - Página: 13 de 396

Los principios básicos de la gestión de servicios de TI de mejores prácticas englobados en

Sin embargo, las tecnologías, herramientas y relaciones han cambiado significativamente,

Información del contacto

Si desea informarnos de cualquier cambio que pueda ser necesario en este

Para obtener más información sobre cualificaciones y acreditación de formación, visite

Mesa de servicio APMG

Tel: +44 (0) 1494 452450

ITIL V3 - Operación de servicio - Página: 14 de 396

Arquitecto jefe y autores

Sharon Taylor (Aspect Group Inc) Arquitecto jefe

David Cannon (HP) Autor

David Wheeldon (HP) Autor

Equipo de creación de ITIL

El equipo de creación de ITIL contribuyó a esta guía comentando el contenido.

Christian Nissen y Paul Wilkinson

ITIL V3 - Operación de servicio - Página: 15 de 396

El Grupo Asesor de ITIL

ITIL V3 - Operación de servicio - Página: 16 de 396

El advenimiento de la nueva tecnología y las ahora borrosas líneas entre lo tradicional

ITIL V3 - Operación de servicio - Página: 17 de 396

La operación del servicio es la fase del ciclo de vida de ITSM responsable de

Los procesos bien planificados e implementados no servirán de nada si el día a día

La operación del servicio no es una unidad organizativa ni un proceso único, pero

ITIL V3 - Operación de servicio - Página: 18 de 396

1.2.1 Gestión de servicios

1.2.2 Buenas prácticas en el dominio público

Las organizaciones operan en entornos dinámicos con la necesidad de aprender y

ITIL V3 - Operación de servicio - Página: 19 de 396

Figura 1.1 Fuente de la práctica de gestión de servicios

• El conocimiento patentado está profundamente arraigado en las organizaciones y, por lo tanto,

ITIL V3 - Operación de servicio - Página: 20 de 396