004 ITIL V3 Operacao de Servico PDF

ITIL Versão 3
Operação de Serviço
ITIL V3 - Operação de Serviço - Página: 1 de 423

O Core ITIL é composto por cinco publicações. Cada uma
delas fornece a orientação necessária para uma
abordagem integrada, tal como exigido pela ISO / IEC
20000 padrão especificação:
• Estratégia de Serviço
• Design de Serviços
• Transição de Serviço
• Operação de Serviço
• Melhoria de Serviço Continuada.

INDICE
Prefácio ............................................................................................................. 12
Prefácio da OGC........................................................................................................... 12
Prefácio Arquiteto Chefe............................................................................................... 13
Prefaciar ............................................................................................................ 14
Informações de contato ................................................................................................ 14
Agradecimentos................................................................................................. 15
Arquiteto-chefe e autores ............................................................................................. 15
ITIL autoria da equipe ................................................................................................... 15
Mentores ....................................................................................................................... 15
Outras contribuições ..................................................................................................... 15
O ITIL Grupo Consultivo .................................................................................................. 16
Revisores......................................................................................................................... 16
1 Introdução ...................................................................................................... 17
1.1 Visão Geral ............................................................................................................. 18
1,2 Contexto .................................................................................................................. 19
1.2.1 Gestão de Serviços ................................................................................................ 19
1.2.2 Boas práticas no domínio público ........................................................................... 19
1.2.3 ITIL e boas práticas em Gestão de Serviços .......................................................... 21
1.2.3.1 Estratégia de Serviço .................................................................................................. 23
1.2.3.2 Design de Serviços ..................................................................................................... 23
1.2.3.3 Transição de Serviço .................................................................................................. 24
1.2.3.4 Operação de Serviço .................................................................................................. 24
1.2.3.5 Melhoria de Serviço Continuada.................................................................................. 24
1,3 Propósito ................................................................................................................. 26
1,4 Uso .......................................................................................................................... 26
1,5 Visão geral do capítulo ........................................................................................... 27
2 Gerenciamento de Serviço como uma prática ................................................ 28
2.1 O que é Gerenciamento de Serviços? ................................................................... 28
2.2 O que são serviços? ............................................................................................... 30
2.2.1 O valor proposição.................................................................................................. 30
2.3 Funções e processos em todo o ciclo de vida ....................................................... 31
2.3.1 Funções .................................................................................................................. 31
2.3.2 Processos ............................................................................................................... 31
2.3.3 Especialização e coordenação em todo o ciclo de vida.......................................... 32
2.4 Operação fundamentos Serviço ............................................................................. 33
2.4.1 Finalidade objetivo / / objetivo................................................................................. 33
2.4.2 Âmbito .................................................................................................................... 33
2.4.3 Valor para os negócios ........................................................................................... 34
2.4.4 Otimização do desempenho do Serviço de Operação............................................ 35
2.4.5 Processos dentro de Operação de Serviço ............................................................ 35
2.4.5.1 Gestão de Eventos ..................................................................................................... 35
2.4.5.2 Incidentes e Gestão de Problemas .............................................................................. 35
2.4.5.3 Cumprimento de Requisição ....................................................................................... 36
2.4.5.4 Gerenciamento de Acesso .......................................................................................... 36
2.4.6 Funções dentro de Operação de Serviço ............................................................... 36
2.4.6.1 Service Desk............................................................................................................... 37
2.4.6.2 Gestão Técnica........................................................................................................... 37
2.4.6.3 Gestão de Operações de TI ........................................................................................ 37
2.4.6.4 Gerenciamento de Aplicativos ..................................................................................... 37
2.4.6.5 Interfaces para outros estágios Serviço Lifecycle Management ................................... 38

3 Operação princípios do serviço ...................................................................... 39
3,1 Funções, grupos, equipes, departamentos e divisões .......................................... 40
Alcançar 3,2 equilíbrio na Operação de Serviço .......................................................... 42
3.2.1 TI interna ver contra vista de negócios externo ...................................................... 42
3.2.2 Estabilidade em relação a capacidade de resposta................................................ 46
3.2.3 A qualidade do serviço versus custo do serviço ..................................................... 49
3.2.4 reativa contra proativo ............................................................................................ 52
3,3 prestação de serviços ............................................................................................. 57
3,4 a participação do pessoal de operação em Design de Serviços e Transição de
Serviço .......................................................................................................................... 58
3,5 Saúde Operacional ................................................................................................. 59
3,6 Comunicação .......................................................................................................... 61
3.6.1 Reuniões................................................................................................................. 62
3.6.1.1 A reunião de Operações ............................................................................................. 63
3.6.1.2 Departamento reuniões de grupo ou equipe ................................................................ 64
3.6.1.3 reuniões com clientes ................................................................................................. 64
3,7 Documentação ........................................................................................................ 66
4 Operação processos de serviço ..................................................................... 67
4.1 Gestão de Eventos ................................................................................................. 69
4.1.2 Âmbito .................................................................................................................... 69
4.1.4 Políticas / princípios / conceitos básicos................................................................. 71
4.1.5 as atividades de processo, métodos e técnicas...................................................... 73
4.1.5.1 Evento ocorre ............................................................................................................. 74
4.1.5.2 Notificação de eventos ................................................................................................ 74
4.1.5.3 Detecção de eventos .................................................................................................. 75
4.1.5.4 Evento filtragem .......................................................................................................... 75
4.1.5.5 Significado de eventos ................................................................................................ 75
4.1.5.6 correlação de eventos ................................................................................................. 77
4.1.5.7 Gatilho ........................................................................................................................ 77
4.1.5.8 Resposta seleção ....................................................................................................... 78
4.1.5.9 Rever as acções ......................................................................................................... 81
4.1.5.10 evento Close ............................................................................................................. 81
4.1.6 Triggers interfaces de entrada e saída / inter-processo.......................................... 82
4.1.7 Gestão da Informação ............................................................................................ 83
4.1.8 Métricas .................................................................................................................. 84
4.1.9 Desafios, Fatores Críticos de Sucesso e riscos...................................................... 85
4.1.9.1 Desafios ..................................................................................................................... 85
4.1.9.2 Fatores Críticos de Sucesso ....................................................................................... 85
4.1.9.3 Riscos......................................................................................................................... 86
4.1.10 Projeto de Gestão de Eventos .............................................................................. 86
4.1.10.1 Instrumentação ......................................................................................................... 86
4.1.10.2 mensagens de erro ................................................................................................... 87
4.1.10.3 de detecção de eventos e mecanismos de alerta....................................................... 87
4.1.10.4 Identificação de limiares ............................................................................................ 88
4.2 Gestão de Incidentes .............................................................................................. 89
4.2.2 Âmbito .................................................................................................................... 89
4.2.4 Políticas / princípios / conceitos básicos................................................................. 90
4.2.4.1 Prazos ........................................................................................................................ 90
4.2.4.2 Modelos de Incidentes ................................................................................................ 90
4.2.4.3 grandes incidentes ...................................................................................................... 91
4.2.5 As atividades de processo, métodos e técnicas ..................................................... 92
4.2.5.1 identificação de incidentes .......................................................................................... 93
4.2.5.2 registro de incidentes .................................................................................................. 94

4.2.5.3 categorização de incidentes ........................................................................................ 95
4.2.5.4 priorização de Incidentes ............................................................................................ 97
4.2.5.5 O diagnóstico inicial .................................................................................................... 99
4.2.5.6 escalada de incidentes ................................................................................................ 99
Nota sobre alocação de Incidentes ..........................................................................................................100
4.2.5.7 Investigação e Diagnóstico........................................................................................ 100
4.2.5.8 Resolução e Recuperação ........................................................................................ 101
4.2.5.9 Fechamento de Incidentes ........................................................................................ 102
Regras para reabertura incidentes ................................................................................ 103
4.2.6 Triggers interfaces de entrada e saída / inter-processo........................................ 103
4.2.7 Gestão da Informação .......................................................................................... 104
4.2.8 Métricas ................................................................................................................ 105
4.2.9 Desafios, Fatores Críticos de Sucesso e riscos.................................................... 106
4.2.9.1 Desafios ................................................................................................................... 106
4.2.9.2 Fatores Críticos de Sucesso ..................................................................................... 107
4.2.9.3 Riscos....................................................................................................................... 107
4,3 Cumprimento de Requisição ................................................................................ 108
Finalidade 4.3.1 meta / / objetivo ................................................................................... 108
4.3.2 Âmbito .................................................................................................................. 108
4.3.3 Valor para os negócios ......................................................................................... 109
4.3.4 Políticas / princípios / conceitos básicos............................................................... 109
4.3.4.1 Modelos Pedido ........................................................................................................ 109
4.3.5 as atividades de processo, métodos e técnicas.................................................... 110
4.3.5.1 seleção do menu....................................................................................................... 110
4.3.5.2 aprovação Financeiro................................................................................................ 110
4.3.5.3 aprovação Outros ..................................................................................................... 110
4.3.5.4 Cumprimento ............................................................................................................ 111
4.3.5.5 Encerramento ........................................................................................................... 111
4.3.8 Métricas ................................................................................................................ 112
4.3.9.1 Desafios ................................................................................................................... 112
4.3.9.2 Fatores Críticos de Sucesso ..................................................................................... 113
4.3.9.3 Riscos....................................................................................................................... 113
4,4 Gerenciamento de Problemas .............................................................................. 115
4.4.1 Finalidade objetivo / / objetivo............................................................................... 115
4.4.2 Âmbito .................................................................................................................. 115
4.4.4.1 Modelos de problemas .............................................................................................. 116
4.4.5.1 detecção de problemas ............................................................................................. 117
4.4.5.2 registro Problema...................................................................................................... 118
4.4.5.3 Categorização Problema ........................................................................................... 119
4.4.5.4 Priorização de Problemas ......................................................................................... 119
4.4.5.5 Investigação e Diagnóstico de Problemas ................................................................. 119
4.4.5.6 Soluções Alternativas................................................................................................ 123
4.4.5.7 Levantando um registro de Erro Conhecido ............................................................... 124
4.4.5.8 A resolução de problemas ......................................................................................... 124
4.4.5.9 Encerramento Problema ........................................................................................... 125
4.4.5.10 Revisão grande problema ....................................................................................... 125
4.4.5.11 Os erros detectados no ambiente de desenvolvimento ............................................ 126
4.4.7.1 CMS ......................................................................................................................... 128
4.4.7.2 Banco de Dados Erro Conhecido .............................................................................. 128
4.4.8 Métricas ................................................................................................................ 130

4,5 Gerenciamento de Acesso ................................................................................... 132
4.5.1 Finalidade objetivo / / objetivo............................................................................... 132
4.5.2 Âmbito .................................................................................................................. 132
4.5.5.1 Solicitação de acesso ............................................................................................... 133
4.5.5.2 Verificação ................................................................................................................ 134
4.5.5.3 Prever direitos........................................................................................................... 134
4.5.5.4 status de identidade de Monitoramento ..................................................................... 136
4.5.5.5 acesso acompanhamento e rastreamento ................................................................. 136
4.5.5.6 Remoção ou restritiva de direitos .............................................................................. 137
4.5.7.1 Identidade ................................................................................................................. 139
4.5.7.2 Os usuários, grupos, funções e grupos de serviço..................................................... 140
4.5.8 Métricas ................................................................................................................ 141
4,6 As atividades operacionais de processos cobertos de fases do ciclo de vida de
outros .......................................................................................................................... 143
4.6.1 Gestão da Mudança ............................................................................................. 143
4.6.2 Gerenciamento da Configuração .......................................................................... 143
4.6.3 Gerenciamento de Liberação e Implantação ........................................................ 144
4.6.4 Gerenciamento da Capacidade ............................................................................ 144
4.6.4.1 Capacidade e Performance Monitoring...................................................................... 145
4.6.4.2 capacidade ou manipulação desempenho incidentes relacionados ............................ 146
4.6.4.3 Capacidade e tendências de desempenho ................................................................ 147
4.6.4.4 Armazenamento de dados de gerenciamento de capacidade .................................... 147
4.6.4.5 Gerenciamento da Demanda .................................................................................... 148
4.6.4.6 Workload Management ............................................................................................. 148
4.6.4.7 Modelação e aplicações de dimensionamento........................................................... 149
4.6.4.8 Planejamento de Capacidade ................................................................................... 149
4.6.5 Gerenciamento de Disponibilidade ....................................................................... 150
4.6.6 Gestão do Conhecimento ..................................................................................... 151
4.6.7 Gerenciamento Financeiro para Serviços de TI.................................................... 152
4.6.8 Gestão da Continuidade de Serviço de TI ............................................................ 152
5 atividades operação comum Serviço ............................................................ 154
5,1 Monitoramento e controle ..................................................................................... 157
5.1.1 Definições ............................................................................................................. 157
5.1.2 Controle Loops monitor ........................................................................................ 158
5.1.2.1 malha de controle Complexo do Monitor.................................................................... 160
5.1.2.2 O ITSM Monitor de Controle de Loop ........................................................................ 162
5.1.2.3 definir o que precisa ser monitorado.......................................................................... 165
5.1.2.4 Monitoramento Interno e Externo e Controle ............................................................. 165
5.1.2.5 Definir objectivos para monitoramento e controle ...................................................... 166
5.1.2.6 Tipos de monitoramento............................................................................................ 168
5.1.2.7 Monitoramento em ambientes de teste ...................................................................... 171
5.1.2.8 Relatórios e ação ...................................................................................................... 171
5.1.2.9 auditorias Operação de Serviço ................................................................................ 172
5.1.2.10 Medição, métricas e KPIs ........................................................................................ 172
Medição .....................................................................................................................................................173
Métrica ......................................................................................................................................................173
Indicadores Chave de Desempenho ........................................................................................................173
5.1.2.11 Interfaces para práticas de outros serviços do Ciclo de Vida.................................... 174
Monitoramento Operacional e Melhoria de Serviço Continuada.................................... 174
5,2 Operações de TI ................................................................................................... 176
5.2.1 Management Console / Ponte de Operações ....................................................... 176

5.2.2 Job Scheduling ..................................................................................................... 177
5.2.3 Backup e Restauração ......................................................................................... 178
5.2.3.1 backup ...................................................................................................................... 179
5.2.3.2 Restaurar.................................................................................................................. 181
5.2.4 impressão e de saída ........................................................................................... 181
5.3 Gestão Mainframe ................................................................................................ 183
5,4 Management Server e suporte ............................................................................. 184
5,5 Gerenciamento de Rede ...................................................................................... 186
5,6 Armazenamento e Arquivo ................................................................................... 188
5,7 Database Administration ...................................................................................... 190
5,8 Diretório de Gestão de Serviços .......................................................................... 192
5,9 Desktop Support ................................................................................................... 193
5,10 Middleware Gestão ............................................................................................. 194
5,11 Gestor da Internet / Web .................................................................................... 196
5,12 Instalações e Data Management Centre............................................................ 197
5.12.1 Dados estratégias Centro ................................................................................... 198
5,13 Gestão de Segurança da Informação e Operação de Serviço .......................... 200
5.13.1 Policiamento e relatórios..................................................................................... 200
5.13.2 Assistência técnica ............................................................................................. 201
5.13.3 controle de segurança operacional ..................................................................... 201
5.13.4 Seleção e habilitação.......................................................................................... 201
5.13.5 Treinamento e conscientização .......................................................................... 202
5.13.6 políticas e procedimentos documentados ........................................................... 202
5,14 Melhoria das actividades operacionais .............................................................. 203
5.14.1 automação de tarefas manuais........................................................................... 203
5.14.2 Rever atividades improvisadas ou procedimentos.............................................. 203
5.14.3 Auditorias Operacionais...................................................................................... 203
5.14.4 Usando o Gerenciamento de Incidentes e de Problemas ................................... 203
5.14.5 Comunicação ...................................................................................................... 203
5.14.6 A educação ea formação .................................................................................... 204
6 Organizador para Operação de Serviço ....................................................... 205
6.1 Funções ................................................................................................................ 205
6.1.1 Funções e atividades ............................................................................................ 207
6,2 Service Desk ......................................................................................................... 210
6.2.1 Justificação e do papel do Service Desk .............................................................. 210
6.2.2 Posto de objectivos de serviço ............................................................................. 211
6.2.3 estrutura organizacional Service Desk ................................................................. 212
6.2.3.1 Posto de Serviço Local.............................................................................................. 212
6.2.3.2 Service Desk centralizado ......................................................................................... 213
6.2.3.3 Service Desk Virtual .................................................................................................. 214
6.2.3.4 Siga o Sol ................................................................................................................. 215
6.2.3.5 grupos Posto de serviço especializado ...................................................................... 216
6.2.3.6 Ambiente .................................................................................................................. 216
6.2.3.7 Nota sobre a construção de um único ponto de contato............................................. 217
6.2.4 pessoal Service Desk ........................................................................................... 217
6.2.4.1 Os níveis de pessoal ................................................................................................. 217
6.2.4.2 Os níveis de especialização ...................................................................................... 219
6.2.4.3 Formação ................................................................................................................. 221
6.2.4.4 retenção de pessoal .................................................................................................. 222
6.2.4.5 Superusuários........................................................................................................... 223
6.2.5 Posto de métricas de serviço ................................................................................ 224
6.2.5.1 cliente / usuário pesquisas de satisfação ................................................................... 226
6.2.6 A terceirização do Service Desk ........................................................................... 228
6.2.6.1 As ferramentas comuns e processos ......................................................................... 229
6.2.6.2 metas de SLA ........................................................................................................... 230
6.2.6.3 A boa comunicação................................................................................................... 230

6.2.6.4 Propriedade dos dados ............................................................................................. 231
6.3 Gestão Técnica ..................................................................................................... 232
6.3.1 papel de Gestão Técnica ...................................................................................... 232
6.3.2 Técnicas objectivos de gestão .............................................................................. 233
6.3.3 genéricos técnicos actividades de gestão ............................................................ 233
6.3.4 organização Gestão Técnica ................................................................................ 236
6.3.5 Manutenção Design e Técnico de Apoio Técnico e .............................................. 237
6.3.6 Técnicas de Gestão de métricas .......................................................................... 237
6.3.7 documentação Gestão Técnica ............................................................................ 239
6.3.7.1 A documentação técnica ........................................................................................... 239
6.3.7.2 programações de manutenção .................................................................................. 239
6.3.7.3 Inventário de Habilidades .......................................................................................... 239
6,4 TI Gestão de Operações ...................................................................................... 241
6.4.1 Funções de Gerenciamento de Operações de TI ................................................. 241
6.4.2 Operações de TI objectivos de gestão ................................................................. 243
6.4.3 Operações de TI Gestão de organização ............................................................. 243
6.4.4 Operações de TI métricas de gestão .................................................................... 244
6.4.5 Operações de TI Gestão de documentação ......................................................... 245
6.4.5.1 Procedimentos Operacionais Padrão ........................................................................ 245
6.4.5.2 Operações Logs........................................................................................................ 245
6.4.5.3 Shift Schedules e Relatórios ..................................................................................... 246
6.4.5.4 Horário de Operações ............................................................................................... 247
6,5 Gerenciamento de Aplicativos .............................................................................. 247
6.5.1 papel Gerenciamento de Aplicativos .................................................................... 247
6.5.2 Aplicação objectivos de gestão............................................................................. 248
6.5.3 Gestão de princípios de aplicação ........................................................................ 249
6.5.3.1 Construir ou comprar? .............................................................................................. 249
6.5.3.2 Modelos Operacionais .............................................................................................. 250
6.5.4 Aplicação de Gestão do Ciclo de Vida.................................................................. 250
6.5.4.1 Requisitos ................................................................................................................. 252
6.5.4.2 Desenho ................................................................................................................... 253
6.5.4.3 Construção ............................................................................................................... 254
6.5.4.4 Implantar .................................................................................................................. 254
6.5.4.5 Operar ...................................................................................................................... 255
6.5.4.6 Otimizar .................................................................................................................... 255
6.5.5 Aplicação de Gestão de actividades de carácter genérico ................................... 256
6.5.6 Aplicação de Gestão de organização ................................................................... 259
6.5.6.1 papéis organizacionais .............................................................................................. 261
6.5.7 Aplicação funções de gerenciamento e responsabilidades .................................. 263
6.5.7.1 Aplicações Gerentes / ou chefes de equipa ............................................................... 263
6.5.7.2 Aplicações Analista / Arquiteto .................................................................................. 264
6.5.8 Gestão de métricas de aplicação.......................................................................... 265
6.5.9 documentação Gerenciamento de Aplicativos...................................................... 266
6.5.9.1 Application Portfolio .................................................................................................. 266
6.5.9.2 Requisitos da Aplicação ............................................................................................ 267
6.5.9.3 mudanças de uso e Casos ........................................................................................ 268
6.5.9.4 documentação de projeto .......................................................................................... 269
6.5.9.5 Manuais .................................................................................................................... 270
6,6 Serviço de Operação papéis e responsabilidades............................................... 271
6.6.1 Posto de Serviço papéis ....................................................................................... 271
6.6.1.1 Service Desk Manager .............................................................................................. 271
6.6.1.2 Supervisor de Service Desk ...................................................................................... 271
6.6.1.3 Posto de Serviço Analistas ........................................................................................ 272
6.6.1.4 Superusuários........................................................................................................... 272
6.6.2 Técnicas funções de gerenciamento .................................................................... 272
6.6.2.1 Os gerentes técnicos / ou chefes de equipa .............................................................. 272
6.6.2.2 Os analistas técnicos / Arquitetos .............................................................................. 273
6.6.2.3 Operador Técnico ..................................................................................................... 274
6.6.3 Operações de TI funções de gerenciamento ........................................................ 274

6.6.3.1 TI Gerente de Operações .......................................................................................... 274
6.6.3.2 Líderes Turno ........................................................................................................... 275
6.6.3.3 Operações de TI Analistas ........................................................................................ 275
6.6.3.4 Operadores de TI ...................................................................................................... 275
6.6.4 Gestão funções de aplicativo ................................................................................ 276
6.6.4.1 Aplicações Gerentes / ou chefes de equipa ............................................................... 276
6.6.4.2 Aplicações Analista / Arquiteto .................................................................................. 276
6.6.5 Gestão de papéis de Eventos ............................................................................... 277
6.6.5.1 O papel do Service Desk........................................................................................... 277
6.6.5.2 O papel do Técnico e Gerenciamento de Aplicativos ................................................. 278
6.6.5.3 O papel da TI Gestão de Operações ......................................................................... 278
6.6.6 Gestão de Incidentes papéis ................................................................................ 278
6.6.6.1 Gerente de Incidentes ............................................................................................... 278
6.6.6.2 Primeira linha ............................................................................................................ 279
6.6.6.3 de segunda linha....................................................................................................... 279
6.6.6.4 Terceira linha ............................................................................................................ 279
6.6.7 A realização de papéis Pedido ............................................................................. 280
6.6.8 Problema funções de gerenciamento ................................................................... 280
6.6.8.1 Gestor Problema ....................................................................................................... 280
6.6.8.2 resolução de problemas Grupos ................................................................................ 281
6.6.9 Acesso funções de gerenciamento ....................................................................... 281
6.6.9.1 O papel do Service Desk........................................................................................... 282
6.6.9.2 O papel do Técnico e Gerenciamento de Aplicativos ................................................. 282
6.6.9.3 O papel da TI Gestão de Operações ......................................................................... 283
6,7 Serviço Organização Estruturas de Operação .................................................... 284
6.7.1 Organização pela especialização técnica ............................................................. 284
6.7.2 Organização pela atividade .................................................................................. 286
6.7.3 Organização para gerenciar processos ................................................................ 288
6.7.4 Organização de Operações de TI por geografia ................................................... 289
6.7.5 híbridos estruturas de organização....................................................................... 292
6.7.5.1 Funções combinadas ................................................................................................ 293
6.7.5.2 Aplicação de Organização e Gestão Técnica ............................................................ 295
6.7.5.3 Geografia.................................................................................................................. 295
6.7.5.4 Técnica Combinada e estrutura de Gerenciamento de Aplicativos ............................. 296
7 considerações de tecnologia ........................................................................ 298
7,1 requisitos genéricos .............................................................................................. 299
7.1.1 Auto-Ajuda ............................................................................................................ 299
7.1.2 Fluxo de Trabalho ou processo motor .................................................................. 299
7.1.3 Integrado CMS...................................................................................................... 299
7.1.4 Descoberta de Implantação / / licenciamento de tecnologia ................................. 299
7.1.5 O controle remoto ................................................................................................. 300
7.1.6 utilitários de diagnóstico ....................................................................................... 300
7.1.7 Relatórios.............................................................................................................. 300
7.1.8 Dashboards .......................................................................................................... 301
7.1.9 Integração com o Business Service Management ................................................ 301
7.2 Gestão de Eventos ............................................................................................... 302
7,3 Gerenciamento de Incidentes............................................................................... 303
7.3.1 Integrado ITSM tecnologia.................................................................................... 303
7.3.2 Fluxo de Trabalho e escalonamento automatizado .............................................. 303
7,4 cumprimento Pedido ............................................................................................. 304
7,5 Gerenciamento de Problemas .............................................................................. 305
7.5.1 Integrated Service Management Technology ....................................................... 305
7.5.2 Gestão da Mudança ............................................................................................. 305
7.5.3 Integrado CMS...................................................................................................... 305
7.5.4 Banco de Dados Erro Conhecido ......................................................................... 305
7,6 Gerenciamento de Acesso ................................................................................... 307
7,7 Service Desk ......................................................................................................... 308

7.7.1 Telefonia ............................................................................................................... 308
7.7.2 Ferramentas de suporte ....................................................................................... 308
7.7.2.1 Banco de Dados Erro Conhecido .............................................................................. 309
7.7.2.2 os scripts de diagnóstico ........................................................................................... 309
7.7.2.3 interface web de Auto-Ajuda ..................................................................................... 309
7.7.2.4 O controle remoto ..................................................................................................... 310
7.7.3 Planejamento da Continuidade dos Serviços de TI para ferramentas de suporte
ITSM .............................................................................................................................. 311
8 considerações sobre a aplicação .................................................................. 312
8,1 mudança de gestão, em Operação de Serviço.................................................... 313
8.1.1 Mudança desencadeia.......................................................................................... 313
8.1.2 Avaliação de Mudança ......................................................................................... 313
8.1.3 Medição de mudança bem sucedida .................................................................... 314
8.2 Operação de Serviços e Gerenciamento de Projetos ......................................... 315
8,3 Avaliação de risco e gestão na Operação de Serviço ......................................... 316
8,4 pessoal operacional em Design de Serviços e Transição ................................... 317
8,5 Planejamento e implementação de tecnologias de gerenciamento de serviços 318
8.5.1 As licenças............................................................................................................ 318
8.5.1.1 licenças dedicados .................................................................................................... 318
8.5.1.2 licenças partilhadas................................................................................................... 318
8.5.1.3 licenças Web ............................................................................................................ 318
8.5.1.4 Serviço sob demanda ............................................................................................... 319
8.5.2 Implantação .......................................................................................................... 320
8.5.3 verifica a capacidade ............................................................................................ 320
8.5.4 O tempo de implantação de tecnologia ................................................................ 320
8.5.5 Tipo de introdução ................................................................................................ 321
9 Desafios, Fatores Críticos de Sucesso e riscos ............................................ 323
9,1 Desafios ................................................................................................................ 323
9.1.1 A falta de compromisso com a equipe de desenvolvimento e projeto .................. 323
9.1.2 financiamento Justificando.................................................................................... 324
9.1.3 Desafios para os Gestores operação de serviço .................................................. 324
9,2 Fatores Críticos de Sucesso ................................................................................ 327
9.2.1 Gestão de apoio ................................................................................................... 327
9.2.2 O apoio às empresas............................................................................................ 328
9.2.3 Campeões ............................................................................................................ 328
9.2.4 Recrutamento e retenção ..................................................................................... 329
9.2.5 formação em Gestão de Serviços......................................................................... 329
9.2.6 Ferramentas adequadas....................................................................................... 330
9.2.7 Validade dos testes .............................................................................................. 330
9.2.8 Medição e comunicação ....................................................................................... 331
9,3 Riscos ................................................................................................................... 332
9.3.1 Serviço de perda................................................................................................... 332
9.3.2 Os riscos para a operação de serviço de sucesso ............................................... 332
Posfácio........................................................................................................... 334
Apêndice A: orientações da indústria Complementar ...................................... 335
A1 COBIT .................................................................................................................... 336
A2 ISO / IEC 20000 .................................................................................................... 338
A3 CMMI ..................................................................................................................... 339
Balanced Scorecard A4 .............................................................................................. 339
A5 de Gestão da Qualidade ....................................................................................... 340
A6 ITIL eo Quadro OSI ............................................................................................... 340
Apêndice B: Comunicação na Operação de Serviço ....................................... 342
Comunicação B1 rotina operacional .......................................................................... 342
Comunicação B2 entre os turnos ............................................................................... 345

B3 Relato de Desempenho......................................................................................... 346
IT Performance Serviço ................................................................................................. 346
Equipe do Serviço de Operação ou desempenho departamento .................................. 348
Infra-estrutura ou o desempenho do processo .............................................................. 350
B4 Comunicação em projetos .................................................................................... 352
A comunicação relacionada com alterações B5 ........................................................ 354
B6 comunicação relacionada com exceções ............................................................. 356
Comunicação B7 relação às emergências................................................................. 358
B8 A comunicação com os usuários e clientes .......................................................... 360
Anexo C: Kepner Tregoe e .............................................................................. 362
C1 Definindo o problema ............................................................................................... 363
C2 Descrevendo o problema ......................................................................................... 363
C3 Estabelecer as possíveis causas ............................................................................. 363
C4 Testando a causa mais provável.............................................................................. 364
C5 Verificando a verdadeira causa ................................................................................ 364
Anexo D: Diagramas de Ishikawa .................................................................... 365
Apêndice E: Descrição detalhada de Gestão de Instalações ........................... 367
E1 Gestão de Edifícios ............................................................................................... 368
E2 Equipamentos de Hospedagem ............................................................................ 369
Gerenciamento de energia E3.................................................................................... 370
E4 condicionamento ambiental e sistemas de alerta................................................. 372
E5 Segurança ............................................................................................................. 374
E6 Controle de Acesso Físico .................................................................................... 374
E7 envio e recebimento .............................................................................................. 374
E8 Envolvimento em Gestão de Contratos ................................................................ 375
Manutenção E9 ........................................................................................................... 376
Anexo F: Controle de Acesso Físico ................................................................ 377
Glossário ......................................................................................................... 382
Lista de siglas ............................................................................................................. 382
Lista de definições ...................................................................................................... 386

Prefácio
Prefácio da OGC
Desde a sua criação, ITIL cresceu e se tornou a abordagem mais aceita para o
gerenciamento de serviços no mundo. No entanto, juntamente com este sucesso
vem a responsabilidade de assegurar que a orientação mantém o ritmo com um
ambiente de negócios em constante mudança global. Requisitos de
gerenciamento de serviços são inevitavelmente moldado pelo desenvolvimento
de tecnologia, modelos de negócios revistos e as expectativas dos clientes cada
vez maior. A nossa mais recente versão do ITIL foi criado em resposta a estes
desenvolvimentos.
Esta é uma das cinco publicações principais que descrevem as práticas de

gerenciamento de serviços de TI que compõem a ITIL. Eles são o resultado de
um projeto de dois anos para revisar e atualizar a orientação. O número de
profissionais de gerenciamento de serviços de todo o mundo que ajudaram a
desenvolver o conteúdo dessas publicações é impressionante. Sua experiência
e conhecimentos que contribuíram para o conteúdo para trazer-lhe um conjunto
consistente de alta qualidade orientação. Isto é apoiado pelo desenvolvimento
contínuo de um sistema de qualificação abrangente, juntamente com formação
acreditada e consultoria.
Se você faz parte de uma empresa global, um departamento ou uma pequena

empresa, ITIL dá acesso a conhecimento de classe mundial de gestão de
serviços. Essencialmente, ele coloca os serviços de TI onde eles pertencem - no
centro de operações de negócios de sucesso.
Peter Fanning
Atuando Executivo
Office of Government Commerce

Prefácio Arquiteto Chefe
ITIL Service orientação Prática de Gestão está estruturado em torno do Ciclo de
Vida do Serviço. Comum em todo o ciclo de vida é a prática geral em si, que se
baseia em processos, funções, atividades, modelos organizacionais e de
medição, que, juntos, permitem IT Service Management (ITSM) para integrar
com os processos de negócio, fornecer valor mensurável e evoluir a indústria de
ITSM em frente na nossa busca da excelência no atendimento.
Em nenhum outro lugar do ITIL Service Lifecycle faz o efeito de como atuar
como prestadores de serviços tocar os clientes intimamente como operações de
serviços. Este é o lugar onde a estratégia, design, transição e melhorias são
entregues e apoiada em uma base dia-a-dia.
A publicação traz Operação de Serviço Gerenciamento de Serviços de vida para

o negócio, e a prestação de contas para a execução dos serviços, as pessoas
que os criam e da tecnologia que permite que eles são monitorados, controlados
e entregue nesta fase do Ciclo de Vida do Serviço.
Esta publicação vai ajudar a orientar-nos a todos para alcançar a excelência do

serviço e ver o valor de ITSM em uma ampla visão de negócios com foco dela.
Se você é novo para a prática de ITIL ou um profissional experiente, a
orientação nesta publicação irá expandir sua visão e conhecimento de como ser
o provedor de serviços de best-of-breed, através da implementação de
Operação de Serviço.
Há um ditado que diz que a aprendizagem é 20/20. A orientação na Operação

de Serviço é destilado de mais de 20 anos de experiência em ITSM por
especialistas mundiais, empresários e profissionais de ITSM e as lições
aprendidas por eles sobre o serviço de excelência realmente é e como alcançá-
lo.
Qualquer pessoa envolvida em serviços de operação irá beneficiar da orientação

nas páginas seguintes desta publicação. Operação de Serviço oferece o melhor
aconselhamento e orientação de todo o mundo e um caminho para o que é
possível em seu futuro.
Sharon Taylor
Arquiteto Chefe, Práticas ITIL Service Management

Prefaciar
Esta publicação abrange e supera os aspectos operacionais do ITIL Service
Support e Service Delivery publicações e também cobre a maior parte do escopo
de Gestão TIC infra-estrutura. Ele também incorpora aspectos operacionais do
planejamento para implementar, gerenciamento de aplicações, gerenciamento
de ativos de software e publicações de Gestão de Segurança.
Os princípios básicos de boas práticas de serviços de TI de gestão enquadrada

no âmbito de versões anteriores do ITIL permanecem inalteradas. O senso
comum permanece o bom senso!
No entanto, as tecnologias, ferramentas e relações mudaram significativamente,

mesmo em período de tempo relativamente curto desde a última versão do ITIL
foi concluída. Embora esta publicação re-usos e atualizações material relevante
das versões anteriores se for caso disso, também inclui muitos novos conceitos
e práticas da indústria para dar cobertura completa de melhores práticas de
orientação para a Operação de hoje serviço em um único volume, para os
negócios de hoje e ambiente tecnológico .
Informações de contato
Todos os detalhes sobre a gama de material publicado sob a bandeira ITIL
podem ser encontradas em www.best-management-practice.com/itil
Se você gostaria de nos informar de quaisquer alterações que possam ser

necessárias para esta publicação por favor, registrá-los em www.best-
management-practice.com/changelog
Para mais informações sobre qualificação e acreditação da formação, visite

www.itil-officialsite.com. Alternativamente, favor contatar:
APMG Service Desk

Espada Casa
Totteridge Estrada
High Wycombe
Buckinghamshire
HP13 6DG
Tel: +44 (0) 1494 452450

E-mail: servicedesk@apmgroup.co.uk

Agradecimentos
Arquiteto-chefe e autores
Sharon Taylor (Aspect Group Inc) Arquiteto Chefe

David Cannon (HP) Autor
David Wheeldon (HP) Autor
ITIL autoria da equipe

O ITIL equipe de criação contribuiu para este guia através de comentários sobre
o conteúdo e alinhamento em todo o conjunto. Então, graças também são
devidos a outros autores do ITIL, especificamente Jeroen Bronkhorst (HP), Gary
Case (Pink Elephant), Ashley Hanna (HP), Majid Iqbal (Carnegie Mellon
University), Shirley Lacy (ConnectSphere), Vernon Lloyd (Fox IT ), Ivor
Macfarlane (Guillemot Rock), Michael Nieves (Accenture), Stuart Rance (HP),
Colin Rudd (itens) e George Spalding (Pink Elephant).
Mentores
Christian Nissen e Paul Wilkinson
Outras contribuições
Um número de pessoas contribuíram generosamente seu tempo e conhecimento para esta
publicação operação de serviço. Jim Clinch, como OGC Gerente de Projeto, agradece o apoio
prestado pela HP para a equipe de criação no desenvolvimento desta publicação e,
particularmente, a contribuição de Peter Doherty e Stroud Robert, e para o apoio de Jenny
Dugmore, Convenor do Grupo de Trabalho ISO / IEC 20000, Janine Eves, Carol Hulm, Aidan
Lawes e Michiel van der Voort.
Os autores também gostariam de agradecer a Stuart Rance e Ashley Hanna, da Hewlett-

Packard, Christian F Nissen (Itilligence), Maria Jarra (Itilligence), Eu Jin Ho (UBS), Jan
Bjerregaard, (Sun Microsystems), Jan Oberg (Oberg Parceiros ), Lars Zobbe Mortensen (Zobbe
Consult & Zoftware), Mette Nielsen (Carlsberg TI), 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 e Nenen Ong da Hewlett-Packard TI, Jaye Thompson, Dee Seymour,
Andranik Ziyalyan, Young Chang, Lauren Abernethy, abril McCowan, Becky Wershbale, Rob
Garman, Scott McPherson, Sandra de panificação, Rick Streeter, Leon Gantt, Charlotte Devine,
Greg Algorri, Maria Fischer, Bill Thayer e Diana Osberg da Empresa The Walt Disney Company
de TI, Dennis Deane e João Sowerby da DHL, Richard Fahey e Chris Hughes de Serviços de
Entrega Global da HP Aplicação, Cindi Locker e Dhiraj Gupta da Companhia Progressive
Casualty Insurance, Peter Doherty e Robert Stroud, da Computer Associates e Tillston Paulo da
Hewlett-Packard, Brian Jakubec, Vernon Blakes, Angela Chin, Colin Lovell , Ken Hamilton, Rose

Lariviere, Jenny McPhee, Tom Nielsen, Roc Paez, Lloyd Robinson, Paul Wilmot, Jeanette e Ken
Smith Wendle da Hewlett-Packard.
A fim de desenvolver práticas de gestão ITIL Service para refletir as melhores práticas actuais e
produzir publicações de valor duradouro, OGC amplas consultas com as diferentes partes
interessadas em todo o mundo em todas as fases do processo. OGC também gostaria de
agradecer às seguintes pessoas e suas organizações, por suas contribuições à orientação
refrescante ITIL a:
O ITIL Grupo Consultivo

Pippa Bass, OGC; Tony Betts, Independente; 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-Consultores , João Gibert,
Independente; Colin Hamilton, RENARD Consulting Ltd; Lex Hendriks, EXIN; Carol Hulm, British
Computer Society-ISEB; Tony Jenkins, DOMAINetc; Phil Montanaro, EDS; Alan Nance,
ITpreneurs; Christian Nissen, Itilligence; Página Don, Marval Grupo; Bill Powell, IBM; Sergio
Rubinato Filho, CA; James Siminoski, SOScorp; Robert E. Stroud, CA; Jan van Bon, informe-IT;
Ken Wendle, HP, Paul Wilkinson, Getronics PinkRoccade; Takashi Yagi, Hitachi.
Revisores
Jorge Acevedo, Computec SA; Balaji Alapilla; Valerie Arraj, INTEQ; Colin Ashcroft, Cidade de
Londres, William Bagley, Amgreetings; Martijn Bakker, Getronics PinkRoccade; Jeff Bartrop, BT
& Atendimento ao Cliente direto; Rajesh Basava Amatyappa Bellary, Satyam, John Bennett ,
Centram Ltd; Ian Bevan, Fox IT, Enrico Boverino, CA; Bart Van Brabant, Post; Ronald Browning,
CA; Stephen Bull, Serra de Sistemas; Bradley Busch, InTotality; Howard Carpenter, IBM; Liang
Cheng, IBM, John Clark, HP; Nicole Conboy, Nicole Conboy & Associates; Sharon Dale, Aquip
Internacional; Sandra Daly, Dawling Consultoria; Tony Domínio, Blue Yonder, Michael Donahue,
IBM; Ken Doughty, André J. Emmell, DKMStech; Matthew Evans, Processo Worx, Juan Antonio
Fernandez, Quint Wellington Redrood; Karen Ferris, proativa Serviços; Juan José Figueiras,
Globant; Liz Gallacher; Rae Garrett, Pink Elephant, Klaus Goedel, HP; David Gooda, Genesys
Consultoria; Detlef Gross, Automação Consulting Group GmbH; Matthias Hall, Universidade de
Dundee, John Hannan, melhores práticas de TI; Jonas Hansen, MMIT; Oliver Hast, Scoops; Jabe
Hickey, IBM; Graham Hill, Metisc; Kevin Hite, Microsoft; Sergio Hrabinski, Xelere; Scott Jaegar,
Plexant; Chris Jay; Chunyang Jia, Microsoft; Masthan Kadhar Kadhar, Cognizant, Tony Kelman-
Smith, HP; Peter Koepp, Independente; Joanne Kopcho, a Capgemini América; Rene van Kuijen;
Debbie Langenfield, IBM; Horacio Laprea; Sarah Lascelles, Interserve Projeto Services Ltd, Peter
Loos , Accenture Services GmbH, Marcos Lopez, da Microsoft; Emmanuel Marchand, Advens;
James Marmion, Yell Group, Jesus Martin, Ibermatica SA; Luis Moran, Independente; Steve
Morgan, KPMG; Ron Morton, HP; Philip Mougis, TCS; Richard Mulholland, IBM; Ron Muns, IDH;
Darren Murtagh, Retravision; Krisna Nugraha, Cleon Consultoria; Shuichi Owa, Niandc; Sampo
Pasanen, Efecte; Rodrigo Pementa, Pink Elephant, Eddy Peters, CTG; Steve Phelan, Lua
Macaco; Carol Piccus, CA; Poul Mols Poulsen, Coop Norden TI; Roger Purdie, A Arte de Serviço;
Glen Ralph, iCore Ltd; Padmini Ramamurthy, Satyam Computer Services Ltd; Keith Reynolds,
NSS Consultoria; Manfred Rieder, HP; Stephanie Roddy, Camelot Group; Mieke Roelens, CTA;
Frances Scarff, OGC; Markus Schiemer, a Unisys; Barbara Schiesser, Swiss TIC; Klaus Seidel,
Microsoft; Migel Sergey; Mamak Shafai; Prakash Sharma; Gilbert Silva, Techbiz Informatica Ltd;
Jim Siminoski, Soscorp; Dierk Soellner, Mod-gruppe , José Estêvão, do Departamento de
Transportes, Governo dos EUA; Michala Sterling, Mid Sussex Conselho Distrital; Helen Sussex,
Logic ACMG; Rohan Thuraisingham, Friends Provident Management Services Ltd, Mateus
Tolman, Sandvik, Cheryl Tovizi, MWH Global; Frank Victor, Victor GmbH ; Corde Wagner;
Christoph Wettstein, CLAVIS KLW AG; Andi Wijaya, IBM; Aaron Wolfe, Pink Elephant, Mike
Yang, IBM; Younghoon Youn, IBM.

1 Introdução
Esta publicação fornece as melhores práticas de aconselhamento e orientação
sobre todos os aspectos da gestão do dia-a-dia operação de uma organização
de tecnologia da informação (TI). Abrange questões relacionadas com as
pessoas, processoes de tecnologia, infra-estrutura e relaçãos necessária para
garantir a elevada qualidade, o fornecimento eficaz de Serviços de TI necessário
para atender às necessidades de negócio.
O advento de novas tecnologias e as linhas ténues entre agora os silos de

tecnologia tradicionais de hardware, redes, telefonia e software aplicaçãos
gestão significa que uma abordagem atualizada para a gestão operação de
serviços é necessária. Organizaçãos estão cada vez mais propensos a
considerar formas de prestação de TI na sua melhor custar e flexibilidade, com a
introdução de utilidade TI, pay-per-use serviços de TI, fornecimento de TI
virtuais, dinâmicas capacidade e Adaptive Enterprise Computing, bem como em
tarefas de abastecimento e terceirização opções.
Estas alternativas têm levado a uma miríade de relações de negócios de TI,

tanto interna como externamente, que aumentaram em complexidade, tanto
quanto as tecnologias que estão sendo gerenciados têm. Negócio dependência
sobre essas relações complexas é cada vez mais crítico para a sobrevivência e
prosperidade.

1.1 Visão Geral
Operação de Serviço é a fase em ITSM Ciclo de Vida que é responsável por
"business-as-usual" atividades.
Operação de Serviço pode ser visto como a "fábrica" de TI. Isto implica um
maior foco nas atividades do dia-a-dia e infra-estrutura que são utilizados para
prestar serviços. No entanto, esta publicação é baseada no entendimento de
que o objetivo primordial da Operação de Serviço é para entregar e suportar
serviços. Gestão da infra-estrutura ea operacional atividades devem sempre
apoiar esta finalidade.
Processos bem planejados e implementados será em vão se a operação do dia-

a-dia desses processos não é bem conduzido, controlado e gerenciado. Nem
será serviço melhorias será possível se dia-a-dia para monitorizar atuação,
Avaliar métricos dados e recolher não são sistematicamente realizadas durante
a Operação de Serviço.
Operação equipe de serviço deve dispor de processos e ferramentas de apoio

que lhes permitam ter uma visão global da operação de serviço e de entrega (e
não apenas a parte componentes, como o hardware, aplicações de software e
redes, que compõem o fim-de-final serviço a partir de um perspectiva de
negócios) E para detectar quaisquer ameaças ou falhas de serviço qualidade.
Dado que os serviços podem ser fornecidos, no todo ou em parte, por um ou

mais parceiros /fornecedor organizaçãos, o Operação de Serviço ver de fim-de-
final serviço deve ser ampliada para abranger os aspectos externos de
prestação de serviços - e onde compartilhada necessária ou interface
processoes e são necessárias ferramentas para gerenciar fluxos de trabalho
inter-organizacionais.
Operação de Serviço não é nem uma unidade organizacional nem um único

processo - mas inclui vários funçãos e muitos processos e actividades, que
estão descritos nos Capítulos 4, 5 e 6

1,2 Contexto
1.2.1 Gestão de Serviços
TI é um termo comumente utilizado que muda de significado com o contexto. A

partir da perspectiva de primeira, TI sistemas, aplicaçãos e infra-estrutura são
componentes ou subconjuntos de um produto maior. Eles permitem ou são
incorporados em processos e serviços. A partir da segunda perspectiva, é uma
organização com seu próprio conjunto de capacidades e recursos. Organizações
de TI podem ser de vários tipos, tais como funções de negócios, unidades de
serviços partilhados e unidades de nível empresarial do núcleo.
A partir da terceira perspectiva, é uma categoria dos serviços utilizados pelas

empresas. Eles são tipicamente aplicações de TI e infra-estrutura que são
empacotados e oferecidos como serviços por organizações de TI interna ou
externa provedor de serviçoss. TI custars são tratados como despesas
comerciais. A partir da quarta perspectiva, é uma categoria de negócio ativoss
que fornecem um fluxo de benefícios para seus proprietários, incluindo, mas não
limitado a, lucros, receitas e lucro. Os custos de TI são tratados como
investimentos.
1.2.2 Boas práticas no domínio público
Organizações operar em ambientes dinâmicos com a necessidade de aprender

e se adaptar. Existe uma necessidade de melhorar atuação enquanto gestora
trade-offs. Sob pressão semelhante, clientes procuram vantagem de prestadores
de serviços. Eles perseguem estratégias de sourcing que melhor servem o seu
interesse próprio negócio. Em muitos países, as agências governamentais e
organizações sem fins lucrativos empresas têm uma propensão similar ao
terceirizar para o bem da operacional eficácia. Isso coloca uma pressão
adicional sobre os prestadores de serviços para manter uma vantagem
competitiva em relação às alternativas que os clientes possam ter. O aumento
em terceirização se particularmente expostas prestador de serviços internos à
concorrência incomum.
Para lidar com a pressão, organizações referência se contra colegas e procurar

para fechar lacunas em capacidades. Uma forma de fechar essas lacunas é a
adoção de boas práticas em toda a indústria. Existem várias fontes de boas
práticas, incluindo estruturas públicas, padrãos e do conhecimento de
propriedade de organizações e indivíduos (ver Figura 1.1).

Figura 1.1 Fonte de Prática Gestão de Serviços
Estruturas públicas e as normas são atraentes quando comparados com

conhecimento de propriedade:
• Conhecimento proprietário, está profundamente enraizado nas

organizações e, portanto, difícil de adotar, replicar ou transferir, mesmo
com a cooperação dos proprietários. Tal conhecimento é muitas vezes na
forma de conhecimento tácito que é indissolúvel e mal documentadas.
• Conhecimento proprietário é personalizado para o contexto local e as
necessidades específicas do negócio, a ponto de ser idiossincrático. A
não ser que os destinatários de tais conhecimentos têm correspondência
circunstâncias, o conhecimento não pode ser tão eficaz em uso.
• Proprietários de conhecimento proprietário esperam ser recompensados
por seus investimentos de longo prazo. Eles podem fazer tal
conhecimento disponível apenas em termos comerciais, por meio de
compras e licenciamento acordos.
• Publicamente disponíveis quadros e padrãos, tais como ITIL, Objetivos de
Controle para TI (COBIT), CMMI, eSCM-SP, PRINCE2,ISO 9000, ISO
20000 e ISO 27001 são validados através de um conjunto diversificado de
ambientes e situações, em vez de limitada experiência de um único
organização. Eles estão sujeitos a ampla rever através de várias
organizações e disciplinas. Eles são controlados por diversos conjuntos
de parceiros, fornecedors e concorrentes.
• O conhecimento das estruturas públicas é mais provável a ser
amplamente distribuído entre uma grande comunidade de profissionais
por meio de treinamento disponíveis publicamente e certificado. É mais
fácil para as organizações a adquirir tais conhecimentos por meio do
mercado de trabalho.

Ignorando estruturas públicas e padrões podem desnecessariamente colocar
uma organização em desvantagem. As organizações devem cultivar seu próprio
conhecimento proprietária em cima de um corpo de conhecimento baseado em
quadros públicos e padrões. Colaboração e coordenação entre as organizações
são mais fáceis com base compartilhada práticas e padrões.
1.2.3 ITIL e boas práticas em Gestão de Serviços
O contexto desta publicação é o ITIL Quadro como uma fonte de boas práticas
Serviço de Gestão de. ITIL é usado por organizações em todo o mundo para
estabelecer e melhorar as capacidades de gerenciamento de serviços. ISO / IEC
20000 fornece um padrão formal e universal para organizações que buscam ter
seus recursos de gerenciamento de serviço auditado e certificado. Enquanto a
norma ISO / IEC 20000 é um padrão a ser alcançado e mantido, ITIL oferece um
corpo de conhecimento útil para alcançar o padrão.
A Biblioteca ITIL tem o seguinte componentes:
• ITIL Core: melhores práticas de orientação aplicável a todos os tipos de

organizações que prestam serviços a uma empresa de
• ITIL Orientação complementar: um conjunto complementar de
publicações com orientações específicas para os setores da indústria,
tipos de organização, modelos operacionais e tecnologia arquiteturas.
O Core ITIL é composto por cinco publicações (ver Figura 1.2). Cada uma delas
fornece a orientação necessária para uma abordagem integrada, conforme
exigido pela norma ISO / IEC 20000 padrão especificação:
• Operação de Serviço
• Melhoria de Serviço Continuada.

Figura 1.2 ITIL Núcleo
Cada publicação aborda as capacidades que têm impacto direto sobre um

serviço de provedor atuação. A estrutura do núcleo é na forma de um ciclo de
vida. Ele é interativo e multidimensional. Ele garante que organizaçãos são
criados para alavancar as capacidades em uma área de aprendizagem e
melhorias em outras. O Núcleo é esperado para dar estabilidade, estrutura e
força para Serviço de Gestão de capacidades, com duráveis princípios, métodos
e ferramentas. Isso serve para proteger os investimentos e proporcionar a base
necessária para a aprendizagem, medição e melhoria.
A orientação em ITIL pode ser adaptado para as mudanças de uso em vários

negócios ambientes e estratégias organizacionais. Orientação Complementar
fornece flexibilidade para implementar o núcleo em uma variada gama de
ambientes. Os médicos podem seleccionar Orientação Complementar conforme
necessário, para proporcionar tracção para o núcleo num contexto comercial
determinada, tanto quanto os pneus são seleccionados com base no tipo de
finalidade do automóvel, e as condições da estrada. Isto é para aumentar a
durabilidade e a portabilidade de conhecimento ativoss e proteger os
investimentos em capacidades de gerenciamento de serviços.

1.2.3.1 Estratégia de Serviço
O Estratégia de Serviço volume fornece orientação sobre como projeto,

Desenvolver e implementar o Gerenciamento de Serviço, não apenas como uma
organização capacidade mas também como um estratégico ativos. São
fornecidas orientações sobre os princípios subjacentes à prática de Gestão de
Serviços, que são úteis para o desenvolvimento de políticas de gerenciamento
de serviços, diretrizs e processoes entre o ITIL Serviço Ciclo de Vida. Orientação
Estratégia serviço é útil no contexto de Design de Serviços,Transição de
Serviço,Operação de Serviço e Melhoria de Serviço Continuada. Os tópicos
abordados na Estratégia de Serviço incluem o desenvolvimento dos mercados,
interno e externo, serviço ativos, catálogo de serviços e implementação de
estratégia através do Ciclo de Vida do Serviço. Gestão Financeira,Gestão de
Portfólio de Serviços, Desenvolvimento Organizacional e Estratégico Riscos
estão entre outros grandes temas.
Organizações usam a orientação para definir objetivos e expectativas de

desempenho para servir clientes e espaços de mercado e para identificar,
selecionar e priorizar oportunidades. Estratégia de Serviço se de garantir que as
organizações estão em uma posição para lidar com a custars e os riscos
associados ao seu portfólio de serviçoss e são criados não só para operacional
eficácia mas para o desempenho diferenciado. As decisões feitas em relação à
Estratégia de Serviço tem conseqüências de longo alcance, incluindo aqueles
com efeito retardado.
Organizações que já praticam ITIL usar este volume para orientar uma
estratégica rever de suas capacidades baseadas em ITIL Service Management e
melhorar o alinhamento entre esses recursos e suas estratégias de negócios.
Este volume de ITIL incentiva os leitores a parar e pensar sobre por que algo
está a ser feito antes de pensar em como fazer. Respostas para o primeiro tipo
de questões estão mais próximas de negócio do cliente. Estratégia de Serviço
expande o escopo do Quadro de ITIL além do público tradicional de profissionais
de ITSM.
1.2.3.2 Design de Serviços
O volume de Design de Serviços fornece orientação para a concepção e

desenvolvimento de serviços e processos de gerenciamento de serviços. Ele
abrange os princípios de design e métodos para converter objetivos estratégicos
em portfólios de serviços e bens de serviço. O âmbito do Design de Serviços
não se limita a novos serviços. Ele inclui as mudanças e melhorias necessárias
para aumentar ou manter valor para os clientes durante o ciclo de vida dos
serviços, a continuidade dos serviços, a realização de nível de serviços e
conformidade com padrãos e regulamentos. Ele orienta as organizações sobre
como desenvolver capacidades de design para Gerenciamento de Serviços.

1.2.3.3 Transição de Serviço
O Transição de Serviço volume fornece orientação para o desenvolvimento e

melhoria de capacidades para a transição de serviços novos e modificados em
operaçãos. Esta publicação fornece orientação sobre como o exigências de
Estratégia de Serviço codificados em Design de Serviços são efetivamente
realizados em Operações de Serviço ao controlar a riscos de fracasso e ruptura.
A publicação combina práticas em Gerenciamento de Liberação,Programa
Gestão e Gestão de Risco e coloca-os no contexto da prática de Serviço de
Gestão de. Ele fornece orientações sobre o gerenciamento da complexidade
relacionada a alterações nos serviços e gestão de serviços processoes, evitando
consequências indesejáveis, permitindo a inovação. Orientação é fornecida
sobre a transferência do controlar de serviços entre clientes e provedor de
serviçoss.
1.2.3.4 Operação de Serviço
Este volume incorpora práticas na gestão de Operação de Serviços. Inclui

orientação sobre a realização eficácia e eficiência na entrega e suporte de
serviços, de modo a garantir um valor para o cliente e o provedor de serviços.
Estratégico objetivos são, em última análise realizada através de operações de
serviços, portanto, tornando-se uma crítica capacidade. São fornecidas
orientações sobre como manter a estabilidade em operações de serviços, o que
permite mudanças de escala, design, escopo e níveis de serviço. Organizações
são fornecidos com processo detalhado diretrizs, métodos e ferramentas para
uso em dois grandes controle de perspectivas: reativa e pró-ativa. Gestores e
profissionais são fornecidos com o conhecimento que lhes permite tomar
melhores decisões em áreas como a gestão do disponibilidade de serviços, a
demanda controle, otimização capacidade agendamento de utilização, das
operações de fixação e problemas. São fornecidas orientações sobre operações
de apoio através de novos modelos e arquiteturas, tais como serviços
compartilhados, utilidade computação, serviços web e comércio móvel.
1.2.3.5 Melhoria de Serviço Continuada
Este volume oferece orientação instrumental na criação e manutenção de valor

para os clientes através de uma melhor projeto, Implantação e operação de
serviços. Ele combina os princípios, práticas e métodos de Qualidade Gestão,
Gestão da Mudança e Melhoria de Capacidade. Organizações aprender a
perceber melhorias incrementais e de larga escala em serviço qualidade,
operacional eficiência e continuidade dos negócios. Orientação é fornecida para
ligar os esforços de melhoria e resultados com Service Design de Serviços,
Estratégia e Transição de Serviço. A realimentação de circuito fechado sistema,
Com base no Plan-Do-Check-Act (PDCA) modelo especificado no ISO / IEC
20000, É estabelecido e capaz de receber entradas para mudar a partir de
qualquer planejamento perspectiva.

A gestão do dia-a-dia operacional da Serviços de TIs é significativamente
influenciado pela maneira como um organização'S estratégia geral de TI serviço
foi definido e quão bem os processos de ITSM foram planejadas e
implementadas. Esta é a quarta publicação no Gerenciamento de Serviços ITIL
série Práticas e as outras publicações sobre Estratégia de Serviço, Desenho de
Serviço e Transição de Serviço deve ser consultado para melhores práticas
orientação sobre esses importantes etapas anteriores à operação do serviço.
Operação de Serviço é extremamente importante, pois é no dia-a-dia

operacional que eventos ocorrer o que pode adversamente impacto qualidade
do serviço. A forma como uma organização Infra-estrutura de TI e seus
processos de apoio ITSM são operados terá mais direta e imediata influência de
curto prazo sobre serviço qualidade.

1,3 Propósito
Operação de Serviço é uma fase crítica do ITSM ciclo de vida. Bem planejado e
processos bem implementados será em vão se a operação do dia-a-dia desses
processos não é bem conduzido, controlado e gerenciado. Nem vai atender
melhorias será possível se dia-a-dia para monitorar atuação, Avaliar métricos
dados e recolher não são sistematicamente realizadas durante a Operação de
Serviço.
Operação equipe de serviço deve dispor de processos e ferramentas de apoio

que lhes permitam ter uma visão global da operação de serviço e de entrega (e
não apenas a parte componentes, tais como hardware, software aplicaçãos e
redes, que compõem o fim-de-final serviço a partir de uma perspectiva de
negócios) e para detectar qualquer ameaças ou falhas de serviço qualidade.
Dado que os serviços podem ser fornecidos, no todo ou em parte, por um ou

mais parceiros /fornecedor organizações, o Operação de Serviço vista de ponta
a ponta-de serviço deve ser estendido para abranger os aspectos externos de
prestação de serviços - e onde compartilhada necessária ou interface
processoes e são necessárias ferramentas para gerenciar fluxos de trabalho
inter-organizacionais.
1,4 Uso
Esta publicação deve ser usada em conjunto com as outras quatro publicações
que compõem o Serviço ITIL Ciclo de Vida.
Os leitores devem estar cientes de que a melhor prática diretrizs em volumes

este e outros não são destinados a ser prescritiva. Cada organização é único e
deve "adaptar e adotar" a orientação para suas próprias necessidades
específicas, ambiente e cultura. Isso envolverá tendo em conta a dimensão da
organização, competências /recursos, cultura, financiamento, prioridades e ITSM
existentes maturidade e modificando a orientação adequada para atender às
necessidades da organização.
Para as organizações encontrando ITIL, pela primeira vez, a forma inicial de

alguns avaliação comparar os processos atuais da organização e práticas com
as recomendadas pelo ITIL seria um ponto de partida muito valioso. Estas
avaliações são descritos em mais pormenor no ITIL Melhoria de Serviço
Continuada publicação.
Onde existem lacunas significativas, pode ser necessário para resolvê-los em

etapas ao longo de um período de tempo para atender às prioridades de negócio
da organização e manter o ritmo com o que a organização é capaz de absorver
e pagar

1,5 Visão geral do capítulo
Capítulo 2 introduz o conceito de Serviço de Gestão de como uma prática. Aqui,
Gerenciamento de Serviços está posicionada como uma estratégica e
profissional componente de qualquer organização. Este capítulo também fornece
uma visão geral da operação de serviço como um componente crítico da Prática
de Gestão de Serviços.
Os princípios fundamentais da operação de serviço são abordados no Capítulo 3

desta publicação. Estes princípios delinear alguns dos conceitos e princípios
básicos em que o restante da publicação se baseia.
Capítulo 4 abrange os processos realizados dentro de Operação de Serviço - a

maioria dos processos de operação de serviço são reativos devido à natureza do
trabalho a ser realizado para manter Serviços de TIs numa condição estável
robusto. Este capítulo também abrange processos proactivos de enfatizar que o
objetivo da Operação de Serviço é a estabilidade - mas não de estagnação.
Operação de Serviço deve ser constantemente procurando maneiras de fazer as
coisas melhor e de forma mais econômica, e os processos de dinamização têm
um papel importante a desempenhar aqui.
Capítulo 5 abrange uma série de atividades de serviços comuns de operação,

que são grupos de atividades e procedimentos realizadas por Funções operação
de serviço. Estes especializados, e muitas vezes técnicas, atividades não são
processos no verdadeiro sentido da palavra, mas todos eles são vitais para a
capacidade de oferecer qualidade de serviços de TI no ideal custar.
Capítulo 6 cobre os aspectos organizacionais da Operação de Serviço - os

indivíduos ou grupos que realizam processos de serviço de operação ou
atividades - e inclui algumas orientações sobre estruturas de organização de
serviços de Operação.
Capítulo 7 descreve as ferramentas e tecnologia que são usados durante a

Capítulo 8 aborda alguns aspectos da implementação que precisam ser

considerados antes da operacional fase do ciclo de vida torna-se ativa.
Capítulo 9 destaca os desafios, Fatores Críticos de Sucesso e riscos enfrentou

durante Operação de Serviço, Enquanto o Posfácio resume e conclui a
publicação.
ITIL não está sozinha na prestação de orientação para os gestores de TI e os

apêndices delinear algumas das estruturas complementares fundamentais,
metodologias e abordagens que são comumente usados em conjunto com ITIL
durante Operação de Serviço

2 Gerenciamento de Serviço como uma prática
2.1 O que é Gerenciamento de Serviços?
Serviço de Gestão de é um conjunto de capacidades especializadas
organizacionais para o valor de clientes, sob a forma de serviços. As
capacidades de assumir a forma de funçãos e processoes para gerenciamento
de serviços ao longo de um ciclo de vida, Com especializações em
estratégia,projeto, Transição, operação e melhoria contínua. Os recursos
representam um serviço organização'S capacidade, Competência e confiança
para a ação. O ato de transformar recursos em serviços de valor está no centro
de Gerenciamento de Serviço. Sem esses recursos, uma organização de serviço
é meramente um conjunto de recursos que por si só tem relativamente baixo
valor intrínseco para os clientes.
Definição de Gerenciamento de Serviço
Service Management é um conjunto de capacidades especializadas

organizacionais para o valor aos clientes na forma de serviços.
Capacidades organizacionais são moldadas pelos desafios que eles terão de

superar. Um exemplo desta situação é como em 1950 Toyota desenvolvidas
capacidades únicas de superar o desafio de menor escala e capital financeiro
em relação aos seus rivais americanos. Toyota desenvolvidas novas
capacidades em engenharia de produção, gestão de operações e gestão
fornecedors para compensar sua incapacidade de pagar grandes estoques,
fazer componentes, produzir matérias-primas ou possuir as empresas que os
produzem. [Fonte: Magretta, Joan 2002. O que é gestão: Como funciona e por
que negócio é de todos. O Free Press.] Capacidades de gerenciamento de
serviços são igualmente influenciado pelos seguintes desafios que o distinguem
de outros serviços sistemas de criação de valor, tais como mineração,
manufatura e agricultura:
• Natureza intangível dos produtos de saída e intermediário de processos

de serviços: difícil de medir, controlar e validar (ou provar).
• A demanda está intimamente ligado com o cliente ativoss: Usuários e
ativos dos clientes, tais como processos, aplicaçãos, documentos e
transaçãos chega com a demanda e estimular a produção de serviços.
• Alto nível de contato para os produtores e consumidores de serviços:
tampão Pouca ou nenhuma entre o cliente, o front-office e back-office.
• A natureza perecível serviço saída e serviço capacidade: Não há valor
para o cliente de garantia da continuidade do fornecimento de consistente
qualidade. Provedores precisam garantir um suprimento constante de
demanda dos clientes.

No entanto, Serviço de Gestão de é mais do que apenas um conjunto de
capacidades. É também um profissional prática suportado por um extenso corpo
de conhecimento, experiência e habilidades. Uma comunidade global de
indivíduos e organizações dos setores público e privado promove seu
crescimento e maturidade. Esquemas formais existem para a educação,
formação e certificado de praticar organizações e indivíduos influenciar sua
qualidade. Indústria melhores práticasA pesquisa, acadêmica e formal padrãos
contribuir para o seu capital intelectual e tirar dele.
As origens do Gerenciamento de Serviço estão em empresas de serviços

tradicionais, tais como companhias aéreas, bancos, hotéis e empresas de
telefonia. Sua prática tem crescido com a adoção pelas organizações de TI de
uma abordagem orientada a serviços para gestão de TI aplicaçãoa infra-
estrutura e processos. Soluções para os negócios problemas e suporte para
negócios modelos, estratégias e operaçãos são cada vez mais sob a forma de
serviços. A popularidade de serviços partilhados e terceirização contribuiu para o
aumento do número de organizações que são provedor de serviçoss, incluindo
unidades organizacionais internas. Este, por sua vez, reforçou a prática de
Gestão de Serviços e, ao mesmo tempo imposta maiores desafios em cima dele.

2.2 O que são serviços?
2.2.1 O valor proposição
Definição de serviço
Um serviço é um meio de entregar valor aos clientes, facilitando resultados

clientes querem alcançar, sem a posse de determinado custars e riscos.
Os serviços são um meio de entregar valor aos clientes, facilitando os resultados

que os clientes querem alcançar, sem a posse de custos e riscos específicos.
Serviços de facilitar os resultados através do aumento da atuação associado de
tarefas e a redução do efeito de restrições. O resultado é um aumento na
probabilidade de resultados desejados.
Figura 2.1 Uma conversa sobre a definição e significado de serviços

2.3 Funções e processos em todo o ciclo de vida
2.3.1 Funções
Funçãos são unidades de organizações especializadas para executar certos

tipos de trabalho e responsável pela específico resultados. Eles são auto-
suficientes, com capacidades e recursos necessária para a sua atuação e os
resultados. Os recursos incluem métodos de trabalho interno para as funções.
Funções têm seu próprio corpo de conhecimentos, que se acumula com a
experiência. Eles fornecem estrutura e estabilidade para as organizações.
Funções são um meio de estruturar as organizações, de modo a implementar o

princípio da especialização. Funções normalmente definem papels ea autoridade
associado e responsabilidade para um desempenho específico e os resultados.
Coordenação entre funções através compartilhada processoes é um padrão
comum na organização projeto. Funções tendem a otimizar seus métodos de
trabalho a nível local, para se concentrar nos resultados atribuídos. Fraca
coordenação entre as funções, combinados com um foco para dentro, leva a
silos funcionais que impedem o alinhamento e feedback crítico para o sucesso
do organização como um todo. Processo modelos ajudar a evitar esse problema
com hierarquias funcionais, melhorando a coordenação inter-funcional e
controlar. Processos bem definidos pode melhorar a produtividade dentro e
através de funções.
2.3.2 Processos
Processos são exemplos de circuito fechado sistemas, pois fornecem mudar e

de transformação para um objetivo e utilizar o feedback para a auto-reforço e
auto-ação corretiva (ver Figura 2.2). É importante levar em consideração todo o
processo, ou como um processo encaixa outra.
Figura 2.2 Um processo básico

Definições de processos descrevem ações, dependências e seqüência.
Processos de ter as seguintes características:
• Mensuráveis: Nós somos capazes de medir o processo de uma maneira

relevante. É o desempenho conduzido. Os gerentes querem medir
custar,qualidade e outras variáveis, ao passo que os profissionais estão
preocupados com a duração e a produtividade.
• Resultados específicos: A razão de um processo existe é entregar um
resultado específico. Este resultado deve ser individualmente
identificáveis e contáveis. Enquanto podemos contar mudanças, é
impossível contar quantas Service Desks foram concluídas.
• Clientes: Todo processo de entrega de seus resultados primários para um
cliente ou das partes interessadas. Elas podem ser internas ou externas à
organização, mas o processo tem de satisfazer as suas expectativas.
• Responde a um específico evento: Enquanto um processo pode ser
contínuo ou iterativo, deve ser feita com um gatilho específico.
As funções são muitas vezes confundidos com os processos. Por exemplo,

existem conceitos errados sobre Gerenciamento da Capacidade ser um Serviço
de Gestão de processo. Primeiro, Gerenciamento da Capacidade é uma
organização capacidade com processos especializados e métodos de trabalho.
Quer se trate de uma função ou de um processo depende inteiramente o projeto
de organização. É um erro supor que Gerenciamento da Capacidade pode ser
apenas um processo. É possível medir e controlar capacidade e para determinar
se ele é adequado para um determinado fim. Assumindo que é sempre um
processo, Com contável discreto resultados, pode ser um erro.
2.3.3 Especialização e coordenação em todo o ciclo de vida
Especialização e coordenação são necessários no ciclo de vida abordagem.

Feedback e controle entre o funçãos e processos dentro e entre os elementos
do ciclo de vida de tornar isso possível. O padrão dominante do ciclo de vida é o
progresso seqüencial a partir de SS através SO-SD-ST e volta a SS por meio de
CSI. No entanto, esse não é o único padrão de acção. Cada elemento do ciclo
de vida fornece pontos de feedback e controle.
A combinação de múltiplas perspectivas permite uma maior flexibilidade e

controle em ambientes e situações. A abordagem do ciclo de vida imita a
realidade da maioria das organizações onde a gestão eficaz requer a utilização
de múltiplas controle de perspectivas. Os responsáveis pela
projeto,desenvolvimento e melhoria de processos para Serviço de Gestão de
pode adotar uma perspectiva de controle baseada em processos. Os
responsáveis pela gestão acordos, contratos e serviços pode ser melhor servido
por uma perspectiva de controle do ciclo de vida baseado em fases distintas.
Ambos controle benefício perspectivas de sistemas pensando. Cada perspectiva
de controle pode revelar padrões que podem não ser evidentes a partir do outro.

2.4 Operação fundamentos Serviço
2.4.1 Finalidade objetivo / / objetivo
O objectivo da Operação de Serviço é coordenar e executar as atividades e

processos necessários para fornecer e gerenciar serviços em níveis acordados
para os negócios usuários e clientes. Operação de Serviço é também
responsável pela gestão contínua da tecnologia que é usada para entregar e
suportar serviços.
Processos bem desenhados e bem implementado será de pouco valor se o dia-

a-dia operação desses processos não é bem conduzido, controlado e
gerenciado. Nem será serviço melhorias será possível se dia-a-dia para
monitorizar atuação, Avaliar métricos dados e recolher não são
sistematicamente realizadas durante a Operação de Serviço.
2.4.2 Âmbito
Operação de Serviço inclui a execução de todas as actividades em curso

exigidos para entregar e suportar serviços. O escopo de Operação de Serviço
inclui:
• Os próprios serviços. Qualquer atividade que faz parte de um serviço

está incluído na Operação de Serviço, quer seja executado pela
Prestadora de Serviço, um externo fornecedor ou o usuário ou cliente
desse serviço
• Gestão de processos de serviços. O gerenciamento e execução de
processos de gerenciamento de serviço são muitos realizada em
operação de serviço, apesar de uma série de processos de ITIL (como
Mudança e Gerenciamento de Capacidade) originam-se no Design de
Serviços ou Transição de Serviço fase do Serviço Ciclo de Vida, Eles
estão em usar continuamente em operação do serviço. Alguns processos
não são incluídos especificamente na operação de serviço, tais como
Estratégia Definição, o projeto real do próprio processo. Esses processos
se concentrar mais no longo prazo planejamento e atividades de
melhoria, que estão fora do escopo direto de Operação de Serviço, no
entanto, Operação de Serviço fornece entrada e influencia estes
regularmente, como parte do ciclo de vida de Gerenciamento de Serviço.
• Tecnologia. Todos os serviços requerem alguma forma de tecnologia
para entregá-los. Gerenciando essa tecnologia não é uma questão
separada, mas uma parte integrante da gestão dos próprios serviços.
Portanto, uma grande parte desta publicação está preocupada com a
gestão da infra-estrutura utilizada para prestar serviços.
• Pessoas. Independentemente do que serviços, processoes e tecnologia
são geridos, todos eles são sobre pessoas. São as pessoas que dirigem a
demanda para o organização'S serviços e produtos e são as pessoas que

decidem como isso será feito. Em última análise, são as pessoas que
gerenciam a tecnologia, processos e serviços. A falha em reconhecer isto
irá resultar (e resultou) na falha de Serviço de Gestão de projetos
2.4.3 Valor para os negócios
Cada estágio no Serviço ITIL Ciclo de Vida fornece valor ao negócio. Por
exemplo, o valor do serviço é modelado em Estratégia de Serviço; O custar do
serviço é projetado, previsto e validado em Design de Serviços e Transição de
Serviço, E medidas para a otimização são identificados em Melhoria de Serviço
Continuada. O operação de serviço é onde estes planos, projetos e otimizações
são executados e medidos. A partir de um cliente ponto de vista, Operação de
Serviço é onde o valor real é visto.
Há um lado para baixo a este, no entanto:
• Uma vez que o serviço foi projetado e testado, é esperado para executar
dentro do orçamento e Retorno sobre Investimento metas estabelecidas
no início do ciclo de vida. Na realidade, porém, muito poucas
organizações planejar de forma eficaz para os custos de gestão contínua
dos serviços. É muito fácil de quantificar os custos de um projeto, mas
muito difícil de quantificar o que o serviço vai custar depois de três anos
de funcionamento.
• É difícil de obter, durante o financiamento operacional fase, para corrigir
projeto falhas ou imprevistos exigências - uma vez que este não fazia
parte da proposta de valor original. Em muitos casos, é apenas depois de
algum tempo de operação que estes problemas superfície. A maioria das
organizações não tem um mecanismo formal para rever serviços
operacionais para o projeto e valor. Isto é deixado para a Incidentes e
Gerenciamento de Problemas para resolver - como se ele é puramente
uma questão operacional.
• É difícil obter financiamento adicional para ferramentas ou ações
(incluindo formação), que visa melhorar a eficiência de Operação de
Serviço. Isto é em parte porque eles não estão diretamente ligadas ao
funçãoalidade de um serviço específico e em parte porque há uma
expectativa do cliente que estes custos deveriam ter sido construído no
custo do serviço desde o início. Infelizmente, a taxa da tecnologia mudar
é muito elevado. Pouco depois de uma solução foi implantada que vai
gerir eficazmente um conjunto de serviços, a nova tecnologia se torna
disponível, que pode fazê-lo mais rápido, mais barato e mais eficaz.
• Uma vez que um serviço está em funcionamento há algum tempo, torna-
se parte do linha de base do que a espera do negócio Serviços de TIs. As
tentativas de otimizar o serviço ou utilizar novas ferramentas para
gerenciá-lo de forma mais eficaz são vistos como bem-sucedido apenas
se o serviço tem sido muito problemática no passado. Em outras
palavras, alguns serviços são um dado adquirido e qualquer ação para

otimizá-los é percebido como "fixação de serviços que não estão
quebrados".
Esta publicação sugere uma série de processos, funções e medidas que visam
abordar essas áreas.
2.4.4 Otimização do desempenho do Serviço de Operação
Operação de Serviço é otimizard de duas maneiras:
• Longo prazo a melhoria incremental. Isto baseia-se na avaliação da

atuação e saída de todos os processos de operação de serviço, funçãos e
saídas ao longo do tempo. Os relatórios são analisados e uma decisão
sobre se a melhoria é necessária e, em caso afirmativo, qual a melhor
forma de implementá-lo através de Design de Serviços e Transição. Os
exemplos incluem o desenvolvimento de um novo conjunto de
ferramentas, as alterações processo projetos, a reconfiguração da infra-
estrutura, etc Este tipo de melhoria é abordado em detalhes na
publicação Melhoria de Serviço Continuada.
• Curto prazo, a melhoria contínua de trabalho práticas dentro dos
processos de serviço de operação, funções e tecnologia em si. Estes são
geralmente pequenas melhorias que são implementadas sem qualquer
alteração para a natureza fundamental de um processo ou de tecnologia.
Exemplos incluem afinação,carga de trabalho equilíbrio, reafectação de
pessoal e formação, etc
Embora ambos estes são discutidos em detalhe dentro do escopo de Operação

de Serviço, o Melhoria de Serviço Continuada publicação proporcionará um
quadro e alternativas em que a melhoria pode ser conduzido como parte do
apoio global da objetivo de negócios.
2.4.5 Processos dentro de Operação de Serviço
Há uma série de Operação de Serviço chave processoes que devem ligar em

conjunto para proporcionar uma estrutura de suporte eficaz geral IT. A estrutura
geral é brevemente descrito aqui e, em seguida, cada um dos processos é
descrito em mais detalhe no Capítulo 4.
2.4.5.1 Gestão de Eventos
Gestão de Eventos monitora todos eventos que ocorrem em todo o Infra-

estrutura de TI, Para monitorizar normais operação e para detectar e aumentar
as condições de exceção.
2.4.5.2 Incidentes e Gestão de Problemas

Gerenciamento de Incidentes concentra-se na restauração dos serviços
inesperadamente degradados ou interrompidos para usuários o mais
rapidamente possível, a fim de minimizar a actividade impacto.
Gerenciamento de Problemas envolve: análise de causa raiz para determinar e

resolver a causa da incidentes, atividades pró-ativas para detectar e prevenir
futuros problemas / incidentes e um Erro Conhecido sub-processo para permitir
o rápido diagnóstico e resolução se novos incidentes ocorrem.
2.4.5.3 Cumprimento de Requisição
Cumprimento de Requisição é o processo de tratamento com Solicitação de

Serviços - muitos deles realmente menor, de menorrisco, Mudanças -
inicialmente através da Service Desk, Mas utilizando um processo semelhante
ao que separado de Gerenciamento de Incidentes mas com Cumprimento
Pedido separado registros / tabelas - se necessário ligados ao incidente ou
Grave problema(S) que iniciou a necessidade para a solicitação. Para ser uma
solicitação de serviço, é normal que alguns pré-requisitos a serem definidos e
cumpridos (por exemplo, as necessidades de ser comprovada, repetível, pré-
aprovado, proceduralized).
A fim de resolver um ou mais incidentes, problemas ou erros conhecidos,

alguma forma de mudar pode ser necessária. Menor, muitas vezes padrão, as
alterações podem ser tratadas através de um processo de Cumprimento de
Requisição, mas maiores, mudanças de maior risco ou pouco frequentes devem
passar por um formal Gestão da Mudança processo.
2.4.5.4 Gerenciamento de Acesso
Gerenciamento de Acesso é o processo de concessão de autorização usuárioo

direito de usar um serviço, Limitando o acesso a usuários não-autorizados. Ele é
baseado em ser capaz de identificar com precisão os usuários autorizados e
gerenciar sua própria capacidade de acessar serviços como exigido durante as
diferentes fases de seus Recursos Humanos (RH) ou contratual ciclo de vida.
Gerenciamento de acesso também tem sido chamado de identidade ou Direitos
Gestão em algumas organizações.
2.4.6 Funções dentro de Operação de Serviço
Processos por si só não vai resultar em eficaz Operação de Serviço. Uma infra-
estrutura estável e adequadamente pessoas qualificadas são necessários
também. Para conseguir isso, Operação de Serviço depende de vários grupos
de pessoas qualificadas, todos focados em uso de processos para coincidir com
a capacidade da infra-estrutura às necessidades do negócio.

Estes grupos são classificados em quatro principais funçãos, aqui e discutido em
detalhes no Capítulo 6.
2.4.6.1 Service Desk
O Service Desk é o principal ponto de contato para os usuários quando há uma

interrupção do serviço, por Solicitação de Serviços, ou até mesmo para algumas
categorias de Requisição de Mudança. O Service Desk fornece um ponto de
comunicação com os usuários e um ponto de coordenação para vários grupos
de TI e processos
2.4.6.2 Gestão Técnica
Gestão Técnica fornece detalhadas habilidades técnicas e recursos necessários

para suportar o curso operação do Infraestrutura de TI. Gestão Técnica também
desempenha um papel importante na projeto, Testes, liberar e melhoria das
Serviços de TIs. Em pequenas empresas, é possível gerenciar essa experiência
em um único departamento, mas as grandes organizações são normalmente
dividida em vários departamentos especializados tecnicamente.
2.4.6.3 Gestão de Operações de TI
TI Gestão de Operações executa a diária operacional atividades necessárias

para gerenciar a infra-estrutura de TI. Isso é feito de acordo com o desempenho
Padrãos definido durante Design de Serviços. Em algumas organizações este é
um departamento único e centralizado, enquanto em outros algumas atividades
e funcionários são centralizados e alguns são fornecidos por departamentos
distribuídos ou especializada. Gestão de Operações de TI tem duas funções que
são únicas e são geralmente formais estruturas organizacionais. Estes são os
seguintes:
• Operações de TI Controle, O qual é geralmente composta por deslocars

de operadores e que assegura que as tarefas rotineiras operacionais são
realizadas. Controle de Operações de TI também irá fornecer centralizado
monitoramento e controlar actividades, geralmente usando uma
Operações Ponte ou Centro de Operações de Rede.
• Facilities Management refere-se à gestão da TI física ambiente,
Geralmente centros de dados ou salas de informática. Em muitas
organizações técnica e Aplicação de Gestão de são co-localizado com
Operações de TI em grandes centros de dados.
2.4.6.4 Gerenciamento de Aplicativos
Application Management é responsável pela gestão Aplicaçãos ao longo do seu

ciclo de vida. A função de gerenciamento de aplicativos suporta e mantém
aplicações operacionais e também desempenha um importante papel no projeto,

teste e melhoria de aplicações que fazem parte dos serviços de TI.
Gerenciamento de Aplicativos é geralmente dividida em departamentos com
base no portfólio de aplicativos do organização, Permitindo assim mais fácil de
especialização e de mais apoio focado.
2.4.6.5 Interfaces para outros estágios Serviço Lifecycle Management
Existem vários outros processos que serão executados ou apoiados durante

Operação de Serviço, Mas que são conduzidas durante outras fases do Serviço
de Gestão de Ciclo de Vida. Isto será discutido na parte final do capítulo 4 e
incluem:
• Gestão da Mudança, Que é um importante processo que deve estar

intimamente ligado ao Gerenciamento da Configuração e Gerenciamento
de Liberação. Esses tópicos são cobertos principalmente no Transição de
Serviço publicação.
• Capacidade e Gerenciamento de Disponibilidade, Que são abordados na
publicação Service Design.
• Gestão Financeira, Que é coberto no Estratégia de Serviço publicação.
• Gestão do Conhecimento, que é coberto na publicação Transição de
Serviço.
• Serviços de TI Continuidade, que é coberto no Design de Serviços
publicação.
• Serviço de Relatórios e Mensuração, que são cobertos no Melhoria de
Serviço Continuada publicação.

3 Operação princípios do serviço
Ao considerar Operação de Serviço é tentador focar apenas no gerenciamento
do dia-a-dia e tecnologia como um fim em si mesmos. No entanto, Operação de
Serviço existe dentro de um contexto muito maior. Como parte do Ciclo de Vida
do Gerenciamento de Serviços, é responsável pela execução e realização de
processos que otimizar o custar e qualidade de serviços. Como parte do
organização, É responsável por permitir o negócio para cumprir o seu objetivos.
Como parte do mundo da tecnologia, que é responsável pelo bom
funcionamento do componentes que os serviços de apoio. Os princípios deste
capítulo são destinadas a ajudar os praticantes operação de serviço para atingir
um equilíbrio entre todos estes papels e se concentrar em gerir eficazmente os
aspectos do dia-a-dia, mantendo uma perspectiva de um contexto maior.

3,1 Funções, grupos, equipes, departamentos e divisões
A publicação Operação de Serviço usa vários termos para referir-se a maneira
pela qual as pessoas estão organizadas para executar processos ou atividades.
Existem várias definições publicadas para cada termo e não é o propósito desta
publicação para entrar no debate sobre qual é a melhor definição. Por favor,
note que as definições a seguir são genéricas e não prescritivos. Eles são
fornecidos apenas a definir os pressupostos e para facilitar a compreensão do
material. O leitor deve adaptar esses princípios para a organização práticas
usado em sua própria organização.
• Função: Uma função é um conceito lógico que se refere ao povo e

medidas automatizadas que executam um processo definido, uma
atividade ou uma combinação de processos ou atividades. Em
organizações maiores, uma função pode ser dividido e realizado por
diversos departamentos, equipes e grupos, ou pode ser incorporado
dentro de uma única unidade organizacional (por exemplo, Service Desk).
Em organizações menores, uma pessoa ou grupo pode executar múltiplas
funções - por exemplo, um Gestão Técnica departamento pode também
incorporar a função de Service Desk.
• Grupo: Um grupo é um número de pessoas que são, de algum modo
semelhante. Nesta publicação, os grupos se referem a pessoas que
desempenham atividades semelhantes - embora eles possam trabalhar
em tecnologia diferente ou relatório em diferentes estruturas
organizacionais ou mesmo em empresas diferentes. Os grupos são
geralmente não formal organização estruturas, mas são muito úteis para
a definição de processos comuns em toda a organização - eg garantir que
todas as pessoas que resolver incidentes completar a Grave incidente da
mesma maneira. Nesta publicação "grupo" o termo não se refere a um
grupo de empresas que pertencem a uma mesma entidade.
• Equipe: Uma equipe é um tipo mais formal do grupo. Estas são as
pessoas que trabalham em conjunto para alcançar um comum objetivo,
Mas não necessariamente na estrutura mesma organização. Os membros
da equipe podem ser co-localizado, no trabalho ou em vários locais
diferentes e operar virtualmente. Equipes são úteis para a colaboração,
ou para lidar com uma situação de natureza temporária ou transitória.
Exemplos de equipes incluem projeto equipes, aplicação desenvolvimento
equipes (geralmente composto por pessoas de várias unidades de
negócios diferentes) e de incidentes ou problema resolução equipes.
• Departamento: Departamentos são estruturas de organização formal que
existem para executar um conjunto específico de atividades definidas em
uma base contínua. Departamentos têm uma estrutura de relatórios
hierárquica com os gestores, que geralmente são responsáveis pela
execução das atividades e também para o dia-a-dia de gestão do pessoal
do departamento.

• Divisão: Uma divisão refere-se a uma série de serviços que foram
agrupadas, muitas vezes por geografia ou linha de produtos. A divisão é
normalmente auto-suficiente e é capaz de planejar e executar todas as
atividades em um cadeia de suprimentos.
• Papel: Um papel refere-se a um conjunto de comportamentos ligados ou
ações que são realizadas por uma pessoa da equipe ou grupo em um
contexto específico. Por exemplo, um Gestão Técnica departamento de TI
pode desempenhar o papel de Gerenciamento de Problemas ao
diagnosticar o causa raiz de incidentes. Este mesmo departamento
também se podem esperar para jogar vários outros papéis em momentos
diferentes, por exemplo, pode avaliar a impacto das alterações (Gestão
da Mudança de papel), gerenciar a atuação de dispositivos sob seu
controle (papel Gerenciamento da Capacidade), etc A escopo do seu
papel e que desencadeia-los a desempenhar esse papel são definidos
pelo relevante processo e acordado por seu gerente de linha.

Alcançar 3,2 equilíbrio na Operação de Serviço
Operação de Serviço é mais do que apenas a execução repetitiva de um
conjunto padrão de procedimentos ou atividades. Todos funçãos, processos e
atividades são projetadas para fornecer um nível e acordado de serviços, mas
que tem que ser entregue em uma constante mudança ambiente.
Isso forma um conflito entre a manutenção do status quo e adaptação às

mudanças do negócio e ambientes tecnológicos. Um dos papéis fundamentais
serviço de operação é, portanto, para lidar com este conflito e para alcançar um
equilíbrio entre conjuntos conflitantes de prioridades.
Esta seção da publicação destaca algumas das principais tensões e conflitos e

identifica como as organizações de TI podem reconhecer que eles estão
sofrendo de um desequilíbrio, tendendo mais para um extremo ou outro. Ele
também proporciona algum alto nível diretrizs sobre a forma de resolver o
conflito e, assim, avançar para uma abordagem de melhores práticas. Cada
conflito, portanto, representa uma oportunidade de crescimento e
aperfeiçoamento.
3.2.1 TI interna ver contra vista de negócios externo
O conflito mais fundamental em todas as fases do ITSM Ciclo de Vida é entre a

visão de TI como um conjunto de serviços de TI (a visão empresarial externo) ea
visão de TI como um conjunto de tecnologia componentes (TI interna ver).
• A visão externa de TI é a forma como os serviços são experimentados por

sua usuários e clientes. Eles nem sempre entendem, nem se preocupam
com os detalhes do que a tecnologia é usada para gerenciar esses
serviços. Todos eles estão preocupados é que os serviços sejam
entregues conforme necessário e acordado.
• A visão interna de TI é a maneira pela qual os componentes de TI e
sistemas são geridas para realizar os serviços. Desde sistemas de TI são
complexas e diversas, isso muitas vezes significa que a tecnologia é
gerida por várias equipes ou departamentos diferentes - cada um dos
quais está focado em alcançar um bom atuação e disponibilidade de
sistemas de 'suas'.
Ambas as visões são necessárias quando a prestação de serviços. O

organização que se concentra apenas em negócios exigências sem pensar
sobre como eles estão indo entregar vai acabar fazendo promessas que não
possam ser mantidos. A organização que se concentra apenas em sistemas
internos, sem pensar sobre quais os serviços que suportam vai acabar com
serviços caros que oferecem pouco valor.

O potencial para a papel conflito entre as vistas externas e internas é o resultado
de muitas variáveis, incluindo o maturidade da organização, a sua gestão
cultura, Sua história, etc Isso faz com que um equilíbrio difícil de conseguir, ea
maioria das organizações tendem mais para um papel que o outro.
Naturalmente, nenhuma organização será totalmente internamente ou
externamente focado, mas encontra-se numa posição ao longo de um espectro
entre os dois. Isto é ilustrado na Figura 3.1:
Figura 3.1 Atingir um equilíbrio entre o foco externo e interno
A Tabela 3.1 resume alguns exemplos das características de posições extremas

nas extremidades do espectro. O objetivo desta tabela é para ajudar as
organizações a identificar para não que eles estão mais próximos extrema, para
identificar vida real cargos para os quais as organizações devem aspirar.
Foco interno extrema Foco externo extrema
Foco principal Desempenho e gestão de Atingir elevados níveis de desempenho

Infraestrutura de TI dispositivos, de TI serviço com pouco respeito às
sistemas e pessoal, com pouca como ele é alcançado
consideração para o resultado final
na De serviços de TI
Métricos • Foco no desempenho • Focalizar Externa Metrics sem

técnico, sem mostrar o que mostrar o pessoal interno como
isso significa para os estes são derivados ou como
serviços de eles podem ser melhorados
• Interna métricas (por • Pessoal interno são esperados
exemplo, a disponibilidade para elaborar as suas próprias
da rede) informou ao métricas para medir o
negócio, em vez de serviço desempenho interno.
atuação métricas.

Cliente/usuário • Alta consistência da • Consistência pobres de
experiência entrega, mas apenas entrega
oferece uma porcentagem • "Ele consiste de boas pessoas
do que a empresa precisa. com boas intenções, mas nem
• Usa um "empurrão" sempre pode executar '
abordagem para a entrega, • De modo reativo operação.
ou seja, prefere ter um • Usa um "pull" abordagem para
conjunto padrão de a entrega, ou seja, prefere
serviços para todos oferecer serviços
unidade de negócioss. personalizados a pedido
Operações • Operações padrão em toda • Várias equipes de entrega e

estratégia a linha tecnologias múltiplas
• Todos os novos serviços • As novas tecnologias exigem
precisam se encaixar no abordagens novas operações
atual arquitetura e e, muitas vezes nova
procedimentos. Operações de TI equipes.
Procedimentos Concentre-se puramente em como Concentra-se principalmente sobre o

e manual gerenciar a tecnologia, não sobre que precisa ser feito e quando e menos
como o seu desempenho se refere em como isso deve ser alcançado
aos serviços de TI
Estratégia de • A redução de custos • Orçamento alocados com base

custo alcançada puramente por na qual a unidade de negócios
meio da consolidação de é percebida a ter maior
tecnologia necessidade
• Otimização de operacional • Unidades de negócio menos
procedimentos e recursos articulados ou vocal muitas
• Negócio impacto de custar vezes têm serviços inferiores
corte freqüentemente só como não há financiamento
entendeu depois suficiente alocado para os seus
• Retorno sobre o serviços.
Investimento cálculos estão
focados exclusivamente na
redução de custos ou
"períodos de retorno.
Treinamento O treinamento é realizado como um • O treinamento é realizado em

aprendizado, onde a equipe de um projetoA projecto base
Operações novo tem que aprender • Não há cursos de treinamento
a forma como as coisas têm de ser padrão desde operacional
feitas, por que não procedimentos e tecnologia
estão mudando
constantemente.
Equipe de • Pessoal especializado, • Equipe generalista, organizado

operações organizado de acordo com em parte de acordo com a
a especialidade técnica técnica capacidade e, em
• Equipe de trabalho no falso parte, de acordo com a relação

pressuposto de que a com unidade de negócios
realização técnico bom é o • Dependência de 'heroísmo',
mesmo que bom cliente onde os funcionários saem de
serviço. sua maneira de resolver
problemas que poderiam ter
sido evitadas por uma melhor
interna processoes.
Tabela 3.1 Exemplos de foco interno e externo extrema
Isto não quer dizer que a concentração externa não é importante. Todo o ponto
de Serviço de Gestão de é fornecer serviços que satisfaçam as objetivos da
organização como um todo. É crítico para os serviços de estrutura em torno
clientes. Ao mesmo tempo, é possível para comprometer a qualidade de
serviços por não pensar sobre como eles serão entregues.
Edifício Operação de Serviço com um equilíbrio entre o foco interno e externo

exige uma abordagem a longo prazo, dedicado refletida em todas as fases do
Serviço de ITSM Ciclo de Vida. Isso vai exigir o seguinte:
• Uma compreensão de que os serviços são utilizados pela empresa e por

quê.
• A compreensão da importância relativa e impacto desses serviços no
negócio.
• Um entendimento de como a tecnologia é utilizada para fornecer De
serviços de TIs.
• Envolvimento de Operação de Serviço em Melhoria de Serviço
Continuada projetos que visam identificar formas de entregar mais,
aumentar serviço qualidade e menor custar.
• Procedimentos e manuais que delineiam o papel de Operações de TI em
tanto a gestão da tecnologia e da entrega de serviços de TI.
• Um conjunto claramente diferenciada de métricos de informar a empresa
sobre a realização dos objectivos de serviço, e de informar os gestores de
TI na eficiência e eficácia de Operação de Serviço.
• Todos a equipe de TI Operações entender exatamente como o atuação
da tecnologia afeta a entrega de serviços de TI e, por sua vez como estas
afetam o negócio e os objetivos de negócio.
• Um conjunto de serviços padrão entregue de forma consistente a todos
Unidade de Negócioss e um conjunto de não-padrão (por vezes
personalizada) serviços prestados a unidades de negócios específicas -
junto com um conjunto de Procedimento Operacional Padrãos (POPs)
que pode satisfazer os dois conjuntos de exigências.
• Acustar estratégia que visa equilibrar as exigências de diferentes
unidades de negócio, com a redução de custos através da otimização
disponíveis da tecnologia existente ou o investimento em novas
tecnologias - e um entendimento da estratégia de custo por todos os
envolvidos TI recursos.

• Um valor-base, em vez de baseado em custo, Retorno sobre o
Investimento estratégia.
• Envolvimento de Operações de TI pessoal no Design de Serviços e
Transição de Serviço fases do ITSM Ciclo de Vida.
• Entrada de e feedback para Melhoria de Serviço Continuada para
identificar áreas onde há um desequilíbrio e os meios para identificar e
aplicar melhorias.
• A comunicação clara e treinamento plano para o negócio. Embora muitas
organizações são bons no desenvolvimento de planos de comunicação
para projetos, isso muitas vezes não se estende em sua operacional fase.
3.2.2 Estabilidade em relação a capacidade de resposta
Não importa o quão boa a funcionalidade é de um De serviços de TI e não

importa o quão bem ele foi concebido, será que vale muito menos se o serviço
componentes não estão disponíveis ou se realizar de forma inconsistente.
Isto significa que, Operação de Serviço necessidades para assegurar que a

Infraestrutura de TI é estável e disponível como projetado. Ao mesmo tempo,
operação de serviço precisa reconhecer que os negócios ea TI exigências
mudar.
Algumas dessas mudanças são evolutivas. Por exemplo, a funcionalidade,

atuação e arquitetura de uma plataforma podem mudar ao longo de vários anos.
Cada mudança traz consigo uma oportunidade de proporcionar melhores níveis
de serviço para o negócio. Em mudanças evolutivas, é possível planejar a forma
de responder à mudança e, assim, manter a estabilidade, respondendo às
mudanças.
Muitas mudanças, porém, acontecer muito rapidamente e às vezes sob extrema

pressão. Por exemplo, uma unidade de negócios inesperadamente ganha um
contrato que requer adicionais serviços de TI, mais capacidade e mais rápido
tempo de respostas. A capacidade de responder a este tipo de mudança, sem
afetar outros serviços é um desafio significativo.
Muitas organizações de TI não são capazes de alcançar este equilíbrio e tendem

a se concentrar em qualquer estabilidade da infra-estrutura de TI ou a
capacidade de responder às mudanças rapidamente.

Figura 3.2 Atingir um equilíbrio entre o foco na estabilidade e capacidade de
resposta
A Tabela 3.2 resume alguns exemplos das características de posições em

extremos do espectro. O objetivo desta tabela é para ajudar as organizações a
identificar para não que eles estão mais próximos extrema, para identificar vida
real cargos para os quais as organizações devem aspirar.
Foco extremo na estabilidade Foco extremo na resposta
Foco principal • Tecnologia • Saída para o negócio

• Desenvolvimento e • Concorda com as
aperfeiçoamento de técnicas alterações necessárias
de gestão de TI e processoes. antes de determinar o
que vai demorar para
entregá-los.
Típico problemas TI pode demonstrar que está A equipe de TI não estão

experimentado cumprindo com os POPs e Acordo de disponíveis para definir ou
Nível Operacionals (ANO), mesmo executar tarefas de rotina, porque
quando não há desalinhamento claro eles estão ocupados em projetos
para negócios exigências para novos serviços
Crescimento da • Estratégia de crescimento com • Tecnologia adquirida para

tecnologia base na análise da demanda cada requisito de novos
estratégia existente na actual sistemas negócios
• Novos serviços estão resistiu e • Usando múltiplas
Unidade de Negócioss vezes, tecnologias e soluções

tomar posse de "seus próprios para soluções
sistemas para ganhar acesso a semelhantes, para
novos serviços. atender às necessidades
de negócios ligeiramente
diferentes.
A tecnologia A tecnologia existente ou padrão a ser Mais de provisionamento.

utilizada para utilizado; serviços devem ser ajustadas Nenhuma tentativa foi feita para
entregar De para funcionar dentro de parâmetros modelar a nova serviço na infra-
serviços de TIs existentes estrutura existente. Tecnologia
nova e dedicada é adquirido para
cada novo projeto
Gerenciamento • Previsões com base em • Previsões com base em

da Capacidade projeções de corrente carga de negócios futuros atividade
trabalhos para cada serviço
• Sistema atuação é mantida em individualmente e não
níveis consistentes através levam em conta a
afinação e gestão da procura, atividade de TI ou outros
E não por previsão de carga serviços de TI
de trabalho e gestão. • Cargas de trabalho
existentes não são
relevantes.
Tabela 3.2 Exemplos de extremo foco na estabilidade e capacidade de resposta
A construção de uma TI organização que alcança um equilíbrio entre a

estabilidade e capacidade de resposta em Operação de Serviço exigirá as
seguintes ações:
• Garantir o investimento em tecnologias e processos que são adaptativas

ao invés de rígida, por exemplo, virtual servidor e aplicação tecnologia e
da utilização de Mudança do modelos (ver Transição de Serviço
publicação).
• Construir uma forte Gerenciamento de Nível de Serviço (SLM) processo
que está ativo a partir do Design de Serviços fase para a Melhoria de
Serviço Continuada fase do ITSM Ciclo de Vida.
• Promover a integração entre SLM e os processos de design de outros
serviços para garantir mapeamento adequado de requisitos de negócio
para TI operacional actividades e componentes da Infraestrutura de TI.
Isso torna mais fácil para modelar o efeito de mudanças e melhorias.
• Iniciar mudanças na primeira fase apropriada no Ciclo de Vida de ITSM.
Isso irá garantir que tanto funcional (de negócios) e capacidade de
gerenciamento (TI operacional) exigências pode ser avaliado e construído
ou alterado juntos.
• Garantir o envolvimento da TI no negócio muda tão cedo quanto possível
no mudar processo para assegurar escalabilidade, Consistência e
capacidade de concretização de De serviços de TIs sustentar mudanças
de negócios.

• Operação de Serviço equipes devem fornecer informações para o curso
projeto e refinamento da arquiteturas e serviços de TI (ver Design de
Serviços e Serviço de publicações estratégia).
• Implementar e usar SLM para evitar situações onde os negócios e os
gerentes de TI e pessoal de negociar informal acordos.
3.2.3 A qualidade do serviço versus custo do serviço
Operação serviço é necessário para entregar consistentemente o nível acordado

de serviços de TI para a sua clientes e usuários, enquanto que, ao mesmo
tempo mantendo custars e recurso utilização em um nível ideal.
Figura 3.3 representa o investimento realizado para entregar um serviço em

níveis crescentes de qualidade.
Figura 3.3 a qualidade do serviço de balanceamento e custo
Na Figura 3.3, um aumento do nível de qualidade geralmente resulta em um

aumento no custo do serviço, e vice-versa. No entanto, o relação nem sempre é
diretamente proporcional:
• Logo no início do serviço de ciclo de vida é possível conseguir aumentos

significativos na qualidade de serviço, com uma quantidade relativamente
pequena de dinheiro. Por exemplo, melhorar o serviço disponibilidade de
55% para 75% é bastante simples e não pode exigir um investimento
enorme.
• Mais tarde no ciclo de vida do serviço, mesmo pequenas melhorias na
qualidade são muito caros. Por exemplo, melhorar a disponibilidade do

mesmo serviço de de 96% para 99,9% pode exigir grandes investimentos
em tecnologia de alta disponibilidade e pessoal de apoio e ferramentas.
Embora isso possa parecer simples, muitas organizações estão sob forte
pressão para aumentar a qualidade do serviço e reduzir os seus custos. Na
Figura 3.3, a relação entre custo e qualidade às vezes é inversa. É possível
(normalmente dentro da gama de optimização) para aumentar a qualidade e
reduzir custos. Isto é normalmente iniciado dentro de Operação de Serviço e
transportados por Melhoria de Serviço Continuada. Alguns custos podem ser
reduzidos gradualmente ao longo do tempo, mas as economias mais custos
pode ser feita apenas uma vez. Por exemplo, uma vez que uma ferramenta de
software duplicado foi eliminada, não pode ser eliminada de novo para redução
de custos adicionais.
Alcançar um equilíbrio ideal entre custar e qualidade (mostrado entre as linhas

pontilhadas na Figura 3.3) é uma chave papel de Serviço de Gestão de. Não há
indústria padrão para o que este intervalo deve ser, uma vez que cada serviço
terá uma gama diferente de optimização, dependendo da natureza do serviço e
do tipo de objetivo de negócio sendo atendidas. Por exemplo, a empresa pode
estar preparado para gastar mais para alcançar alta disponibilidade em um
serviço de missão crítica, enquanto ele está preparado para conviver com a
baixa qualidade de uma ferramenta administrativa.
Determinar o equilíbrio de custo e de qualidade deve ser feito durante o

Estratégia de Serviço e Design de Serviços Ciclo de Vida fases, embora em
muitas organizações é deixada para o Operação de Serviço equipes - muitos
dos quais não têm, geralmente, todos os fatos ou a autoridade para ser capaz
de fazer este tipo de decisão.
Infelizmente, também é comum encontrar organizações que estão gastando

grandes quantidades de dinheiro, sem realização de quaisquer melhorias claras
na qualidade. Novamente, Melhoria de Serviço Continuada será capaz de
identificar a causa da ineficiência, avaliar o equilíbrio ideal para esse serviço e
formular um corretivo plano.
Atingir o equilíbrio correto é importante. Foco muito em qualidade resultará em

De serviços de TIs que oferecem mais do que o necessário, a um custo maior, e
pode levar a uma discussão sobre a redução do preço dos serviços. Foco muito
no custo resultará em TI entrega ou sob orçamento, Mas colocar o negócio em
risco através de sub-padrão de serviços de TI.
Nota especial: o quão longe é demais?
Ao longo dos últimos anos, as organizações de TI estão sob pressão para cortar
custos. Em muitos casos, isto resultou em otimizard e custos qualidade. Mas,
noutros casos, os custos foram reduzidos até ao ponto em que passou a

padecer de qualidade. Na primeira, os sinais eram sutis - pequenos aumentos
de incidente resolução vezes e um ligeiro aumento no número de incidentes.
Com o tempo, porém, a situação se tornou mais grave como o pessoal
trabalhava longas horas para lidar com múltiplas carga de trabalhos serviços e
correu em infra-estrutura envelhecida ou ultrapassada.
Não há cálculo simples para determinar quando os custos foram cortados longe
demais, mas SLM bom é crucial para a tomada clientes conscientes da impacto
de corte muito longe, tão reconhecer esses sinais e sintomas podem melhorar
muito a organizaçãoCapacidade 's para corrigir esta situação.
Exigência de Nível de Serviços - juntamente com uma compreensão clara do

objeto social da serviço e os riscos potenciais - vai ajudar a garantir que o
serviço é entregue ao custo adequado. Eles também ajudam a evitar
"superdimensionamento" do serviço simplesmente porque o orçamento está
disponível, ou "sob dimensionamento", porque a empresa não entender o
gerenciamento exigências da solução. Ou resultado fará com que a insatisfação
do cliente e despesa ainda mais quando a solução é re-engenharia ou retro-
equipada com os requisitos que deveriam ter sido especificados durante a
Design de Serviços.
Figura 3.4 Atingir um equilíbrio entre o foco no custo e qualidade
Tabela 3.3 apresenta alguns exemplos das características de posições em lados

extremos do espectro de custo / qualidade. O objetivo desta tabela é para ajudar
as organizações a identificar para não que eles estão mais próximos extrema,
para identificar vida real cargos para os quais as organizações devem aspirar.
Extremo foco na qualidade Foco extremo no custo
Foco principal Cumprindo o nível de qualidade exigido Reunião orçamento e reduzindo

pela empresa, independentemente do custars

que é preciso
Típico • Orçamentos crescentes • Ele limita a qualidade de

problemas • De serviços de TIs geralmente serviço com base no seu
experimentado entregar mais do que é orçamento disponibilidade
necessário para o sucesso do • Escaladas da empresa
negócio para obter mais serviços
• Crescentes exigências de de TI.
maiorqualidade serviços.
Gestão Ele geralmente não tem um método de O relatório financeiro é feito

Financeira comunicação do custo de serviços de puramente em valores
TI. Contabilidade métodos baseiam-se orçamentados. Não há nenhuma
num método de agregados (por maneira de ligar as atividades de
exemplo, custo de TI por usuário). TI para a entrega de serviços de
TI.
Tabela 3.3 Exemplos de extremo foco na qualidade e custo
Alcançar um equilíbrio irá garantir a entrega do nível de serviço necessário para

atender negócios exigências a uma óptima (em oposição a menor possível) o
custo. Isso vai exigir o seguinte:
• Um processo de Gestão Financeira e ferramentas que podem esclarecer

o custo da prestação de serviços de TI, e qual o modelo de métodos
alternativos de prestação de serviços em diferentes níveis de custo. Por
exemplo, comparando o custo de fornecimento de um serviço de
disponibilidade de 98% ou menos 99,9% de disponibilidade, ou o custo da
prestação de um serviço com ou sem funcionalidade adicional.
• Assegurar que as decisões em torno custo versus qualidade são feitas
pelos gestores adequadas durante Estratégia de Serviço e Design de
Serviços. TI operacional gerentes não são geralmente equipados para
avaliar oportunidades de negócios e só deve ser solicitado a tomar
decisões financeiras que estão relacionadas a alcançar a eficiência
operacional.
3.2.4 reativa contra proativo
Um reactivo organização é aquele que não age a menos que seja solicitado a
fazê-lo por uma externa motorista, E.g. um requisito de negócio novo, uma
aplicação que tem sido desenvolvido ou escalada em reclamações feitas por
usuários e clientes. Uma triste realidade em muitas organizações é o foco na
gestão reactiva erroneamente como o único meio para assegurar serviços que
são altamente consistente e estável, ativamente desencorajar comportamento
pró-ativo da equipe operacional. A ironia infeliz desta abordagem é que o
investimento em esforço desanimador proativo Serviço de Gestão de pode,
finalmente, aumentar o esforço e custo das atividades reativas e mais risco
estabilidade e consistência nos serviços.

Uma organização pró-ativa está sempre procurando maneiras de melhorar a
situação atual. Ele continuamente varredura interna e externa ambientes,
procurando sinais de potencialmente impactar mudanças. Comportamento pró-
ativo é geralmente visto como positivo, especialmente uma vez que permite que
a organização para manter a vantagem competitiva em um ambiente em
mudança. No entanto, ser muito activa podem ser caros e podem resultar em
pessoal ser distraído. A necessidade de equilíbrio no comportamento reativo e
proativo consegue muitas vezes o resultado ideal.
Geralmente, é melhor para gerenciar serviços de TI de forma proativa, mas

conseguir isso não é facilmente planejado ou alcançado. Isto porque a
construção de uma organização de TI pró-ativa é dependente de muitas
variáveis, incluindo:
• O maturidade do organização. Quanto mais tempo a organização foi

entregar um conjunto consistente de De serviços de TIs, o mais provável
é entender a relação entre a TI e os negócios ea Infraestrutura de TI e
serviços de TI.
• O cultura da organização. Algumas organizações têm uma cultura que
está focada na inovação e são mais propensos a ser proativo. Outros são
mais propensos a se concentrar sobre o status quo e, como tal, são
susceptíveis de resistir mudar e ter mais foco reativo.
• O papel que a TI desempenha no negócio e do mandato que a TI tem de
influenciar o estratégia e táticas da empresa. Por exemplo, uma empresa
onde o CIO é um membro do conselho é provável que tenha uma
organização de TI que é muito mais pró-ativo e ágil do que uma empresa
onde a TI é vista como um administrativo despesas gerais.
• O nível de integração de processos e ferramentas de gestão. Níveis
superiores de integração vai facilitar um melhor conhecimento das
oportunidades.
• A maturidade e escopo de Gestão do Conhecimento na organização, o
que é visto especialmente em organizações que têm sido capazes de
armazenar e organizar dados históricos de forma eficaz - especialmente
Disponibilidade e Gerenciamento de Problemas dados.
De uma perspectiva de maturidade, é claro que as organizações mais novas

terão prioridades diferentes e experiências de uma organização mais
estabelecida - o que é melhores práticas para uma organização madura não
pode atender um jovem organização. Portanto, um desequilíbrio pode resultar de
uma organização ou ser menos ou mais maduro. Considere o seguinte:
• Organizações menos maduras (ou organizações com novos serviços de

TI ou tecnologia), geralmente, mais reativa, simplesmente porque eles
não sabem todas as variáveis envolvidas na execução de seus negócios
e oferecer serviços de TI.

• A equipe de TI em organizações mais recentes tendem a ser generalistas
porque não está claro exatamente o que é necessário para entregar
estáveis serviços de TI para o negócio.
• Incidentes e problemas em organizações mais novas são bastante
imprevisíveis, pois a tecnologia é relativamente nova e mudanças
rapidamente.
• Organizações mais maduras tendem a ser mais pró-ativa, simplesmente
porque têm mais dados e relatórios disponíveis e conhecer os padrões
típicos de incidentes e fluxos de trabalho. Assim, eles prevêem exceções
muito mais facilmente.
• O pessoal que trabalha em organizações maduras também geralmente
tendem a ter relacionamentos mais estáveis entre a equipe de TI e os
negócios e por isso pode ser mais proativo sobre o encontro de negócios
em constante mudança exigências - isto é especialmente verdadeiro
quando a TI é vista como um estratégico componente do negócio.
Figura 3.5 Atingir um equilíbrio entre ser muito reativa ou proativa também

A Tabela 3.4 resume alguns exemplos das características de posições em
extremos do espectro. O objetivo desta tabela é para ajudar as organizações a
identificar para não que eles estão mais próximos extrema, para identificar vida
real cargos para os quais as organizações devem aspirar.
Extremamente reativo Extremamente proativa
Foco principal Responde às necessidades de Antecipa negócios exigências

negócios e incidentes só depois que antes de serem comunicados e
eles são relatados problemas antes que elas ocorram
Os problemas • Preparando-se para oferecer • Dinheiro é gasto antes que

típicos novos serviços leva um longo os requisitos são
experimentado tempo, porque cada projeto é demonstrados. Em alguns
tratado como se fosse o casos em que compra
primeiro itens que nunca serão
• Incidentes similares ocorram usados porque antecipou
novamente e de novo, como as exigências erradas ou
não há nenhuma maneira de porque o projeto está
tendências los parado
• Rotatividade de pessoal é alta • A equipe de TI tendem a
eo moral é geralmente baixo, ter estado no organização
como a equipe de TI se por um longo tempo e
manter em movimento de tendem a assumir que eles
projeto para projeto, sem sabem os requisitos de
alcançar um conjunto, negócio melhor do que a
duradouras estável de De empresa faz
serviços de TIs
Planejamento de Espere até que haja capacidade Antecipar problemas de

Capacidade problemas e, em seguida, adquirir a capacidade e gastar dinheiro em
capacidade excedente para durar até prevenção estes - mesmo quando
que o incidente relacionado com a o cenário é improvável que isso
capacidade próxima aconteça
Planejamento da • Não planos existir até depois Over-planejamento (E sobre os

Continuidade dos de um grande evento ou gastos) de TI Opção de
Serviços de TI desastre recuperaçãos. Geralmente
• Ela planeja foco na recuperação imediata é fornecido
recuperação de chave para a maioria De serviços de TIs,
sistemas, mas sem garantir independentemente da sua
que a empresa pode recuperar impacto ou prioridade
seus processos
Gestão da • As alterações são muitas As alterações são solicitados e

Mudança vezes não registrado, ou aplicado mesmo quando não
registrado no último minuto, existe uma necessidade real, isto
como Mudança de é, uma quantidade significativa de
emergências trabalho para fixar os artigos que
• Não é tempo suficiente para o não são quebrados
impacto adequada e custar
avaliaçãos

• As alterações são pouco
estudado e controlado, o que
resulta num elevado número
de incidentes
Tabela 3.4 Exemplos de comportamento extremamente reativo e proativo
Embora o comportamento pró-ativo em Operação de Serviço geralmente é bom,

também há momentos em que o comportamento reativo é necessário. O papel
de Operação de Serviço é, portanto, para alcançar um equilíbrio entre ser reativa
e pró-ativa. Isso vai exigir:
• Formal Gerenciamento de Problemas e Gerenciamento de Incidentes

processos, integrada entre Operação de Serviço e Melhoria de Serviço
Continuada.
• A habilidade de ser capaz de priorizar falhas técnicas, bem como as
demandas de negócios. Isso precisa ser feito durante a operação de
serviço, mas os mecanismos precisam ser postas em prática durante
Estratégia de Serviço e Design. Estes mecanismos podem incluir
categorização incidente sistemas, escalada procedimentos e ferramentas
para facilitar impacto avaliação para mudanças.
• Dados de configuração e Gestão de Ativos para fornecer dados, quando
necessário, economizando projetos do tempo e tomar decisões mais
precisas.
• Participação permanente do SLM na Operação de Serviço.

3,3 prestação de serviços
Todo o pessoal Operação de Serviço devem estar plenamente conscientes de
que eles estão lá para "prestar serviço" para o negócio. Eles devem fornecer um
oportuno (resposta rápida e entrega rápida dos exigências), profissional e cortês
serviço para permitir que a empresa para realizar suas próprias atividades - de
forma que o comercial cliente'S necessidades são satisfeitas eo negócio
prospera.
É importante que os funcionários são treinados não apenas em como entregar e

apoiar De serviços de TIs, mas também na forma em que o serviço a ser
fornecido. Por exemplo, funcionários que são capazes e prestar serviços de
forma eficaz ainda pode causar insatisfação do cliente significativo se eles são
insensíveis ou de desprezo. Por outro lado, nenhuma quantidade de ser
agradável para um cliente irá ajudar se o serviço não está sendo entregue.
Um elemento crítico de ser proficiente provedor de serviços está a colocar tanta

ênfase no recrutamento e treinamento de pessoal para desenvolver competência
em lidar com clientes e gestão relaçãos e interações como eles fazem em
competências técnicas para a gestão de TI ambiente.

3,4 a participação do pessoal de operação em Design de
Serviços e Transição de Serviço
É extremamente importante que o pessoal de operação de serviço estão
envolvidas em Design de Serviços e Transição de Serviço e, potencialmente,
também na Estratégia de Serviço, onde apropriado.
Uma chave para alcançar o equilíbrio na Operação de Serviço é um conjunto

eficaz de processos de design de serviço. Estes proporcionarão TI Gestão de
Operações com:
• Definição clara de serviço de TI objetivos e atuação critérios

• Ligação de serviço de TI especificaçãos para o desempenho do
Infraestrutura de TI
• Definição de operacional requisitos de desempenho
• Um mapeamento de serviços e tecnologia
• A capacidade de modelar o efeito de mudanças na tecnologia e
mudanças para as empresas exigências
• Apropriado custar modelos (por exemplo, cliente ou serviço baseado)
para avaliar o retorno do investimento e redução de custos estratégias.
A natureza do TI Gestão de Operações envolvimento deve ser cuidadosamente

posicionadas. Design de Serviços é uma fase na Serviço de Gestão de Ciclo de
Vida utilizando um conjunto de processos, e não um função independente da
operação do serviço. Como tal, muitas das pessoas que estão envolvidas em
Design de Serviços virá de TI Gestão de Operações.
Isso não só deve ser incentivado, mas Operação de Serviço pessoal deve ser
medido em seu envolvimento em atividades de design de serviço - e tais
atividades devem ser incluídas no descrição do trabalhos e papels, etc Isto irá
ajudar a assegurar a continuidade entre os requisitos de negócios e tecnologia
projeto e operação e que também irá ajudar a assegurar que o que é concebida
também pode ser operado. Operações de TI equipe de Gestão também devem
ser envolvidos durante Transição de Serviço para garantir a consistência e para
garantir que o negócio declarado e capacidade de gerenciamento são
cumpridos.
Recursos devem estar disponíveis para estas actividades e o tempo requerido

deve ser levado em conta, se for caso disso

3,5 Saúde Operacional
Muitas organizações acham que é útil para comparar a monitoramento e
controlar de Operação de Serviço de vigilância da saúde e de controle.
Neste sentido, o Infraestrutura de TI é como um organismo que tem sinais vitais

que podem ser monitorados para verificar se ele está funcionando normalmente.
Isto significa que não é necessário monitorizar continuamente sempre
componente de cada TI sistema para assegurar que este está a funcionar.
Saúde operacional pode ser determinado através do isolamento de algumas

importantes "sinais vitais" em dispositivos ou serviços que são definidas como
essenciais para a boa execução de um Função de Negócios Vital. Esta poderia
ser a utilização de largura de banda de um segmento de rede, ou a utilização da
memória em uma grande servidor. Se estes sinais estão dentro dos limites
normais, o sistema é saudável e não necessita de maior atenção. Esta redução
na necessidade de monitorização extensa resultará em redução de custos e
operacional equipes e departamentos que estão focados em áreas apropriadas
para serviço sucesso.
No entanto, tal como com os organismos, é importante para verificar a sistemas

mais minuciosamente ao longo do tempo, para verificar se há problemas que
não afetam imediatamente os sinais vitais. Por exemplo, um disco pode estar
funcionando perfeitamente, mas poderia estar chegando ao Tempo médio entre
falhas (MTBF) limiar. Neste caso, o sistema deve ser retirado de serviço e dado
um exame completo ou "exame de saúde". Ao mesmo tempo, deve sublinhar-se
que o resultado final deve ser o funcionamento saudável do serviço como um
todo. Isto significa que exames de saúde sobre os componentes deve ser
equilibrada contra cheques de serviço o "fim-a-fim". A definição do que precisa
ser monitorado e que é saudável em relação saudável é definida durante a
Design de Serviços, especialmente Gerenciamento de Disponibilidade e SLM.
Saúde operacional é dependente da capacidade de prevenir incidentes e

problemas, investindo em infra-estrutura confiável e de fácil manutenção. Isto é
conseguido através de boas disponibilidade projeto e Gerenciamento de
Problemas pró-ativa. Ao mesmo tempo, Health operacional é também
dependente da capacidade de identificar falhas e localizá-los de forma eficaz, de
modo que eles têm um mínimo impacto sobre o serviço. Isso requer Incident (de
preferência automático) forte e Gerenciamento de Problemas.
A idéia de Saúde Operacional também levou a uma área especializada chamada

"Sistemas de auto-cura. Trata-se de um aplicação de gerenciamento de
disponibilidade, capacidade, conhecimento de Incidentes e Problemas e refere-
se a um sistema que foi concebido para suportar as condições operacionais
mais severas e para detectar, diagnosticar e recuperar a maioria dos incidentes
e Erro Conhecidos. Sistemas de auto-cura são conhecidos por nomes

diferentes, por exemplo, sistemas autônomos, sistemas adaptativos e Sistemas
Dinâmicos. Características dos sistemas de auto-cura incluem:
• Resiliência é projetado e construído para o sistema, por exemplo, vários

discos redundantes ou processadores de múltiplos. Isso protege o
sistema contra hardware falha uma vez que é capaz de continuar a
funcionar, utilizando o hardware repetido componente.
• Software, dados e resiliência do sistema operacional também é projetado
para o sistema, por exemplo, bancos de dados espelhado (onde um
banco de dados é duplicado em um apoio dispositivo) e disco striping
tecnologia (onde pedaços individuais de dados são distribuídos através
de uma matriz de disco - de modo que resulta uma falha no disco de
perda de apenas uma parte dos dados, que pode ser facilmente
recuperado usando algoritmos).
• A capacidade de deslocar processamento de um dispositivo físico para
outro, sem qualquer interrupção do serviço. Esta poderia ser uma
resposta a uma falha ou porque o dispositivo está a atingir níveis de
utilização elevados (alguns sistemas são projetados para distribuir o
processamento carga de trabalhos de forma contínua, para fazer o melhor
uso disponível capacidade, O qual também é conhecido como
virtualização).
• Embutido monitoramento utilitários que permitem que o sistema para
detectar eventos e para determinar se estes representam normais
operaçãos ou não.
• Um mecanismo de correlação (ver parágrafo 4.1.5.6 em Gestão de
Eventos). Isto irá permitir que o sistema para determinar o significado de
cada evento e também para determinar se há qualquer resposta a esse
evento predefinido.
• Um conjunto de ferramentas de diagnóstico, tais como script de
diagnósticos, falta de árvores e uma base de dados de Erro Conhecidos e
comum solução alternativas. Estes são utilizados tão logo um erro for
detectado, para determinar a resposta adequada.
• A capacidade de gerar um chamar por intervenção humana, gerando uma
alertar ou a geração de um incidente.
Embora o conceito de Saúde Operacional não é um conceito central do

Operação de Serviço, Muitas vezes é uma metáfora útil para ajudar a determinar
o que precisa ser monitorado e freqüência para realizar a manutenção
preventiva.
O que e quando para monitorar operacional saúde deve ser determinado em

Design de Serviços, Testado e aperfeiçoado durante Transição de Serviço e
otimizard em Melhoria de Serviço Continuada, Conforme necessário.

3,6 Comunicação
Uma boa comunicação é necessária com outras equipes de TI e departamentos,
com usuários e clientes internos, e entre as equipes de serviço de operação e
departamentos próprios. Questões muitas vezes pode ser evitado ou atenuado
com comunicação adequada.
Esta seção tem como objetivo resumir a comunicação que deve ocorrer em
operação de serviço. Esta não é uma separada processo, Mas uma lista de
verificação do tipo de comunicação que é necessário para a operação de serviço
eficaz.
Um princípio importante é que toda a comunicação deve ter uma finalidade ou

uma acção resultante. As informações não devem ser comunicados a menos
que haja um público claro. Além disso, esse público deveria ter se envolvido
ativamente na determinação da necessidade de que a comunicação eo que eles
vão fazer com a informação.
Uma descrição mais detalhada dos tipos de comunicação típico em operação de

serviço está contida no Apêndice B da presente publicação, em conjunto com
uma descrição da audiência típica e as acções que se destinam a ser tomadas
como resultado de cada comunicação. Estes incluem:
• Rotina operacional comunicação

• A comunicação entre deslocars
• Relatórios de desempenho
• Comunicação em projetos
• Comunicação relacionada com alterações
• Comunicação relacionada com exceções
• Comunicação relacionada a emergências
• Treinamento sobre processos novos ou personalizado e design de
serviços
• Comunicação de estratégia e design para Operação de Serviço equipes.
Por favor, note que não há meio de comunicação definitivo, nem existe um local
fixo ou de freqüência. Em algumas organizações de comunicação tem que
ocorrer nas reuniões. Outras organizações preferem usar e-mail ou a
comunicação inerente à sua Serviço de Gestão de ferramentas.
Assim, deverá ser um política em torno da comunicação dentro de cada equipe

ou departamento e para cada processo. Embora este deve ser formal, a política
não deve ser complicado ou complexo. Por exemplo, um gerente pode exigir que
todas as comunicações relativas a mudanças devem ser enviadas por e-mail.
Enquanto isso é especificado em POPs do departamento (em qualquer forma
que eles existem), não há necessidade de criar uma política separada para ele.

Embora o conteúdo típico de comunicação é bastante consistente uma vez os
processos foram definidos, os meios de comunicação estão mudando a cada
nova introdução da tecnologia. A lista de alternativas está crescendo e, hoje,
inclui:
• E-mail, ao tradicional clientes ou dispositivos móveis

• Mensagens SMS
• Pagers
• Mensagens instantâneas e web-based 'chats'
• Voz sobre Protocolo de Internet (VoIP) utilitários que podem transformar
qualquer dispositivo conectado a um meio de comunicação de baixo custo
• Utilitários reunião por teleconferência e virtuais, revolucionaram reuniões
que estão agora realizadas através de longas distâncias
• DocumentoDe partilha de serviços públicos.
Os meios de comunicação em si está fora do escopo desta publicação. No

entanto, os seguintes pontos devem ser observados:
• A comunicação é fundamental e os meios de comunicação devem

garantir que eles servem este objetivo. Por exemplo, a necessidade para
uma comunicação segura pode eliminar a possibilidade de alguns dos
meios acima referidos. A necessidade de qualidade pode eliminar
algumas opções de VoIP.
• É possível utilizar qualquer meio de comunicação, desde que todos das
partes interessadass compreender como e quando a comunicação
ocorrerá.
3.6.1 Reuniões
Organizações diferentes formas de comunicação diferentes. Onde as

organizações são distribuídos, eles tendem a confiar em e-mail e instalações de
teleconferência. Organizações que possuem processos de serviços mais
maduros e ferramentas de gestão tendem a confiar nas ferramentas e processos
de comunicação (por exemplo, usando um Gerenciamento de Incidentes
ferramenta para aumentar e acompanhar incidentes, em vez de solicitar e-mail
ou telefone para chamadas de atualizações).
Outras organizações preferem se comunicar utilizando reuniões. No entanto, é

importante não entrar no modo pelo qual o trabalho a tempo só é feito, ou de
gestão está envolvido, é durante uma reunião. Além disso, face-a-face tendem a
aumentar custars (por exemplo, o tempo de viagem, passou em discussões
informais, bebidas, etc), assim que os organizadores da reunião deve equilibrar
o valor da reunião com o número ea identidade dos participantes e do tempo
que eles passam, e chegar, a reunião.

O propósito das reuniões é comunicar de forma eficaz para um grupo de
pessoas sobre um conjunto comum de objetivos ou atividades. As reuniões
devem ser bem controlada e breve, eo foco deve ser a facilitar a acção. Uma
boa regra é não realizar uma reunião, se a informação pode ser comunicada de
forma eficaz por meios automáticos.
Uma série de fatores são essenciais para o sucesso de reuniões. Embora estes
possam parecer senso comum, às vezes são negligenciados:
• Estabelecer e comunicar uma agenda clara para garantir que a reunião

atinge seu objetivo e ajudar o facilitador evitar participantes de 'oi-jacking
"da reunião.
• Assegurar que as regras para participar são compreendidos. As
organizações tendem a ter um conjunto formal de regras de reuniões, que
variam de relativamente informal para muito formal (por exemplo, regras
Roberts da Ordem).
• Fazer uso de 'estacionamentos' ou notas que registro questões que não
são diretamente relevantes para o objetivo da reunião, mas que podem
ser chamados em caso de necessidade de discussão surge.
• Ata da reunião: as regras devem ser definidas sobre quando os minutos
são tomadas. Minutos são utilizados para lembrar as pessoas que estão
atribuídas ações e acompanhar o andamento das ações delegadas. Eles
também são úteis para garantir que multifuncionais decisões e ações são
acompanhadas e seguidas por.
• Use técnicas para incentivar o nível adequado de participação. Uma
técnica ao discutir melhorias, por exemplo, é a "manter, parar, começar a
'técnica. Os participantes são encorajados a lista de itens que eles
gostariam de manter, coisas que precisam ser parado e iniciativas ou
ações que eles gostariam de ver iniciada.
Exemplos de reuniões típicos são apresentados a seguir:
3.6.1.1 A reunião de Operações
Reuniões operações são normalmente realizadas entre os gestores da TI

operacional departamentos, equipes ou grupos, no início de cada dia de trabalho
ou semana. O objetivo deste tipo de reunião é fazer com que o pessoal ciente de
qualquer assunto relevante para Operações (como alteração de horários, os
negócios eventos, programas de manutenção, etc) e dar uma oportunidade para
o pessoal para levantar quaisquer questões de que tenham conhecimento. Esta
é uma oportunidade para assegurar que todos os departamentos de um centro
de dados são sincronizados.
Em organizações geograficamente dispersas, pode não ser possível ter uma

única reunião de Operações diária. Nestes casos, é importante para coordenar a
agenda das reuniões e assegurar que cada reunião tem dois componentes:

1. A primeira parte da reunião vai cobrir aspectos que se aplicam ao
organização como um todo, por exemplo, novas políticas, mudanças que
afetam todas as regiões e negócios eventos que abrangem todas as
regiões.
2. A segunda parte da reunião vai cobrir aspectos que se aplicam apenas à
região local, por exemplo, local operaçãohorários s, as mudanças de
equipamento local, etc
A reunião de Operações geralmente é presidido pelo Operações de TI Gerente

ou um gerente de operações sênior e com a participação de todos os gerentes e
supervisores (exceto aqueles cujos deslocars não estão em serviço). Também é
útil ter pelo menos um representante do Service Desk na reunião, de modo que
eles estão cientes de todas as situações que podem dar origem a incidentes.
Oportunidades para melhorar os serviços ou processos devem ser capturados,

se levantou, e encaminhado para a equipe responsável pela Melhoria de Serviço
Continuada.
3.6.1.2 Departamento reuniões de grupo ou equipe
Estas reuniões são essencialmente o mesmo que o encontro de Operações,

mas destinam-se a um grupo de TI único departamento ou equipe. Cada gerente
ou supervisor transmite a informação a partir da reunião de Operações que é
relevante para a sua equipe.
Além disso, estas reuniões também abranger o seguinte:
• Uma discussão mais detalhada de incidentes, problemas e as mudanças

que ainda estão sendo trabalhados, com informações sobre:
• Progredir até à data
• A confirmação de que ainda precisa ser feito
• Tempo estimado para conclusão
• Pedido de adicional recursos, se for necessário
• Discussão de possíveis problemas ou preocupações
• A confirmação da equipe disponibilidade para deveres roster
• Confirmação de horários de férias.
3.6.1.3 reuniões com clientes
De tempos em tempos, será necessário a realização de reuniões com clientes,

independentemente do nível de serviço regular Comente reuniões. Os exemplos
incluem:
• Acompanhamento após incidentes graves. O objectivo destas reuniões é

para reparar o relação com os clientes, mas também para garantir que ele
tenha todas as informações necessárias para evitar a recorrência. Os

clientes também têm a oportunidade de fornecer informações sobre o
negócio imprevisto impactos. Estas reuniões são úteis em concordar
ações para os tipos semelhantes de incidentes que podem ocorrer no
futuro.
• Um forum cliente, que pode ser usado para uma variedade de finalidades,
incluindo testes de ideias para novos serviços ou soluções, ou reunindo
exigências para serviços novos ou revista ou procedimentos. Um fórum
cliente é geralmente um encontro regular com os clientes para discutir
áreas de interesse comum.

3,7 Documentação
TI Gestão de Operações e todas as técnicas e Aplicação de Gestão de equipes
e departamentos estão envolvidos na criação e manutenção de uma série de
documentos. Estes são detalhados nos capítulos 4, 5 e 6 da presente publicação
e incluem o seguinte:
• Participação na definição e manutenção de processo manuais para todos

os processos em que estão envolvidos dentro Estes irão incluir processos
em outras fases do IT Service Management Ciclo de Vida (E.g.
Gerenciamento da Capacidade,Gestão da Mudança,Gerenciamento de
Disponibilidade), Bem como para todos os processos que fazem parte da
Operação de Serviço fase.
• Estabelecer a sua própria técnica procedimentomanuais s. Estes devem
ser mantidos atualizados e novo material deve ser adicionado como
torna-se relevante, sob controle de alterações. Deve ser lembrado que os
seus procedimentos devem sempre ser estruturada de forma a satisfazer
o objetivos e constrangimentos definidos no nível mais alto Serviço de
Gestão de processos, tais como SLM. Por exemplo, um procedimento
técnico para o gerenciamento de servidors deve sempre garantir que visa
alcançar o disponibilidade e atuação níveis acordados no Acordo de Nível
Operacionals e Acordo de Nível de Serviços (SLAs).
• Participação na criação e manutenção de planejamento documentos, por
exemplo, e Capacity Plano de disponibilidades e a TI Plano de
Continuidade do Serviços.
• Participação na criação e manutenção do Portfólio de Serviços. Isso
incluirá a quantificação custars e que institui a operacional viabilidade de
cada proposta serviço.
• Participação na definição e manutenção da ferramenta de Gestão de
Serviços instrução de trabalhos, a fim de satisfazer relatório exigências

4 Operação processos de serviço
Os processos listados no ponto 2.4.5 são discutidos em detalhe neste capítulo.
Como referência, a estrutura geral é brevemente descrito aqui e, em seguida,
cada um dos processos é descrito em mais detalhe mais adiante no capítulo.
Por favor, note que o papels para cada processo e as ferramentas utilizadas
para cada processo são descritos nos capítulos 6 e 7, respectivamente.
• Gestão de Eventos é o processo que monitoriza todos os acontecimentos

que ocorrem através do Infraestrutura de TI para permitir o normal,
operação e também para detectar e aumentar as condições de excepção.
• Gerenciamento de Incidentes concentra-se o serviço para restaurar
usuários o mais rapidamente possível, a fim de minimizar a actividade
impacto.
• Gerenciamento de Problemas envolve análise de causa raiz para
determinar e resolver a causa de eventos e incidentes, atividades pró-
ativas para detectar e prevenir futuros problemas / incidentes e um Erro
Conhecido sub-processo para permitir o rápido diagnóstico e resolução se
novos incidentes ocorrem.
NOTA: Sem essa distinção entre incidentes e problemas, e manter incidente

separado e Grave problemas, existe o perigo de que:
• Incidentes será fechado também no início do ciclo de suporte

global e não haverá ações tomadas para prevenir a reincidência -
de modo que os mesmos incidentes terão de ser fixado e outra
vez, ou
• Incidentes será mantida aberta para que análise de causa raiz
pode ser feito e visibilidade será perdido quando o de usuário'S
serviço era, na verdade restaurard - metas de SLA para que não
pode ser cumprida mesmo que o serviço foi restaurado dentro das
expectativas dos usuários. Isto muitas vezes resulta de um grande
número de incidentes abertos, muitos dos quais nunca serão
fechado a menos que uma "purga" periódica é realizada. Isso pode
ser muito desmotivador e pode impedir a visibilidade eficaz das
questões atuais.
• Cumprimento de Requisição envolve a administração de cliente ou

solicitações de usuários que não são gerados como um incidente de um
atraso de serviço ou interrupção inesperada. Algumas organizações
podem escolher para lidar com esses pedidos como um 'categoria'De
incidentes e gerenciar as informações através de um Gerenciamento de
Incidentes sistema - mas outros podem escolher (por causa de grandes
volumes ou de negócios prioridade de tais pedidos) para facilitar o
fornecimento de capacidades de Cumprimento de Requisição
separadamente através do Cumprimento de Requisição processo.

Tornou-se popular prática utilizar um processo formal de cumprimento de
solicitação para gerenciar clientes e usuários pedidos de todos os tipos de
pedidos, que incluem instalações, movimentos e suprimentos, bem como
aqueles específicos para De serviços de TIs. Estes pedidos não estão
geralmente ligados à mesma SLA medidas e separando o registros e o
fluxo de processo está a emergir como melhores práticas em muitas
organizações.
• Gerenciamento de Acesso: Este é o processo de concessão de usuários
autorizados o direito de usar um serviço, ao restringir o acesso a usuários
não-autorizados. Ele é baseado em ser capaz de identificar com precisão
os usuários autorizados e gerenciar sua própria capacidade de acessar
serviços como exigido durante as diferentes fases de seus recursos
humanos (RH) ou contratual ciclo de vida. Gerenciamento de acesso
também tem sido chamado de identidade ou Direitos Gestão em algumas
organizações.
Além disso, existem vários outros processos que serão executados ou apoiados
durante operação de serviço, mas que são conduzidas durante outras fases do
Serviço de Gestão de Ciclo de Vida. O operacional aspectos destes processos
será discutido na parte final deste capítulo e incluem:
• Gestão da Mudança, Um grande processo que deve estar estreitamente

ligada à Gerenciamento da Configuração e Gerenciamento de Liberação.
Esses tópicos são cobertos principalmente no Transição de Serviço
Publicação.
• Capacidade e Gerenciamento de Disponibilidade, Os aspectos
operacionais do que são abordados nesta publicação, mas que são
abordados com mais detalhes no Design de Serviços publicação.
• Gestão Financeira, Que é coberto no Estratégia de Serviço publicação.
• Gestão do Conhecimento, Que é coberta na publicação Transição de
Serviço.
• Continuidade do Serviço de TI, que é coberta na publicação Service
Design.
• Serviço de Relatórios e Mensuração, que são abordados na publicação
Melhoria de Serviço Continuada

4.1 Gestão de Eventos
Um evento pode ser definido como qualquer ocorrência detectável ou discernível
que tem importância para a gestão do Infraestrutura de TI ou a entrega de De
serviços de TI e avaliação do impacto um desvio poderá causar aos serviços. Os
eventos são tipicamente notificações criadas por um serviço de TI, Item de
Configuração (CI) ou monitoramento ferramenta.
Eficaz Operação de Serviço é dependente de saber o estado da infra-estrutura e

detectar qualquer desvio do normal ou esperado operação. Isto é proporcionado
pelo bom monitoramento e controlar sistemas, que são baseados em dois tipos
de ferramentas:
• monitoramento ativo ferramentas que CIs enquete chave para determinar

o seu estado e disponibilidade. Quaisquer exceções irá gerar um alertar
que precisa ser comunicada para a ferramenta apropriada ou equipe para
a ação
• monitoramento passivo ferramentas que detectam e correlacionar
operacional alertas ou comunicações geradas pela CEI.
A capacidade de detectar eventos, entendê-los e determinar a ação de controle

adequados por Gestão de Eventos. Gestão de Eventos é, portanto, a base para
o Monitoramento Operacional e Controle (ver Anexo B).
Além disso, se estes eventos são programados para comunicar informações

operacionais, assim como avisos e excepções, eles podem ser usados como
base para a automatização de rotina muitos Gestão de Operações atividades,
por exemplo, a execução de scripts em dispositivos remotos, ou enviar trabalhos
para o processamento, ou mesmo dinamicamente equilibrar a demanda por um
serviço em vários dispositivos para melhorar atuação.
Gestão de Eventos, portanto, fornece o ponto de entrada para a execução de

muitos Operação de Serviço processos e atividades. Além disso, ele fornece
uma forma de comparar o desempenho real e comportamento contra projeto
padrãos e SLAs. Como tal, Gestão de Eventos, também fornece uma base para
Garantia de Serviço e Comunicação, e melhoria dos serviços. Isso é abordado
em detalhes na publicação Melhoria de Serviço Continuada.
4.1.2 Âmbito
Gestão de Eventos pode ser aplicado a qualquer aspecto de Serviço de Gestão

de que tem de ser controlada, e que pode ser automatizado. Estes incluem:
• Item de Configuraçãos:

• Alguns CIs serão incluídos porque eles precisam ficar em um
estado constante (por exemplo, um interruptor em uma rede
precisa ficar e ferramentas de Gestão de Eventos confirmar isso
respostas de monitoramento para 'pings').
• Alguns CIs serão incluídos porque a sua estado precisa mudar
com freqüência e Gestão de Eventos pode ser usado para
automatizar esse e atualizar o CMS (por exemplo, a atualização de
um arquivo servidor).
• Condições ambientais (por exemplo, detecção de incêndio e fumaça)
• Monitoramento de licenças de software para uso para garantir ótima /
legal a utilização de licença e alocação
• Segurança (Por exemplo, detecção de intrusão)
• Normal atividade (Por exemplo, rastrear a utilização de um aplicação ou o
desempenho de um servidor).
A diferença entre monitoramento e Gestão de Eventos
Estas duas áreas são muito intimamente relacionados, mas ligeiramente

diferente na natureza. Gestão evento é focado na geração e detecção de
notificações significativas sobre o estado da Infraestrutura de TI e serviços.
Embora seja verdade que o monitoramento é necessário para detectar e rastrear

essas notificações, o monitoramento é mais amplo do que Gestão de Eventos.
Por exemplo, os instrumentos de controlo irá verificar o estado de um dispositivo
para assegurar que está a funcionar dentro de limites aceitáveis, mesmo que o
dispositivo não está a gerar eventos.
Em termos mais simples, Gerenciamento de Eventos trabalha com as

ocorrências que são especificamente gerados a ser monitorado. Monitoramento
acompanha essas ocorrências, mas que também irá procurar activamente
condições que não geram eventos.
Gestão valor evento para o negócio é geralmente indirecto, no entanto, é

possível determinar a base para o seu valor como se segue:
• Gestão de Eventos oferece mecanismos para o início detecção de

incidentes. Em muitos casos, é possível que o incidente a ser detectada e
atribuída a um grupo apropriado para a acção antes de qualquer real
serviço interrupção ocorre.
• Gestão de Eventos torna possível para alguns tipos de automatizado
atividade para ser monitorizada por excepção - removendo assim a
necessidade de caros e recurso controlo em tempo real intensivo,
enquanto reduz tempo de inatividade.

• Quando integrados em outro Serviço de Gestão de processos (tais como,
por exemplo, disponibilidade, ou Gerenciamento da Capacidade), Gestão
de Eventos pode sinalizar mudanças de status ou exceções que permitem
que a pessoa ou equipe para realizar resposta precoce, melhorando
assim a atuação do processo. Isto, por sua vez, permitirá a actividade de
beneficiar de Gestão de serviço mais eficaz e mais eficiente em geral.
• Gestão de Eventos oferece uma base para automatizado operaçãos,
aumentando a eficiência e permitindo caros recursos humanos a serem
utilizados para o trabalho mais inovador, como projetoing nova
funcionalidade ou melhoria ou a definição de novas formas em que a
empresa pode explorar a tecnologia para aumentar a vantagem
competitiva.
4.1.4 Políticas / princípios / conceitos básicos
Há muitos tipos diferentes de eventos, por exemplo:
• Eventos que significam regular funcionamento:

• notificação de que uma marcada carga de trabalho completou
• umusuário tem conectado para usar uma aplicação
• um e-mail chegou ao seu destinatário.
• Eventos que significam uma excepção
• um usuário tenta fazer logon em um aplicativo com a senha
incorreta
• uma situação inusitada ocorreu em um processo de negócio que
pode indicar uma exceção que exige investigação de novos
negócios (por exemplo, uma página da web alertar indica que um
site de autorização de pagamento não está disponível -
impactando aprovação financeira do negócio transaçãos)
• CPU de um dispositivo está acima da taxa de utilização aceitável
• uma varredura do PC revela a instalação de software não
autorizado.
• Eventos que significam incomum, mas não excepcional, operação. Estes
são uma indicação de que a situação pode exigir mais perto
monitoramento. Em alguns casos, a condição irá resolver-se, por
exemplo, no caso de uma combinação invulgar de carga de trabalhos - a
sua conclusão, a operação normal é restaurard. Em outros casos, a
intervenção do operador podem ser necessários, se a situação é repetido
ou se continua por muito tempo. Essas regras ou políticas são definidas
nos Objectivos de monitoramento e controle para esse dispositivo ou
serviço. Exemplos deste tipo de evento são:
• AservidorUtilização da memória atinge até 5% da sua máxima
aceitável atuação nível
• O tempo de conclusão de uma transação é 10% maior do que o
normal.

Duas coisas são significativos sobre os exemplos acima:
• Exatamente o que constitui o funcionamento normal versus anormal,

contra uma exceção? Não existe uma regra definitiva sobre isso. Por
exemplo, um fabricante pode prever que um referência da utilização da
memória 75% é o ideal para aplicação X. No entanto, descobriu-se que,
sob as condições específicas da nossa organização,tempo de respostas
começam a degradar acima utilização de 70%. A próxima seção irá
explorar como esses números são determinados.
• Cada conta com o envio e a recepção de uma mensagem de algum tipo.
Estes são geralmente referidos como notificações de eventos e eles não
acontecem por acaso. Os próximos parágrafos vai explorar exatamente
como os eventos são definidos, gerado e capturado.

4.1.5 as atividades de processo, métodos e técnicas
Figura 4.1 O processo de Gestão de Eventos
Figura 4.1 é uma representação de alto nível e genérico de Gestão de Eventos.

Ele deve ser usado como um ponto de referência e definição, em vez de um
fluxograma de Gestão real do evento. Cada atividade neste processo é descrito
abaixo.

4.1.5.1 Evento ocorre
Eventos ocorrem continuamente, mas nem todos eles são detectados ou

registados. Portanto, é importante que todos os envolvidos no projeto,
desenvolvimento, gestão e suporte De serviços de TIs e a Infraestrutura de TI
que são executados entende que tipos de evento precisa ser detectado.
Isso é discutido no parágrafo 4.1.10.1, intitulado "Instrumentação".
4.1.5.2 Notificação de eventos
Mais CIs são projetados para comunicar certas informações sobre si mesmos
em uma de duas maneiras:
• Um dispositivo é interrogado por uma ferramenta de gestão, que recolhe

alguns dados segmentados. Isso é muitas vezes referido como voto.
• O CI gera uma notificação quando certas condições são satisfeitas. A
capacidade para produzir estas notificações tem de ser concebido e
construído para o CI, por exemplo um gancho de programação inserido
numa aplicação.
As notificações de eventos pode ser patenteado, caso em que apenas

ferramentas de gestão do fabricante pode ser utilizada para detectar eventos.
Mais CIs, no entanto gerar notificações de eventos usando um aberto padrão
tais como o SNMP (Simple Network Management Protocol).
CIs Muitos estão configurado para gerar um conjunto padrão de eventos, com
base na experiência do designer do que é necessário para operar o CI, com a
capacidade de gerar outros tipos de eventos de 'ligando' o mecanismo de
geração de evento relevante. Para outros tipos de ignição por compressão, de
alguma forma de software "agente" terá de ser instalado, a fim de dar início ao
monitoramento. Muitas vezes, esse recurso de monitoramento é livre, mas às
vezes há um custar para o licenciamento da ferramenta.
Em um mundo ideal, a Design de Serviços processo deve definir quais eventos

precisam ser geradas e especificar como isso pode ser feito para cada tipo de
IC. Durante Transição de Serviço, As opções de geração de eventos seria
definido e testado.
Em muitas organizações, no entanto, a definição de quais eventos geram é feito

por tentativa e erro. Sistema gerentes usam o conjunto padrão de eventos como
um ponto de partida e, em seguida, ajustar o IC ao longo do tempo, para incluir
ou excluir eventos conforme necessário. O problema com esta abordagem é que
ela só leva em conta as necessidades imediatas da equipe gerenciamento do
dispositivo e não facilita a boa planejamento ou melhoria. Além disso, torna-se
muito difícil de monitorar e gerenciar o serviço sobre todos os dispositivos e

funcionários. Uma abordagem para combater este problema consiste em rever o
conjunto de eventos, como parte das atividades de melhoria contínua.
Um princípio geral de notificação de eventos é que a mais significativa os dados

que ele contém e do público mais segmentado, mais fácil é para tomar decisões
sobre o evento. Operadores são frequentemente confrontados por codificada
erro mensagens e não têm idéia de como responder a elas ou o que fazer com
eles. Dados significativos de notificação e claramente definidos papels e
responsabilidades precisam ser articulados e documentados durante Transição
de Serviço Design e Serviços (ver também o parágrafo 4.1.10.1 em
"Instrumentação"). Se papels e as responsabilidades não são claramente
definidas, em uma ampla alertar, Ninguém sabe quem está fazendo o que e isso
pode levar a coisas que estão sendo perdidas ou duplicadas esforços.
4.1.5.3 Detecção de eventos
Uma vez que uma notificação de eventos foi gerado, ele será detectado por um
agente rodando no mesmo sistema, ou transmitida directamente para uma
ferramenta de administração especificamente concebido para ler e interpretar o
significado do evento.
4.1.5.4 Evento filtragem
O objetivo da filtragem é decidir se a comunicar a evento de uma ferramenta de

gestão ou ignorá-lo. Se ignorado, o evento geralmente será gravada em um
arquivo de log no dispositivo, mas nenhuma outra ação será tomada.
A razão para a filtragem é que nem sempre é possível transformar Evento

notificação fora, mesmo que uma decisão foi feita de que não é necessário para
gerar esse tipo de evento. Também pode ser decidido que apenas o primeiro de
uma série de repetidas Evento notificações serão transmitidos.
Durante a etapa de filtragem, o primeiro nível de correlação é realizada, isto é, a

determinação de se o evento é informativa, de aviso ou de exceção (veja o
próximo passo). Esta correlação é feita geralmente através de um agente que
reside no CI ou numa servidor para que o IC está ligado.
A etapa de filtragem não é sempre necessário. Para alguns itens de

configuração, cada evento é significativo e move directamente no motor de uma
ferramenta de gestão de correlação de, mesmo se for duplicada. Além disso, ele
pode ter sido possível desligar todos os indesejados Evento notificações.
4.1.5.5 Significado de eventos

Cada organização terá sua própria categorização da importância de um evento,
Mas sugere-se que pelo menos as seguintes três categorias amplas ser
representado:
• Informativo: Isto refere-se a um evento que não exige qualquer acção e

não representa uma excepção. Eles são normalmente armazenados no
sistema ou serviço arquivos de log e mantido por um período pré-
determinado. Informativa eventos são normalmente utilizados para
verificar o status de um dispositivo ou serviço, ou para confirmar a
conclusão bem sucedida de uma atividade. Informativa eventos também
podem ser usados para gerar estatísticas (tais como o número de
usuários conectado a uma aplicação durante um certo período) e como
entrada para investigações (como os trabalhos que concluída com êxito
antes do transação fila de processamento pendurado). Exemplos de
informação eventos incluem:
• Um usuário faz logon em um aplicação
• Um trabalho na fila de lote concluída com êxito
• Um dispositivo está online
• Uma transação é concluída com êxito.
• Aviso: Um aviso é uma evento que é gerado quando um serviço ou
dispositivo se aproxima de um limiar. Avisos destinam-se a notificar a
pessoa adequada, processo ou ferramenta para que a situação pode ser
verificada eo tomadas as medidas adequadas para prevento uma
exceção. Advertências não são tipicamente criados para um dispositivo
falha. Embora haja algum debate sobre se a falha de um dispositivo
redundante é um aviso ou uma exceção (desde que o serviço ainda está
disponível). Uma boa regra é que cada falha deve ser tratado como uma
exceção, já que o risco de um incidente impactando o negócio é muito
maior. Exemplos de avisos são:
• Utilização de memória em um servidor é atualmente a 65% e
crescente. Se atingir 75%, tempo de respostas será
demasiadamente longo e OLA para o departamento será
ultrapassado.
• A taxa de colisão em uma rede aumentou 15% em relação a última
hora.
• Exceção: Uma excepção significa que um serviço ou dispositivo está
operando de forma anormal (no entanto, que tenha sido definido).
Tipicamente, isto significa que um e OLA SLA foram violados eo negócio
está sendo afetado. Exceções podem representar um total falha,
Funcionalidade prejudicada ou degradadas atuação. Observe, porém, que
uma exceção nem sempre representa uma incidente. Por exemplo, uma
exceção pode ser gerada quando um dispositivo não autorizado for
detectado na rede. Isso pode ser gerenciado usando qualquer um Grave
incidente ou um Requisição de Mudança (Ou mesmo ambas), de acordo
com o organizaçãoIncidentes 's e Gestão da Mudança políticas. Exemplos
de exceções incluem:

• Aservidor é baixo
• O tempo de resposta de um padrão transação em toda a rede
reduziu-se a mais de 15 segundos
• Mais de 150 usuários ter conectado ao General Ledger aplicação
concorrentemente
• Um segmento da rede não está respondendo às solicitações de
rotina.
4.1.5.6 correlação de eventos
Se um evento é significativo, uma decisão tem de ser feita sobre o que

exatamente é o significado e as ações que precisam ser tomadas para lidar com
isso. É aqui que o significado do evento é determinado.
Correlação é normalmente feito por um "Correlação Engine ', geralmente parte

de uma ferramenta de gerenciamento que compara o evento com um conjunto
de critérios e regras de uma ordem prescrita. Estes critérios são freqüentemente
chamados de Regras de Negócios, embora eles geralmente são bastante
técnico. A idéia é que o evento pode representar algum impacto sobre a
actividade e as regras pode ser utilizado para determinar o nível e tipo de
impacto comercial.
Um mecanismo de correlação é programado de acordo com os padrões de

desempenho criados durante Design de Serviços e qualquer orientação
adicional específico para a operação ambiente.
Exemplos do que mecanismos de correlação levará em conta incluem:
• Número de eventos similares (por exemplo, esta é a terceira vez que o

mesmo usuário tenha se conectado com a senha incorreta, um aplicativo
de negócios relata que houve um padrão incomum de uso de um telefone
móvel que poderia indicar que o dispositivo for perdido ou roubado)
• Número de CIs gerando eventos semelhantes
• Se uma acção específica está associada com o código de dados ou no
caso
• Se o evento representa uma excepção
• Uma comparação das informações em caso de utilização com um padrão
máximo ou mínimo (por exemplo, o dispositivo tem uma excedido limiar?)
• Se os dados adicionais é necessário para investigar o evento ainda mais,
e possivelmente até mesmo uma coleção de dados por solicitação de
outro sistema ou banco de dados
• Categorização do evento
• A atribuição de um prioridade nível ao evento.
4.1.5.7 Gatilho

Se a correlação atividade reconhece um evento, A resposta será necessária. O
mecanismo utilizado para iniciar a resposta, que é chamada de um gatilho.
Existem muitos tipos diferentes de disparadores, cada um desenhado

especificamente para a tarefa, tem de iniciar. Alguns exemplos incluem:
• Incidente Gatilhos que geram uma registro no Gerenciamento de

Incidentes sistema, Iniciando assim o Gerenciamento de Incidentes
processo
• Alterar gatilhos que geram uma Requisição de Mudança (RFC), iniciando
assim a Gestão da Mudança processo
• Um gatilho resultante de um RFC aprovado que tenha sido aplicada, mas
fez com que o evento ou a partir de uma alteração não autorizada que
tenha sido detectado - em qualquer dos casos, este será referido Change
Management para investigação
• Scripts que executam ações específicas, como enviar trabalhos de grupo
ou reiniciar um dispositivo
• Sistemas de paginação que irá notificar uma pessoa ou equipe do evento
pelo telefone celular
• Gatilhos de banco de dados que restringem o acesso de um usuário aos
registros ou domínios específicos, ou que criar ou excluir entradas no
banco de dados.
4.1.5.8 Resposta seleção
Neste ponto do processo, há uma série de opções de respostas disponíveis. É

importante notar que as opções de resposta pode ser escolhido em qualquer
combinação. Por exemplo, pode ser necessário para manter a entrada de log
para referência futura, mas, ao mesmo tempo aumentar o evento para uma
Gestão de Operações membro da equipe para a ação.
As opções no fluxograma são exemplos. Diferentes organizações terão opções

diferentes, e têm a certeza de ser mais detalhada. Por exemplo, haverá uma
gama de respostas auto para cada tecnologia diferente. O processo de
determinar qual é apropriada e a forma de executar, não estão representados
neste fluxograma. Algumas das opções disponíveis são:
• Evento registrado: Independentemente do que atividade é realizado, é

uma boa idéia ter um registro do evento e quaisquer ações subseqüentes.
O evento pode ser registrado como um registro de eventos na Gestão de
Eventos ferramenta, ou pode simplesmente ser deixada como uma
entrada no registro do sistema do dispositivo ou aplicação que gerou o
evento. Se este for o caso, porém, é preciso que haja uma ordem
permanente para o pessoal adequado Gestão de Operações para
verificar os registros em uma base regular e instruções claras sobre como
utilizar cada log. Também deve ser lembrado que as informações do

evento nos logs podem não ser significativos até que um incidente ocorre,
e onde o Gestão Técnica pessoal usar os logs para investigar onde o
incidente originou. Isto significa que o evento de Gestão procedimentos
para cada sistema ou a equipe precisa definir padrãos sobre como
eventos longos são mantidos nos registros antes de serem arquivados e
excluídos.
• Resposta automática: Alguns eventos, são bem que a resposta
adequada já foi definido e automatizado. Esta é, normalmente, como
resultado da boa projeto ou da experiência anterior (geralmente
Gerenciamento de Problemas). O gatilho irá iniciar a ação e, em seguida,
avaliar se ela foi concluída com êxito. Se não, um incidente ou Grave
problema será criada. Exemplos de respostas auto incluem:
• Reiniciando um dispositivo
• Reiniciando um serviço
• Apresentar um trabalho em lote
• A alteração do parâmetro em um dispositivo
• Bloqueio de um dispositivo ou aplicação para protegê-lo contra o
acesso não autorizado.
Nota: bloqueio de um dispositivo pode resultar em negação de serviço

autorizado usuários, que pode ser explorada por um atacante deliberada -
cuidado tão grande deve ser tomado quando decidir se esta é uma ação
apropriada automatizado. Se esta resposta for usado, ele pode ser
prudente também combinar isso com uma chamar por intervenção
humana, de modo que a acção automatizada pode ser prontamente
verificado e aprovado.
• Alertar e intervenção humana: Se o evento requer intervenção humana,

que terá de ser escalado. O objetivo do alerta é para garantir que a
pessoa com as competências adequadas para lidar com o evento é
notificado. O alerta vai conter todas as informações necessárias para que
a pessoa para determinar a ação apropriada - incluindo a referência a
qualquer documentação necessária (manuais do usuário, por exemplo). É
importante notar que este não é necessariamente o mesmo que o
escalada funcional de um incidente, Onde a ênfase é sobre a restauração
do serviço dentro de um prazo acordado (o que pode exigir uma
variedade de atividades). O alerta requer uma pessoa, ou equipe, para
executar uma ação específica, possivelmente em um dispositivo
específico e, possivelmente, em um momento específico, por exemplo,
trocar um cartucho de toner de uma impressora quando o nível está
baixo.
• Incidente,problema ou mudar? Alguns eventos representam uma situação
em que a resposta adequada terá de ser tratado através do incidente,
problema ou Gestão da Mudança processo. Estes são discutidos abaixo,
mas é importante salientar que um único incidente pode dar início a
qualquer um ou uma combinação destes três processos - por exemplo,

um não-crítico servidor falha é registrado como um incidente, mas como
não há solução alternativa, Um Grave problema é criada para determinar
o causa raiz e resolução e um RFC é logado para mudar o local da carga
de trabalho para um servidor alternativo enquanto o problema é resolvido.
• Abra uma RFC: Há dois lugares no processo de Gestão de Eventos,
onde um RFC podem ser criados:
• Quando ocorre uma exceção: Por exemplo, uma varredura de
um segmento de rede revela que dois novos dispositivos foram
adicionados sem a autorização necessária. Uma forma de lidar
com esta situação é o de abrir um RFC, que pode ser usado como
um veículo para o processo de gestão da mudança para lidar com
a exceção (como uma alternativa para o método mais convencional
de abertura de um incidente que seriam encaminhadas através do
Service Desk ao Gerenciamento de Mudanças). Investigação pelo
Gerenciamento de Mudanças é apropriado aqui desde alterações
não autorizadas implicam que o processo de Gerenciamento de
Mudança não foi eficaz.
• Correlação identifica que um mudar é necessário: Neste caso, o
evento correlação atividade determina que a resposta adequada a
um evento é algo para ser mudado. Por exemplo, um atuação
limiar tiver sido atingido, e um parâmetro de um servidor principal
precisa de ser ajustado. Como a atividade correlação determinar
isso? Foi programado para o fazer, quer no Design de Serviços
processar ou porque isso já aconteceu antes e Gerenciamento de
Problemas ou Gestão de Operações atualizou o Mecanismo de
Correlação de tomar esta ação.
• Abra uma Grave incidente: Tal como acontece com uma RFC, um
incidente pode ser gerado imediatamente quando uma exceção é
detectada, ou quando o motor de correlação determina que um tipo
específico ou combinação de eventos representa um incidente. Quando
um registro de incidentes é aberto, as informações, tanto quanto possível,
deve ser incluído - com links para os eventos em questão e, se possível
uma completa script de diagnóstico.
• Abrir ou vincular a um Grave problema: É raro que um registro de
problema a ser aberto sem incidentes relacionados (por exemplo, como
resultado de um Análise de falha de serviço (Ver Design de Serviços
publicação) ou maturidade avaliação, Ou por causa de um número
elevado de tentativas rede erros, apesar de um falha ainda não ocorreu).
Na maioria dos casos esta etapa refere-se à ligação de um incidente a um
registro de problema existente. Isso vai ajudar a Gerenciamento de
Problemas equipes para reavaliar a gravidade e impacto do problema, E
pode resultar numa alteração prioridade a um problema de circulação.
No entanto, é possível, com algumas das ferramentas mais sofisticadas,

para avaliar o impacto dos incidentes e também para elevar um registro

de problema automaticamente, quando assim o permitam, para permitir a
análise de causas básicas para começar imediatamente.
• Tipos especiais de incidente: Em alguns casos, um evento irá indicar

uma exceção que não impactam diretamente qualquer De serviços de TI,
Por exemplo, uma unidade de condicionamento de ar redundante falha,
ou a entrada não autorizada para um centro de dados. Diretrizs para
estes acontecimentos são as seguintes:
• Um incidente deve ser registrado usando um incidente Modelo que
é adequado para o tipo de excepção, por exemplo, um incidente de
Operações ou Segurança Incidente (ver parágrafo 4.2.4.2 para
mais detalhes de Incidentes Modelos).
• O incidente deve ser escalada para o grupo que gerencia esse tipo
de incidente.
• Como não há interrupção, o Modelo de Incidente usado deve
reflectir que esta era uma operacional em vez de emitir uma
serviço questão. As estatísticas não seria normalmente reportado
para os clientes ou usuários, a menos que possam ser utilizados
para demonstrar que o dinheiro investido em redundância foi um
bom investimento.
• Estes incidentes não devem ser utilizados para calcular tempo de
inatividade, E pode de facto ser utilizado para demonstrar como
proactiva TI tem sido tornar os serviços disponíveis.
4.1.5.9 Rever as acções
Com milhares de eventos que estão sendo gerados a cada dia, não é possível
formalmente rever cada evento individual. No entanto, é importante verificar que
todos os eventos significativos ou exceções foram tratadas de forma adequada,
ou para acompanhar as tendências ou contagens de tipos de eventos, etc Em
muitos casos, isso pode ser feito automaticamente, por exemplo votação um
servidor que havia sido reiniciado usando um script automático para ver se ele
está funcionando corretamente.
Nos casos em que os acontecimentos tenham iniciado o incidente, problema e /

ou mudar, A revisão de Acção não deve duplicar quaisquer críticas que têm sido
feitos como parte desses processos. Pelo contrário, a intenção é a de assegurar
que a transição entre a Gestão de Eventos processo e outros processos ocorreu
como projetado e que a ação esperada, de fato, ocorrer. Isso irá garantir que
incidentes, problemas ou mudanças originadas dentro Gestão de Operações
não se perder entre as equipes ou departamentos.
O Comente também será utilizado como entrada para a melhoria contínua ea

avaliação e auditar do Gestão de Eventos processo.
4.1.5.10 evento Close

Alguns eventos irá permanecer aberto até que uma certa acção tem lugar, por
exemplo, um evento que é ligado a uma abertura incidente. No entanto, a
maioria dos eventos não são 'abriu' ou 'fechado'.
Eventos informativos são simplesmente registrados e então usado como entrada

para outros processos, como backup e Storage Management. Auto-resposta
eventos irá tipicamente ser fechada através da geração de um segundo evento.
Por exemplo, um dispositivo gera um evento e é reiniciado através de resposta
automática -, logo que o dispositivo é sucesso de volta online, ele gera um
evento que efetivamente fecha o ciclo e limpa o primeiro evento.
Às vezes é muito difícil relacionar o evento aberto e as notificações perto quanto

eles são em diferentes formatos. É ideal que os dispositivos na infra-estrutura
produzir eventos "abertos" e "fechar" no mesmo formato e especificar a
mudança de status. Isto permite que o passo de correlação no processo de
facilmente adaptar as notificações de abrir e fechar.
No caso de eventos que geraram um incidente, problema ou mudar, Estes

devem ser formalmente encerrada com um link para o adequado registro a partir
de outro processo.
4.1.6 Triggers interfaces de entrada e saída / inter-processo
Gestão de Eventos pode ser iniciado por qualquer tipo de ocorrência. A chave é
definir qual dessas ocorrências é importante e que precisa ser colocada em
prática. Gatilhos incluem:
• Exceções a qualquer nível de CI atuação definido na projeto

especificaçãos, OLAs ou SOPs
• As exceções a um sistema automatizado procedimento ou um processo,
por exemplo, uma rotina mudar que tem sido atribuída a um construir
equipe não foi concluído a tempo
• Uma excepção a uma processo de negócio que está sendo monitorado
pela Gerência de Eventos
• A conclusão de uma tarefa ou trabalho automatizado
• Aestado mudar em um dispositivo ou registro de dados
• Acesso de um aplicação ou banco de dados por um usuário ou
procedimento automatizado ou trabalho
• Uma situação em que um dispositivo de banco de dados ou aplicações,
etc atingiu um predefinido limiar de desempenho.
Gestão de Eventos pode fazer interface com qualquer processo que requer
monitoramento e controlar, Especialmente aqueles que não necessitam de
monitorização em tempo real, mas que exigem alguma forma de intervenção
após um evento ou grupo de eventos. Exemplos de interfaces com outros
processos incluem:

• Interface com aplicações de negócio e / ou processos de negócios para
permitir que eventos de negócios potencialmente importantes a serem
detectadas e corrigidas (por exemplo, um aplicativo de negócios relata
anormal atividade num clienteO relato de que podem indicar algum tipo
de fraude ou segurança violação).
• O principal ITSM relaçãos são com Incidente, Problema e Gerenciamento
de Mudanças. Estas interfaces são descritas com algum pormenor no
ponto 4.1.5.8.
• Capacidade e Gerenciamento de Disponibilidade são fundamentais na
definição do que eventos são significativos, o que adequado limiars deve
ser e como responder a eles. Em troca, Gestão de Eventos melhorará a
atuação e disponibilidade de serviços por responder a eventos quando
eles ocorrem e, relatando acontecimentos reais e padrões de eventos
para determinar (por comparação com as metas de SLA e KPIs) se
houver algum aspecto da infra-estrutura projeto ou operação que pode
ser melhorado.
• Gerenciamento da Configuração é capaz de usar os eventos para
determinar o status atual de qualquer IC na infra-estrutura. Comparando
eventos com o autorizado linha de bases no Sistema de Gerenciamento
da Configuração (CMS) vai ajudar a determinar se existe não autorizada
Mudar atividade a ter lugar no organização (Ver Transição de Serviço
publicação).
• Gestão de Ativos (Coberto com mais detalhes no Design de Serviços e
publicações de transição) pode usar o Gerenciamento de eventos para
determinar o ciclo de vida estado de ativoss. Por exemplo, um evento
pode ser gerado para indicar que um novo activo foi configurado com
sucesso e é agora operacional.
• Os eventos podem ser uma fonte rica de informações que podem ser
processados para inclusão em Gestão do Conhecimento sistemas. Por
exemplo, os padrões de desempenho pode ser correlacionada com a
actividade e utilizado como entrada para futura concepção e estratégia
decisões.
• Gestão de eventos podem desempenhar um importante papel no sentido
de garantir que o potencial impacto em SLAs é detectado precocemente e
qualquer falhas são rectificadas, logo que possível, de modo que o
impacto na serviço alvos é minimizado.
4.1.7 Gestão da Informação
Informações-chave envolvidos em Gestão de Eventos inclui o seguinte:
• Mensagens SNMP, que são uma forma padrão de comunicar informação

técnica sobre o estado de componentes de um Infraestrutura de TI.
• Gestão da Informação Bases (MIBs) de dispositivos de TI. Uma MIB é o
banco de dados em cada dispositivo que contém informações sobre o
dispositivo, incluindo o seu sistema operacional, o BIOS

versão,configuração dos parâmetros do sistema, etc A capacidade de
interrogar MIBs e compará-los a uma norma é fundamental para ser
capaz de gerar eventos.
• Vendedor monitoramento ferramentas de software agente.
• Motores de correlação conter regras para determinar o significado ea
resposta apropriada aos eventos. Detalhes sobre este são fornecidos no
parágrafo 4.1.5.6.
• Não há eventos padrão Registro para todos os tipos de evento. O
conteúdo exato e formato do registro dependem das ferramentas que
estão sendo usadas, o que está sendo monitorado (por exemplo, um
servidor e a Gestão da Mudança ferramentas terá dados muito diferentes
e, provavelmente, usar um formato diferente). No entanto, existem alguns
dados-chave que é normalmente exigido em cada evento para ser útil em
análise. Deve incluem tipicamente o:
• Dispositivo
• Componente
• Tipo de falha
• Data / hora
• Parâmetros em exceção
• Valor.
4.1.8 Métricas
Para cada período de medição em questão, o métricos para verificar o eficácia e

eficiência do Gestão de Eventos processo deve incluir o seguinte:
• Número de eventos por categoria

• Número de eventos por significado
• Número e porcentagem de eventos que necessitaram de intervenção
humana e se esta foi realizada
• Número e porcentagem de eventos que resultou em incidentes ou
mudanças
• Número e porcentagem de eventos provocados por existir problemas ou
erros conhecidos. Isto pode resultar numa alteração na prioridade de
trabalho em que o problema ou Erro Conhecido
• Número e porcentagem de eventos repetidos ou duplicados. Isso vai
ajudar na afinação do Mecanismo de Correlação de eliminar a geração de
eventos desnecessário e pode também ser utilizada para auxiliar no
projeto de melhor funcionalidade evento geração em novos serviços
• Número e porcentagem de eventos indicando atuação problemas (por
exemplo, o crescimento do número de vezes que um aplicação excedeu a
sua transação limiars nos últimos seis meses)
• Número e porcentagem de eventos indicando potencial disponibilidade
questões (failovers por exemplo, para dispositivos alternativos, ou
excessivo carga de trabalho swapping)
• Número e percentual de cada tipo de evento por plataforma ou aplicação

• Número e proporção de eventos em comparação com o número de
incidentes.
4.1.9 Desafios, Fatores Críticos de Sucesso e riscos
4.1.9.1 Desafios
Há um número de desafios que podem ser encontrados:
• Um desafio inicial pode ser a obtenção de financiamento para as

ferramentas necessárias e esforço necessários para instalar e explorar os
benefícios das ferramentas.
• Um dos maiores desafios é definir o nível correto de filtragem. Definir o
nível de filtragem incorretamente pode resultar em um ser inundado com
relativamente insignificante eventos, ou não ser capaz de detectar
eventos relativamente importantes, até que seja tarde demais.
• A implantação do necessário monitoramento agentes em toda a
infraestrutura de TI inteira pode ser uma tarefa difícil e demorada
atividade exigindo um compromisso contínuo por um longo período de
tempo - há um perigo de que as atividades podem surgir outras que
poderiam desviar recursos e atrasar o lançamento.
• Adquirir as habilidades necessárias pode ser demorado e caro.
4.1.9.2 Fatores Críticos de Sucesso
A fim de obter o financiamento necessário um Business Case convincente deve

ser preparado mostrando como os benefícios da efetiva Gestão de Eventos
podem ultrapassar de longe a custars - dando um retorno positivo sobre o
investimento.
Um dos mais importantes é QCA atingir o nível correto de filtragem. Isto é

complicado pelo facto de a importância das alterações eventos. Por exemplo,
um usuário login em um sistema hoje é normal, mas se o usuário deixa o
organização e tenta entrar é uma segurança violação.
Há três chaves para o nível correcto de filtragem, da seguinte forma:
• Integrar a Gestão de evento em toda a Serviço de Gestão de processos

sempre que possível. Isto assegurará que apenas os eventos
significativos para estes processos são descritos.
• Concepção de novos serviços com Gestão de Eventos em mente (isto é
discutido em detalhes no parágrafo 4.1.10).
• Tentativa e erro. Não importa o quão completamente Gestão de Eventos
é preparado, haverá aulas de eventos que não são devidamente filtrados.
Gestão de Eventos deve, portanto, incluir um formal processo para avaliar
a eficácia de filtragem.

Adequado planejamento é necessário para a distribuição do software do agente
de monitoramento em toda a infra-estrutura de TI inteiro. Isto deve ser
considerado como um projeto com prazos realistas e recursos adequados sendo
alocado e protegidos durante todo o período de duração do projeto.
4.1.9.3 Riscos
A chave riscos são realmente os já mencionados acima: a incapacidade de obter

financiamento adequado, garantindo o nível correto de filtragem, ea falha para
manter a dinâmica na implementação de agentes de controlo necessárias em
todo o Infraestrutura de TI. Se algum destes riscos não são os destinatários que
poderia adversamente impacto sobre o sucesso da Gestão de Eventos.
4.1.10 Projeto de Gestão de Eventos
Gestão de Eventos eficaz não é projetado, uma vez por serviço foi implantado
em Operações. Desde Gestão de Eventos é a base para o acompanhamento da
atuação e disponibilidade de um serviço, as metas exatas e mecanismos de
monitoramento devem ser especificadas e acordadas durante a disponibilidade e
Gerenciamento da Capacidade processos (ver Design de Serviços publicação).
No entanto, isso não significa que a Gestão de Eventos foi projetado por um
grupo de controle remoto sistema desenvolvedores e, em seguida, liberado para
Gestão de Operações juntamente com o sistema que tem de ser gerida.
Também não quer dizer que, uma vez desenvolvido e acordado, Gestão de
Eventos se torna estática - dia-a-dia operaçãos vai definir adicional eventos,
prioridades, alertars e outras melhorias que irão alimentar através da Melhoria
Contínua processo volta Estratégia de Serviço,Design de Serviços etc
Operação de Serviço funçãos deverão participar na projeto do serviço e como

ela é medida (ver secção 3.4).
Para Gestão de Eventos, As áreas de concepção específicos incluem o

seguinte.
4.1.10.1 Instrumentação
Instrumentação é a definição do que pode ser monitorado sobre CIs e da

maneira em que o seu comportamento pode ser afetado. Em outras palavras, a
instrumentação é sobre como definir e projetar exatamente como monitorar e
controlar o Infraestrutura de TI e De serviços de TIs.
Instrumentação é parte de um conjunto de decisões que precisam ser feitas e,

em parte, sobre a criação de mecanismos para executar essas decisões.
Decisões que precisam ser tomadas incluem:

• O que precisa ser monitorado?
• Que tipo de acompanhamento é necessária (por exemplo, ativa ou
passiva; atuação ou saída)?
• Quando precisamos de gerar um evento?
• Que tipo de informação deve ser comunicada no evento?
• Quem são as mensagens destinados?
Mecanismos que precisam ser projetados incluem:
• Como os eventos ser gerados?

• O IC já tem mecanismos de geração de eventos como um recurso padrão
e, em caso afirmativo, qual destes será utilizado? São suficientes ou não
o CI precisa ser personalizado para incluir mecanismos adicionais ou
informações?
• Os dados que serão usados para preencher o Evento Registro?
• São eventos gerados automaticamente ou se o CI tem que ser buscado?
• Onde vai ser eventos registrados e armazenados?
• Como os dados complementares ser recolhidas?
Nota: Uma interface forte existe aqui com o aplicação'S design. Todas as
aplicações devem ser codificadas de tal maneira que significativa e detalhado
erro mensagens / códigos são gerados no ponto exato de falha - De modo que
estes podem ser incluídos no evento e permitir rápida diagnóstico e resolução da
causa subjacente. A necessidade da inclusão e teste de mensagens de erro do
tipo é descrita em mais detalhe no Transição de Serviço publicação.
4.1.10.2 mensagens de erro
Mensagens de erro é importante para todos componentes (hardware, software,

redes, etc.) É particularmente importante que todos os aplicativos são projetados
para suportar Gestão de Eventos. Isso pode incluir o fornecimento de
mensagens de erro significativo e / ou códigos que indicam claramente o ponto
específico de falha ea causa mais provável. Em tais casos, o teste de novo
aplicaçãos deve incluir o teste de precisão evento geração.
Novas tecnologias como Java Management Extensions (JMX) ou HawkNL ™

fornecer as ferramentas para a construção de distribuídos, baseados na web,
soluções modulares e dinâmica para a gestão e monitoramento dispositivos,
aplicações e serviçoOrientados por redes. Estes podem ser usados para reduzir
ou eliminar a necessidade de os programadores para incluir erro mensagens
dentro do código - permitindo um nível importante de normalização e de código-
independência.
4.1.10.3 de detecção de eventos e mecanismos de alerta

Bom Gestão de Eventos projeto também incluem a concepção e população das
ferramentas utilizadas para filtrar, correlacionar e escalar Eventos.
O Mecanismo de Correlação especificamente terá de ser preenchido com as

regras e critérios que irão determinar o significado e subseqüente ação para
cada tipo de evento.
Projeto completo do evento detecção e alertar mecanismos requer o seguinte:
• Conhecimento do negócio em relação para qualquer processo de

negócioes a ser gerido através de Gestão de Eventos
• Conhecimento detalhado do Exigência de Nível de Serviços do serviço a
ser suportado por cada CI
• Conhecimento de quem vai ser o apoio à CI
• Conhecimento do que constitui normal e anormal operação da CI
• Conhecimento do significado de vários eventos semelhantes (na CI
mesmo ou semelhante vários CIs
• Uma compreensão do que eles precisam saber para apoiar o CI
efetivamente
• Informações que podem ajudar na diagnóstico de problemas com o CI
• Familiaridade com incidente códigos de prioridade e categorização de
modo que, se é necessário criar um Grave incidente, Esses códigos
podem ser fornecidos
• O conhecimento de outros CIs que pode ser dependente da CI afectado,
ou os IC da qual depende
• Disponibilidade de Erro Conhecido informações de fornecedores ou de
experiência anterior.
4.1.10.4 Identificação de limiares
Limiars mesmos não estão definidos e gerenciados através de Gerenciamento

de Eventos. No entanto, a menos que estas sejam devidamente projetado e
comunicado durante a instrumentação processo, Será difícil determinar qual o
nível de atuação é apropriada para cada IC.
Além disso, a maioria dos limiares não são constantes. Eles consistem
tipicamente de uma série de variáveis relacionadas. Por exemplo, o número
máximo de concorrentes usuários antes tempo de resposta retarda vai variar
dependendo do que outros trabalhos estão ativos no servidor. Este
conhecimento é muitas vezes só ganhou por experiência, o que significa que os
motores de correlação tem que ser continuamente atento e atualizado através
do processo de Melhoria de Serviço Continuada.

4.2 Gestão de Incidentes
Em ITIL terminologia, um 'incidente'É definido como:
Uma interrupção não planejada a um De serviços de TI ou redução do qualidade

de um serviço de TI. Falha de um item de configuração que ainda não tenha
impacto serviço É também um incidente, por exemplo falha de um disco a partir
de um conjunto de espelho.
Gerenciamento de Incidentes é o processo para lidar com todos os incidentes, o

que pode incluir falhas, perguntas ou perguntas relatados pela usuários
(usualmente através de um telefone chamar ao Service Desk), Pela equipe
técnica, ou automaticamente detectado e reportado pelo evento monitoramento
ferramentas.
O principal objetivo do processo de Gerenciamento de Incidentes é restaurar

normal operação de serviço o mais rapidamente possível e minimizar os efeitos
adversos impacto em operações comerciais, Garantindo assim que os melhores
níveis possíveis de qualidade de serviço e disponibilidade são mantidos.
'Operação de serviço Normal' é definida aqui como operação de serviço dentro
SLA limites.
4.2.2 Âmbito
Gerenciamento de Incidentes inclui qualquer evento que perturbe, ou o que

poderia interromper, um serviço. Isso inclui eventos que são comunicados
diretamente pelos usuários, seja por meio da Central de Serviços ou através de
uma interface de Gestão de Eventos a ferramentas de gerenciamento de
incidentes.
Os incidentes podem também ser comunicados e / ou registrados pela equipe

técnica (se, por exemplo, eles percebem algo desagradável com um hardware
ou rede componente eles podem denunciar ou fazer um incidente e remetê-lo
para o Posto de Serviço). Isso não significa, entretanto, que todos os eventos
são incidentes. Muitas classes de eventos não estão relacionados a interrupções
em tudo, mas são indicadores de operação normal ou são simplesmente
informativa (ver secção 4.1).
Embora ambos os incidentes e solicitação de serviços são relatados para o

Service Desk, isso não significa que eles são os mesmos. Solicitações de
serviço não representam uma interrupção do serviço acordado, mas são uma
maneira de atender a cliente'S precisa e pode ser uma abordagem meta
acordada em um SLA. Solicitações de serviços são tratados pelo Cumprimento
de Requisição processo (ver secção 4.3).

O valor do Gerenciamento de Incidentes inclui:
• A capacidade de detectar e resolver incidentes o que resulta em menor

tempo de inatividade para o negócio, o que por sua vez significa uma
maior disponibilidade do serviço. Isto significa que a actividade é capaz
de explorar a funcionalidade do serviço, como desenhado.
• A capacidade de alinhar a TI atividade às prioridades comerciais em
tempo real. Isto é porque Gerenciamento de Incidentes inclui a
capacidade de identificar as prioridades de negócios e alocar
dinamicamente recursos conforme necessário.
• A capacidade de identificar potenciais melhorias aos serviços. Isto
acontece como resultado da compreensão do que constitui um incidente e
também de estar em contacto com as actividades de negócio operacional
pessoal.
• O Service Desk pode, durante seu tratamento de incidentes, identificar
adicional serviço ou formação exigências encontradas em TI ou o
negócio.
Gerenciamento de Incidentes é altamente visível para o negócio, e por isso é

mais fácil de demonstrar o seu valor do que a maioria das áreas em Operação
de Serviço. Por esta razão, Gerenciamento de Incidentes é muitas vezes um dos
primeiros processos a serem implementadas em Serviço de Gestão de projetos.
A vantagem de fazer isso é que Gerenciamento de Incidentes pode ser usado
para destacar outras áreas que precisam de atenção - proporcionando assim
uma justificativa para as despesas com a implementação de outros processos.
Há algumas coisas básicas que precisam ser levados em conta quando se

considera e decidiu Gerenciamento de Incidentes. Estes são tratados nesta
seção.
4.2.4.1 Prazos
Prazos deve ser aprovada para todas as fases de tratamento de incidente (estes
irão diferir dependendo da prioridade nível do incidente) - com base na resposta
global e incidente resolução alvos dentro de SLAs - e capturados como alvos
dentro Olas e Subjacente Contratos (UCs). Todos grupo de apoios deve ser
plenamente consciente destes prazos. As ferramentas de gerenciamento de
serviços devem ser usadas para automatizar prazos e aumentar o incidente
como necessário com base na regras pré-definidas.
4.2.4.2 Modelos de Incidentes

Muitos incidentes não são novos - eles envolvem lidar com algo que já
aconteceu antes e pode acontecer de novo. Por esta razão, muitas organizações
vai encontrá-lo útil para pré-definir Incident 'padrão' Modelos - e aplicá-los aos
incidentes adequadas quando eles ocorrem.
Um modelo de Incidentes é uma forma de pré-definir os passos que devem ser

tomadas para lidar com uma processo (Neste caso, um processo para tratar um
tipo particular de incidente) de uma forma acordado. Ferramentas de suporte
pode então ser utilizado para administrar o processo desejado. Isso irá garantir
que 'padrão' incidentes são tratados em um caminho pré-definido e dentro de
prazos pré-definidos.
Incidentes que requerem um tratamento especializado pode ser tratada desta

forma (por exemplo, segurançaIncidentes relacionados podem ser
encaminhadas para Gestão de Segurança da Informação e capacidade- Ou
atuaçãoIncidentes relacionados que seriam encaminhadas para Gerenciamento
da Capacidade.
O Modelo de Incidente deve incluir:
• Os passos que devem ser tomadas para lidar com o incidente

• A ordem cronológica estas etapas devem ser tomadas, com quaisquer
dependências ou co-processamento definidos
• Responsabilidades; quem deve fazer o que
• Prazos e limiars para a conclusão das ações
• Escalada procedimentos; que deve ser contactado e quando
• Qualquer necessárias evidências de preservação de atividades
(particularmente relevante para segurança- E capacidadeRelacionada
incidentes).
O modelos deve ser entrada para as ferramentas de manipulação de incidente

de suporte a ser utilizado e, em seguida, as ferramentas devem automatizar o
tratamento, gestão e escalada do processo.
4.2.4.3 grandes incidentes
Um separado procedimento, Com prazos mais curtos e maiores urgência, Deve

ser utilizado para 'principais' incidentes. A definição do que constitui um
incidente grave deve ser acordado e, idealmente, mapeado para a priorização
incidente geral sistema - De tal forma que eles serão tratados através do
incidente de grandes proporções processo.
Nota: As pessoas às vezes usam terminologia solta e / ou confundir um

incidente grave com uma problema. Na realidade, um incidente continua a ser
um incidente para sempre - pode crescer em impacto ou prioridade para se
tornar um grande incidente, mas um incidente nunca 'se torna' um problema. Um

problema é a causa subjacente de um ou mais incidentes e continua a ser uma
entidade separada sempre!
Alguns incidentes menor prioridade também pode ter de ser tratado por este
processo - devido ao impacto potencial - e algumas grandes incidentes pode não
precisar de ser tratada desta forma, se a causa e resoluçãos são óbvias e do
processo de incidente normal pode facilmente lidar dentro da meta acordada
resolução vezes - desde que o impacto é baixo!
Sempre que necessário, o procedimento de incidente grave deve incluir o

estabelecimento dinâmico de uma equipe grande incidente separado, sob a
liderança direta do Gerente de Incidentes, formulada para se concentrar sobre
este incidente só para garantir que adequada recursos e foco são fornecidos
para encontrar uma solução rápida. Se o Service Desk Gerente também é o
cumprimento da papel do Gerente de Incidentes (digamos em um pequeno
organização), Então uma pessoa separada pode precisar de ser designado para
liderar a equipa de investigação principal incidente -, de modo a evitar o conflito
de tempo ou prioridades - mas, em última análise deve informar o Gerente de
Incidentes.
Se a causa do incidente tem de ser investigada, ao mesmo tempo, então o

Gestor de Problemas estaria envolvido bem mas o Gestor de Incidentes deve
assegurar que serviço restauração e causa subjacente são mantidos separados.
Durante todo, o Service Desk seria garantir que todas as atividades são
registradas e usuários sejam plenamente informados do progresso.
4.2.5 As atividades de processo, métodos e técnicas
O processo a ser seguido durante a gestão de um incidente é mostrado na figura

4.2. O processo inclui as seguintes etapas.

Figura 4.2 Incidente de fluxo de processo de Gestão de
4.2.5.1 identificação de incidentes

Trabalho não pode começar a lidar com um incidente até que seja conhecido
que um incidente. É geralmente inaceitável, a partir de um perspectiva de
negócios, Esperar até que um usuário é impactado e os contatos do Service
Desk. Na medida do possível, todas as chaves componentes devem ser
monitoradas para que falhas ou potenciais falhas são detectadas cedo para que
a Gerenciamento de Incidentes processo pode ser iniciado rapidamente.
Idealmente, os incidentes devem ser resolvidos antes que eles tenham um
impacto sobre os usuários!
Por favor, consulte a secção 4.1 para mais detalhes.
4.2.5.2 registro de incidentes
Todos incidentes deve ser totalmente registradas e data / hora marcada,

independentemente de eles são criados através de um Service Desk telefone
chamar ou se detectada automaticamente através de um evento alertar.
Nota: Se o Service Desk e / ou pessoal de apoio visitar o clientes para lidar com
um incidente, eles podem ser convidados para lidar com novos incidentes ",
enquanto eles estão lá". É importante que, se isso for feito, uma separada Grave
incidente é registrado para cada incidente adicional tratado - para garantir que
uma histórica registro é mantido e crédito é dado para o trabalho realizado.
Toda a informação relevante sobre a natureza do incidente devem ser

registrados, de forma que um registro histórico completo é mantida - e de modo
que se o incidente tem de ser encaminhado para outro grupo de apoio(S), que
terá todas as informações relevantes para a mão para ajudá-los.
A informação necessária para cada incidente é provável que inclua:
• Número de referência único

• Categorização incidente (muitas vezes dividido em entre dois e quatro
níveis de sub-categorias)
• Incidente urgência
• Incidente impacto
• Priorização incidente
• Data / hora da gravação
• Nome / ID da pessoa e / ou grupo a gravação do incidente
• Método de notificação (telefone, automático, e-mail, pessoalmente, etc)
• Nome do departamento / / telefone / localização de usuário
• Call-back método (e-mail, telefone, etc)
• A descrição dos sintomas
• Incidente estado (Ativo, esperando, fechado, Etc)
• Relacionado CI
• Grupo de apoio / pessoa para a qual o incidente é alocado
• Relacionado problema/Erro Conhecido

• Atividades realizadas para resolver o incidente
• Resolução data e hora
• Fecho categoria
• Data e hora de encerramento.
Nota: Se o Service Desk não funcionar 24/7 e responsabilidade de primeira linha

incidente registro e manipulação de passes para outro grupo, como Operações
de TI ou suporte de rede, fora do horário de Service Desk, em seguida, estes
funcionários precisam estar igualmente rigorosa sobre o registro de detalhes do
incidente. Formação integral e consciência tem de ser fornecida para esse
pessoal sobre esta questão.
4.2.5.3 categorização de incidentes
Parte do registro inicial deve ser adequado para alocar incidente categorização
de codificação para que o tipo exato do chamar é gravada. Isto será importante
mais tarde quando se olha para tipos de incidentes / freqüências para
estabelecer tendências para o uso em Gerenciamento de Problemas,Gestão de
Fornecedores e outras atividades de ITSM.
Por favor, note que a seleção para Solicitação de Serviços neste processo não
implica que Solicitações de serviços são incidentes. Este é simplesmente o
reconhecimento do fato de que solicitações de serviço são, por vezes
incorretamente registrada como incidentes (por exemplo, um usuário
incorretamente entra o pedido como incidente a partir da interface web). Esta
verificação será detectar tais solicitações e garantir que eles são passados para
o Cumprimento de Requisição processo.
Multi-nível categorização está disponível na maioria das ferramentas -

geralmente a três ou quatro níveis de complexidade. Por exemplo, um incidente
podem ser categorizados como mostrado na Figura 4.3.

Figura 4.3 categorização incidente Multi-nível
Todas as organizações são únicos e, portanto, é difícil dar uma orientação

genérica sobre as categorias de organização Deve usar-se, em especial aos
níveis mais baixos. No entanto, não é uma técnica que pode ser usada para
ajudar a alcançar uma organização de um conjunto completo e correcto das
categorias - caso se parte do zero! Os passos envolvem:
1. Segure um de brainstorming sessão entre o relevante grupo de apoios,

envolvendo a Autoridade SD e gestores de incidentes e problemas.
2. Use esta sessão para decidir o "melhor palpite" categorias de nível
superior - e incluir um 'outro' categoria. Configurar as ferramentas
relevantes de registro para usar essas categorias por um período
experimental.
3. Use as categorias por um período experimental de curta duração (tempo
suficiente para que várias centenas de incidentes a cair em cada
categoria, mas não muito tempo que uma análise vai demorar muito
tempo para executar).
4. Faça uma análise dos incidentes registrados durante o período
experimental. O número de incidentes registrados em cada categoria de
nível superior irá confirmar se as categorias valem a pena - e uma análise

mais detalhada da categoria "outros" deve permitir a identificação de
quaisquer adicionais de nível superior categorias que serão necessários.
5. Uma análise de distribuição dos incidentes em cada categoria de nível
mais alto deve ser usado para determinar as categorias de nível inferior
que serão necessárias.
6. Comente e repetir estas actividades após um período adicional - de,
digamos, um a três meses - e novamente regularmente para garantir que
eles permaneçam relevantes. Esteja ciente de que quaisquer mudanças
significativas para categorização pode causar algumas dificuldades para
comunicação de incidentes de tendências ou de gestão - então eles
devem ser estabilizados, a menos que as mudanças são realmente
necessárias.
Se um esquema de categorização existente está em uso, mas não é pensado de

forma satisfatória, a idéia básica da técnica sugerida acima pode ser usado para
rever e alterar o regime existente.
NOTA: Às vezes, as informações disponíveis no momento de um incidente é

registrado pode ser incompleto, enganosas ou incorretas. Portanto, é importante
que a categorização do incidente é verificada e atualizada, se necessário, no
momento da chamada de encerramento (em separado fecho campo de
categorização, de forma a não danificar a categorização original) - consulte o
parágrafo 4.2.5.9.
4.2.5.4 priorização de Incidentes
Outro aspecto importante de registrar todos os incidente é concordar e alocar

um código de priorização apropriada - como isso vai determinar como o
incidente é tratado tanto por ferramentas de apoio e pessoal de apoio.
Priorização pode normalmente ser determinado tendo em conta tanto o urgência

do incidente (o quão rápido a empresa precisa de um resolução) E o nível de
impacto que está causando. Uma indicação do impacto é frequentemente (mas
não sempre) o número de usuárioestá sendo afetado. Em alguns casos, e muito
importante, a perda de serviço para um único usuário pode ter um impacto
grande negócio - tudo depende de quem está tentando fazer o que - para os
números por si só não é suficiente para avaliar global prioridade! Outros fatores
que também podem contribuir para os níveis de impacto são:
• Risco para a vida ou saúde

• O número de serviços afectados - pode ser de vários serviços
• O nível das perdas financeiras
• Efeito sobre reputação empresarial
• Brechas regulatórias ou legislativas.

Uma forma eficaz de cálculo destes elementos e derivando um nível de
prioridade geral para cada incidente é dado na Tabela 4.1:
Impacto
Alto Médio Baixo
Alto 1 2 3
Urgência Médio 2 3 4
Baixo 3 4 5
Código de prioridade Descrição Tempo de resolução alvo
1 Crítico 1 hora
2 Alto 8 horas
3 Médio 24 horas
4 Baixo 48 horas
5 Planejamento Planejado
Tabela 4.1 sistema de prioridades simples codificação
Em todos os casos, orientação clara - com exemplos práticos - deve ser

fornecida para todo o pessoal de apoio que lhes permitam determinar a urgência
correta e níveis de impacto, então a prioridade correta é alocado. Tais
orientações devem ser produzidos durante nível de serviço negociações.
No entanto, deve notar-se que haverá ocasiões em que, por causa da

oportunidade de negócio particular ou o que quer, os níveis de prioridade normal
tem que ser substituído. Quando um usuário está convencido de que o nível de
prioridade de um incidente deve exceder normais diretrizs, o Service Desk
devem cumprir tal pedido - e que, posteriormente passa a ser incorreta isso
pode ser resolvido como um problema de nível off-line de gestão, em vez de
uma disputa que ocorre quando o usuário está usando o telefone.
Algumas organizações podem também reconhecer VIPs (altos executivos,

funcionários, diplomatas, políticos, etc), cujos incidentes seriam tratados em um
maior prioridade do que o normal - mas, nesses casos, este é o melhor servidos
e documentado dentro do guidance fornecido ao Service Desk pessoal sobre
como aplicar os níveis de prioridade, por isso são todos conscientes das regras
acordadas para VIPs, e que cai nesta categoria.
Deve notar-se que um incidentePrioridade 's pode ser dinâmico - se as

circunstâncias mudarem, ou se um incidente não for resolvida dentro SLA vezes
alvo, em seguida, a prioridade deve ser alterado para refletir a nova situação.

Nota: algumas ferramentas podem ter restrições que dificultam automaticamente
para calcular atuação contra SLA alvos se uma prioridade é alterado durante o
tempo de vida de um incidente. No entanto, se as circunstâncias mudam, a
mudança de prioridade deve ser feito - e, se necessário ajustes manuais feitos
para ferramentas de relatórios. Idealmente, as ferramentas com tais restrições
não devem ser selecionados.
4.2.5.5 O diagnóstico inicial
Se o incidente foi encaminhado através do Service Desk, o Analista de Service

Desk deve realizar inicial diagnóstico, Tipicamente enquanto o usuário ainda
está no telefone - se o chamar é levantada desta maneira - para tentar descobrir
todos os sintomas do incidente e determinar exatamente o que deu errado e
como corrigi-lo. É nesta fase que script de diagnósticos e erro conhecido
informação pode ser mais valiosa do que permite o diagnóstico precoce e
preciso.
Se possível, o Analista de Service Desk vai resolver o incidente, enquanto o

usuário ainda está no telefone - e fechar o incidente se o resolução é bem
sucedida.
Se o Analista de Service Desk não pode resolver o incidente, enquanto o usuário

ainda está no telefone, mas há uma perspectiva de que o Service Desk pode ser
capaz de fazê-lo no prazo acordado sem a ajuda de outra grupo de apoios, o
analista deve informar o utilizador sobre as suas intenções, dar ao usuário o
número de referência incidente e tentar encontrar uma solução.
4.2.5.6 escalada de incidentes
• Escalada funcional. Tão logo torna-se claro que o Service Desk é incapaz
de resolver o incidente em si (ou quando os tempos alvo para primeiro-
ponto resolução foram ultrapassados -! Que ocorrer primeiro), o incidente
deve ser imediatamente encaminhado para um apoio adicional.
Se o organização tem um grupo de apoio de segundo nível e Service

Desk acredita que o incidente pode ser resolvido por esse grupo, deve
referir-se o incidente para eles. Se é óbvio que o incidente terá mais
profundo conhecimento técnico - ou quando o grupo de segundo nível,
não tem sido capaz de resolver o incidente dentro de vezes acordado (o
que ocorrer primeiro), o incidente deve ser imediatamente encaminhado
para o terceiro adequado nível apoiar grupo. Observe que os grupos de
terceiro nível de suporte podem ser internos - mas eles também podem
ser terceiros, tais como software fornecedors ou hardware fabricantes ou
mantenedores. As regras para a escalada e tratamento de incidentes
devem ser acordados na Olas e UCs com grupos de apoio interno e
externo, respectivamente.

Nota: Propriedade de Incidentes permanece com o Service Desk!
Independentemente de onde um incidente é referido durante a sua vida, a
propriedade do incidente permanece com o Service Desk em todos os
momentos. O Service Desk permanece responsável pelo controle do
progresso, mantendo os usuários informados e, finalmente, para a
Incidentes Fecho.
• Escalada hierárquica. Se os incidentes são de natureza grave (por

exemplo Prioridade 1 incidentes), os gerentes de TI apropriadas deve ser
notificado, para fins informativos, pelo menos. Escalada hierárquica
também é utilizado se a investigação "e Diagnóstico'E'Resolução e
Recuperação'Passos estão demorando muito ou provando muito difícil.
Hierárquica escalada devem continuar até a cadeia de gestão para que
os gerentes seniores estão conscientes e podem ser preparadas e tomar
as medidas necessárias, tais como alocação adicional recursos ou
envolvendo fornecedors / mantenedores. Escalada hierárquica também é
usado quando há disputa sobre a quem o incidente é alocado.
Escalada hierárquica pode, naturalmente, ser iniciada pelo afectada

usuários ou cliente gestão, como entenderem - é por isso que é
importante que os gerentes de TI estão cientes, para que possam prever
e preparar-se para qualquer escalada tal.
Os níveis exatos e prazos para escalonamento funcional e hierárquica precisa

ser aprovada, tendo em conta SLA alvos, e incorporados em ferramentas de
apoio, que podem então ser usados para polícia e controlar o fluxo do processo
dentro de prazos acordados.
O Service Desk deve manter o usuário informado de qualquer escalada

relevante que tem lugar e garantir a Grave incidente é atualizado de acordo para
manter uma história cheia de ações.
Nota sobre alocação de Incidentes
Pode haver muitos incidentes numa fila com o mesmo prioridade nível - por isso
vai ser o trabalho do Service Desk e / ou Gerenciamento de Incidentes pessoal
inicialmente, em conjunto com os gestores das diversas grupo de apoios para
que os incidentes são escalados, para decidir a ordem em que os incidentes
devem ser pego e trabalhado ativamente. Esses gerentes devem garantir que os
incidentes são tratados de modo verdadeiro negócio prioridade e que os
funcionários não estão autorizados a "cereja-pick 'dos incidentes que escolher!
4.2.5.7 Investigação e Diagnóstico
No caso de incidentes em que o usuário está apenas em busca de informações,

o Service Desk deve ser capaz de fornecer esta muito rapidamente e resolver a

solicitação de serviço - mas se um culpa está sendo relatado, este é um
incidente e é provável que requerem algum grau de investigação e diagnóstico.
Cada um dos grupos de apoio envolvidos com o tratamento de incidentes irá

investigar e diagnosticar o que está errado - e todas essas atividades (incluindo
detalhes de quaisquer medidas tomadas para tentar resolver ou recriar o
incidente) devem ser devidamente documentados no registro de incidente para
que um histórico completo registro de todas as actividades é mantida em todos
os momentos.
Nota: O tempo valioso muitas vezes pode ser perdido se investigação e acção
de diagnóstico (ou mesmo resolução ou recuperação ações) são executadas em
série. Sempre que possível, essas atividades devem ser realizadas em paralelo
para reduzir prazos gerais - e ferramentas de apoio devem ser concebidos e / ou
selecionados para permitir isso. No entanto, cuidados devem ser tomados para
coordenar as atividades, atividades especialmente de resolução ou de
recuperação, caso contrário, as ações de diferentes grupos podem entrar em
conflito ou complicar ainda mais a resolução!
Esta investigação é provável que incluem ações como:
• Estabelecer exatamente o que deu errado ou sendo procurado pelo

usuário
• Compreender a ordem cronológica de eventos
• Confirmando o pleno impacto do incidente, incluindo o número e
variedade de usuários afetados
• Identificar quaisquer eventos que possam ter provocado o incidente (por
exemplo, uma recente mudar, Alguma ação do usuário?)
• Buscas conhecimento procurando ocorrências anteriores por pesquisar
anterior Incidente/Grave problemas e / ou Banco de Dados de erro
conhecidos ou fabricantes '/fornecedors 'logs de erros ou bancos de
dados de Conhecimento.
4.2.5.8 Resolução e Recuperação
Quando um potencial resolução foi identificado, este deve ser aplicado e

testado. As ações específicas a serem realizadas e as pessoas que serão
envolvidas na tomada de recuperação acções podem variar, dependendo da
natureza do culpa - Mas pode envolver:
• Pedindo o usuário para realizar atividades direcionadas em seu topo

própria mesa ou o equipamento remoto
• O Service Desk implementar a resolução ou centralmente (por exemplo,
reiniciar um servidor) Ou remotamente usando o software para assumir o
controle do computador do usuário para diagnosticar e implementar uma
resolução

• Especialista grupo de apoioestá sendo solicitado a implementar ações de
recuperação específicas (por exemplo suporte de rede reconfigurar um
roteador)
• Um fornecedor de terceiros ou mantenedor sendo solicitados a resolver a
falha.
Mesmo quando uma resolução foi encontrado, testes suficientes devem ser
realizados para garantir que a ação de recuperação é completa e que a serviço
foi totalmente restaurard para o utilizador (es).
NOTA: em alguns casos, pode ser necessário que dois ou mais grupos de tomar
separadas, embora talvez coordenadas as acções de recuperação, para uma
resolução global a ser implementado. Em tais casos, Gestão de Incidentes deve
coordenar as actividades e estabelecer contactos com todas as partes
envolvidas.
Independentemente das medidas tomadas, ou que faz deles, o Grave incidente

deve ser atualizado de acordo com todas as informações e detalhes para que
uma história cheia é mantido.
O grupo deve passar resolver o incidente de volta para o Service Desk para
fecho ação.
4.2.5.9 Fechamento de Incidentes
O Service Desk deve verificar se o incidente está totalmente resolvido e que os

usuários estão satisfeitos e dispostos a aceitar o incidente pode ser fechado. O
Service Desk também deve verificar o seguinte:
• Categorização encerramento. Verificar e confirmar que a categorização

incidente inicial foi correta ou, onde a categorização posteriormente
acabou por ser incorreta, atualizar o registro para que uma categorização
fechamento correto é registrada para o incidente - que procuram
aconselhar ou orientação do grupo de Resolução (s), se necessário.
• Pesquisa de satisfação do usuário. Realizar uma pesquisa de
satisfação do usuário de call-back ou e-mail para o percentual acordado
de incidentes.
• Documentação do incidente. Perseguir todos os detalhes pendentes e
garantir que o registro de incidentes é totalmente documentado para que
um registro completo histórico em um nível suficiente de detalhe é
completa.
• Em curso ou recorrentes problema? Determinar (em conjunto com os
grupos resolvedor) se é provável que o incidente poderia ocorrer e decidir
se qualquer acção preventiva é necessária para evitar isto. Em conjunto
com a Gerenciamento de Problemas, Levantar um registro de problema
em todos esses casos para que a ação preventiva é iniciada.

• Formal fecho. Encerrar formalmente o Grave incidente.
Nota: Algumas organizações podem optar por utilizar um período de fechamento

automático em específico, ou mesmo todos, incidentes (por exemplo incidente
será automaticamente fechado depois de dois dias úteis se mais contato é feito
pela usuário). Onde esta abordagem deve ser considerado, ele deve primeiro
ser totalmente discutido e acordado com os usuários - e amplamente divulgado
para que todos os usuários e equipe de TI estão cientes disso. Pode ser
inapropriado para usar este método para certos tipos de incidentes - como
incidente graves ou aqueles que envolvem VIPs, etc
Regras para reabertura incidentes
Apesar de todo o cuidado adequado, haverá ocasiões em que incidentes se

repetir, apesar de terem sido formalmente fechado. Por causa de tais casos, é
aconselhável ter regras pré-definidas sobre se e quando um incidente pode ser
reaberto. Pode fazer sentido, por exemplo, a concordar que, se persistir o
incidente no prazo de um dia útil, então ele pode ser reaberto -, mas que para
além deste ponto um novo incidente deve ser levantada, mas ligado ao incidente
anterior (s).
O tempo exato limiar/ Regras podem variar entre organizações individuais - mas
regras claras devem ser acordados e documentados e orientação dada a todos
Service Desk pessoal, de modo que a uniformidade é aplicada.
Incidentes pode ser acionado de diversas maneiras. A rota mais comum é

quando um usuário toca o Posto de Serviço ou completa um web-based tela
incidente registro, mas cada vez mais incidentes são criados automaticamente
através Gestão de Eventos ferramentas. A equipe técnica pode notar potencial
falhas e levantar um incidente, ou pedir o Service Desk para o fazer, de modo
que a culpa podem ser abordados. Alguns incidentes podem também surgir no
início do fornecedors - que pode enviar alguma forma de notificação de uma
dificuldade potencial ou real que precisa de atenção.
As interfaces com Gerenciamento de Incidentes incluem:
• Gerenciamento de Problemas: Gerenciamento de Incidentes faz parte do

total processo de tratar problemas no organização. Os incidentes são
muitas vezes causados por problemas subjacentes, que devem ser
resolvidos para evitar que o incidente se repita. Gerenciamento de
Incidentes fornece um ponto onde estes são relatados.
• Gerenciamento da Configuração fornece os dados utilizados para
identificar e progredir incidentes. Uma das utilizações da CMS é identificar
equipamento defeituoso e para avaliar a impacto de um incidente. É

também usado para identificar os utilizadores afectados por problemas
potenciais. O CMS também contém informações sobre as categorias de
incidente deve ser atribuído a que grupo de apoio. Por sua vez,
Gerenciamento de Incidentes pode manter a estado de CIs com defeito.
Ele também pode ajudar Gerenciamento de Configuração para auditar a
infra-estrutura quando se trabalha para resolver um incidente.
• Gestão da Mudança: Sempre que um mudar é necessário para
implementar um solução alternativa ou resolução, este terá que ser
registrada como um RFC e progrediu através do Gerenciamento de
Mudança. Por sua vez, Gerenciamento de Incidentes é capaz de detectar
e resolver os incidentes que surgem de mudanças fracassadas.
• Gerenciamento da Capacidade: Gerenciamento de Incidentes fornece um
gatilho para atuação monitoramento onde parece haver uma atuação
problema. Gerenciamento da Capacidade pode desenvolver soluções
para incidentes.
• Gerenciamento de Disponibilidade; usará dados Gerenciamento de
Incidentes para determinar a disponibilidade de De serviços de TIs e olhar
para onde o incidente ciclo de vida pode ser melhorada.
• SLM: A capacidade de resolver os incidentes em uma hora especificada é
uma parte fundamental de entregar um nível acordado de serviço.
Gerenciamento de Incidentes permite SLM para definir respostas
mensuráveis para as interrupções de serviço. Ele também fornece
relatórios que permitem a SLM rever SLAs objetivamente e regularmente.
Em particular, Gerenciamento de Incidentes é capaz de ajudar a definir
onde os serviços estão em seu ponto mais baixo, de modo que SLM pode
definir ações como parte da Melhoria de Serviço Programa (SIP) -
consulte o Melhoria de Serviço Continuada publicação para mais
detalhes. SLM define os níveis aceitáveis de serviço em que obras de
gerenciamento de incidentes, incluindo:
• Incidente tempo de respostas
• Impacto definições
• Alvo vezes fix
• Definições de serviço, que são mapeados para usuários
• Regras para serviços requerentes
• Expectativas para fornecer feedback para usuários.
A maioria das informações utilizadas no Gerenciamento de Incidentes vem das

seguintes fontes:
• As ferramentas de gerenciamento de incidentes, Que contêm

informações sobre:
• Incidente e problema história
• Categorias de incidentes
• Medidas tomadas para resolver os incidentes

• Script de diagnósticos, que pode ajudar os analistas de primeira
linha para resolver o incidente, ou pelo menos reunir informações
que irão ajudar os analistas de segunda ou terceira linha resolvê-lo
mais rápido.
• Grave incidentes, Que incluem os seguintes dados:
• Número de referência único
• Incidente classificação
• Data e hora da gravação e quaisquer atividades subseqüentes
• Nome e identidade da pessoa gravar e atualizar o registro de
incidentes
• Nome /organização/ Detalhes de contato do usuário afetado (s)
• Descrição dos sintomas de incidentes
• Detalhes de quaisquer medidas tomadas para tentar diagnosticar,
solucionar ou recriar o incidente
• Incidente categoria,impacto,urgência e prioridade
• Relação com outros incidentes, problemas, alterações ou Erro
Conhecidos
• Fecho detalhes, incluindo o tempo, categoria, As medidas tomadas
e identidade de pessoa fechando a registro.
Gerenciamento de Incidentes também exige o acesso ao CMS. Isso irá ajudá-lo

a identificar os CIs afetados pelo incidente e também para estimar o impacto do
incidente.
O Banco de Dados de erro conhecido fornece informações valiosas sobre

possível resoluçãos e solução alternativas. Isso é discutido em detalhes no
parágrafo 4.4.7.2.
4.2.8 Métricas
O métricos que devem ser monitorados e reportados para julgar o eficiência e

eficácia do Gerenciamento de Incidentes processo, Ea sua operação, Irão
incluir:
• Número total de incidentes (como um controlar medida)

• Distribuição dos incidentes em cada fase (por exemplo, registrado,
trabalho em andamento,fechado etc)
• Tamanho do backlog de incidentes atual
• Número e percentual de incidente graves
• O tempo médio para conseguir a resolução de incidentes ou evasão,
discriminadas por código de impacto
• Percentual de incidentes tratados dentro concordaram tempo de resposta
(Incidentes de tempo de resposta alvos podem ser especificados nos
SLAs, por exemplo, por impacto e urgência códigos)
• Média custar por incidente
• Número de incidentes reabertas e como uma percentagem do total

• Número e percentual de incidentes atribuídos incorretamente
• Número e percentual de incidentes classificados incorretamente
• Percentual de Incidentes fechada pelo Service Desk sem referência a
outros níveis de apoio (muitas vezes referido como "o primeiro ponto de
contato")
• Número e porcentagem de incidentes processados por agente Service
Desk
• Número e percentagem de casos resolvidos remotamente, sem a
necessidade de uma visita
• Número de incidentes tratados por cada incidente Modelo
• Distribuição dos incidentes por hora do dia, para ajudar a identificar e
garantir picos de correspondência recursos.
Os relatórios devem ser produzidos sob a autoridade do Gerente de Incidentes,

que deverá elaborar um calendário e lista de distribuição, em colaboração com o
Service Desk e grupo de apoiomanipulação de incidentes s. As listas de
distribuição deve incluir pelo menos De serviços de TIs Gestão e especialista
grupo de apoios. Considere também tornando os dados disponíveis para
usuários e clientes, por exemplo, através de relatórios de SLA.
4.2.9.1 Desafios
Os seguintes desafios irão existir para o sucesso Gerenciamento de Incidentes:
• A capacidade de detectar incidentes tão cedo quanto possível. Isso

exigirá educação da usuárioincidentes s relatórios, o uso de Super Users
(ver parágrafo 6.2.4.5) e do configuração de Gestão de Eventos
ferramentas.
• Convencer todo o pessoal (equipes técnicas, bem como usuários) que
todos os incidentes devem ser registrados, e incentivar o uso de auto-
ajuda baseado na web capacidades (que pode acelerar a assistência e
reduzir recursos exigências).
• Disponibilidade de informações sobre problemas e Erro Conhecidos. Isso
vai permitir que a equipe de Gerenciamento de Incidentes de aprender
com incidentes anteriores e também para acompanhar o estado de
resoluçãos.
• Integração no CMS para determinar relaçãos entre IC e para se referir à
história de CIs ao realizar suporte de primeira linha.
• Integração na SLM processo. Isso vai ajudar Gerenciamento de
Incidentes corretamente para avaliar a impacto e prioridade de incidentes
e auxilia na definição e execução escalada procedimentos. SLM também
serão beneficiados com as informações aprendidas durante o
Gerenciamento de Incidentes, por exemplo, para determinar se nível de
serviço atuação metas são realistas e realizáveis.

Os seguintes fatores serão fundamentais para a Gestão de Incidentes de

sucesso:
• Um bom Service Desk é a chave para o Gerenciamento de Incidentes de

sucesso
• Objectivos claramente definidos que trabalhar para - conforme definido no
SLA
• Adequado clienteOrientada para o pessoal de apoio e tecnicamente
treinamento com os níveis de habilidade corretos, em todas as fases do
processo de
• Ferramentas de apoio integrados de conduzir e controlar o processo de
• Olas e UCs que são capazes de influenciar e moldar o comportamento
correto de todo o pessoal de apoio.
4.2.9.3 Riscos
O riscos para Gestão de Incidentes de sucesso são realmente semelhantes a

alguns dos desafios e no verso de alguns dos Fator Crítico de Sucessos
mencionados acima. Eles incluem:
• Sendo inundados com incidentes que não podem ser tratados dentro de
prazos aceitáveis devido à falta de disposição ou devidamente treinados
recursos
• Incidentes atolando e não progrediu como pretendido, porque de
ferramentas de suporte inadequados para levantar alertars e progresso
pronta
• Falta de fontes de informação adequados e / ou oportuna porque de
ferramentas inadequadas ou falta de integração
• Descasamentos de objetivos ou ações por causa de OLAs mal alinhados
ou não-existente e / ou UCs.

4,3 Cumprimento de Requisição
O termo "Solicitação de Serviço'É utilizado como uma designação genérica para
muitos tipos diferentes de exigências que são colocadas em cima do
Departamento de TI pela usuários. Muitos deles são realmente pequenas
mudanças - baixo risco, Que ocorrem com frequência, baixo custar, Etc (por
exemplo, um pedido para alterar uma senha, um pedido para instalar um
software adicional aplicação em uma estação de trabalho especial, um pedido
para mudar alguns itens de equipamentos de mesa) ou talvez apenas uma
questão solicitando informações -, mas a sua escala e freqüentes, de baixo risco
natureza significa que eles são melhor tratadas em separado por uma processo,
Em vez de serem autorizados a congestionar e obstruir o incidente normal e
Gestão da Mudança processos.
Finalidade 4.3.1 meta / / objetivo
Cumprimento de Requisição é o processo de lidar com solicitações de serviço

dos usuários. O objetivos do processo de Cumprimento de Requisição incluem:
• Para fornecer um canal para que os usuários solicitar e receber serviços

de padrão para que uma aprovação pré-definida e qualificação processo
existe
• Para fornecer informações aos usuários e clientes sobre o disponibilidade
de serviços e os procedimento para a obtenção
• Para fonte e entregar o componentes de pedidos padrão de serviços (por
exemplo, licenças de software e mídia)
• Para ajudar com informações gerais, reclamações ou comentários.
4.3.2 Âmbito
O processo necessário para satisfazer um pedido variará dependendo

exactamente o que está a ser pedido - mas pode ser geralmente dividido em um
conjunto de actividades que têm de ser executadas. Algumas organizações vai
ser confortável para que as solicitações de serviço ser tratado por meio de sua
Gerenciamento de Incidentes processos (e ferramentas) - com solicitações de
serviço que está sendo tratado como um tipo particular de 'incidente'(Utilizando
uma classificação de alto nível sistema identificar os "incidentes" que estão em
Solicitações de Serviço fato).
Notar, contudo, que há uma diferença significativa aqui - um incidente é

geralmente uma imprevista evento enquanto que uma solicitação de serviço
geralmente é algo que pode e deve ser planejado!
Portanto, numa organização onde um grande número de solicitações de serviço

têm que ser tratados e onde as ações a serem tomadas para o cumprimento
desses pedidos são muito variados ou especializados, pode ser apropriado para

lidar com solicitações de serviço como um fluxo de trabalho totalmente separada
- e para gravar e gerenciá-los como um separado registro tipo.
Isto pode ser particularmente apropriado se a organização optou por alargar o

escopo do Service Desk para expandir apenas relacionados a TI questões e
usar a mesa como um ponto focal para outros tipos ou solicitação de serviço -
por exemplo, um pedido para atender a uma copiadora ou mesmo indo tão longe
a ponto de incluir, por exemplo, a construção de questões de gestão, tais como
a necessidade de substituir uma montagem de luz ou reparar um vazamento no
encanamento.
Nota: em última análise, caberá a cada organização decidir e documentar o que

ele vai lidar com pedido através do processo de Cumprimento de Requisição e
que outros terão que passar por Change Management mais formal. Sempre
haverá áreas cinzentas que impedem a orientação genérica de ser útil prescrito.
O valor de Cumprimento de Requisição é fornecer acesso rápido e eficaz aos

serviços padrão que funcionários da empresa pode usar para melhorar sua
produtividade ou a qualidade de serviço de negócios e produtos.
Cumprimento de Requisição efetivamente reduz a burocracia na solicitação e

recebimento de acesso a serviços novos ou já existentes, reduzindo assim o
custar da prestação destes serviços. Centralizando cumprimento também
aumenta o nível de controlar sobre esses serviços. Este por sua vez, pode
ajudar a reduzir custos através da negociação centralizada com fornecedors, e
pode também ajudar a reduzir o custo do suporte.
Muitos Solicitação de Serviços será frequentemente recorrente, portanto, um

pré-definido processo fluxo (a modelo) Pode ser concebido de modo a incluir as
etapas necessárias para cumprir o pedido, a pessoas físicas ou grupo de apoios
envolvidos prazos, alvo e escalada caminhos. Solicitações de serviços
geralmente ser satisfeitas através da implementação de um Mudança Padrão
(Veja a Transição de Serviço publicação para obter mais detalhes sobre
Alterações padrão). A posse de solicitações de serviço reside com o Service
Desk, Que monitora, escalada, expedições e muitas vezes cumpre a usuário
pedido.
4.3.4.1 Modelos Pedido
Algumas solicitações de serviço irá ocorrer com freqüência e vai exigir lidar de
uma forma consistente, a fim de atender concordou nível de serviços. Para
apoiar este, muitas organizações desejam criar modelos pré-definidos pedido

(que normalmente incluem algum tipo de pré-aprovação por Gestão da
Mudança). Isto é similar em conceito à idéia de Modelos de Incidentes já
descritos no parágrafo 4.2.4.2, mas aplicada a solicitações de serviço.
4.3.5.1 seleção do menu
Cumprimento de Requisição oferece grandes oportunidades de auto-ajuda

práticas, onde os usuários podem gerar uma solicitação de serviço usando a
tecnologia que links em Serviço de Gestão de ferramentas. Idealmente, os
usuários devem ser oferecido um 'seleção menu' tipo através de uma interface
web, para que eles possam escolher e detalhes de entrada de solicitações de
serviço a partir de uma lista pré-definidas, onde as expectativas apropriadas
pode ser definido, dando entrega de destino e / ou implementação metas / datas
(em linha com as metas de SLA). Onde as organizações estão oferecendo uma
auto-ajuda de suporte de TI capacidade para os usuários, não faria sentido para
combinar isso com um Cumprimento de Requisição sistema como descrito.
Ferramentas especializadas web para oferecer este tipo de experiência "carrinho

de compras" pode ser utilizado em conjunto com interfaces diretamente para o
back-end ferramentas integradas de ITSM, ou outra mais geral processo de
negócio automação ou Enterprise Resource Planning (ERP), ferramentas que
podem ser utilizadas para o gerenciamento das atividades de Cumprimento de
Requisição.
4.3.5.2 aprovação Financeiro
Um importante passo extra que é provável que seja necessário quando se lida
com um solicitação de serviço é a de aprovação financeira.
A maioria das solicitações terão alguma forma de implicações financeiras,

independentemente do tipo de acordos comerciais no local. O custo de cumprir o
pedido deve primeiro ser estabelecida. Pode ser possível concordar preços fixos
para "padrão" - e pedidos de aprovação prévia para tais pedidos pode ser dado
como parte do organização'S anual global gestão financeira. Em todos os outros
casos, uma estimativa do custo deve ser produzido e apresentado ao usuário
para aprovação financeira (o usuário pode precisar de procurar aprovação a sua
gestão / cadeia financeira). Se a aprovação for dada, além de cumprir o pedido,
a processo Deve também incluir carregamento (Faturamento ou a tarifação) para
o trabalho feito - se a carga está no local.
4.3.5.3 aprovação Outros
Em alguns casos a autorização adicional pode ser necessária - como

relacionados à conformidade ou aprovação mais ampla de negócios.

Cumprimento de Requisição deve ter a capacidade de definir e verificar essas
aprovações, quando necessário.
4.3.5.4 Cumprimento
O real cumprimento atividade irá depender da natureza do Solicitação de

Serviço. Alguns pedidos mais simples pode ser preenchido pelo Service Desk,
Atuando como suporte de primeira linha, Enquanto outros terão de ser
encaminhados para grupos de especialistas e / ou fornecedors para o
cumprimento.
Algumas organizações podem ter grupos especializados de atendimento (para

'pegar, embalar e despachar ") - ou pode ter alguns terceirizados de atendimento
atividades para um fornecedor de terceiros (s). O Service Desk deve monitorar e
perseguir o progresso e manter usuários informado durante todo,
independentemente da fonte de realização real.
4.3.5.5 Encerramento
Quando a solicitação de serviço foi cumprido deve ser remetido ao Service Desk
para fecho. O Service Desk devem passar pelo processo de encerramento
mesmo como descrito anteriormente no ponto 4.2.5.9 - verificar se o usuário
está satisfeito com o resultado.
A maioria dos pedidos será acionado, quer através de um usuário chamando o

Service Desk ou um usuário de completar alguma forma de auto-ajuda baseado
na web tela de entrada para fazer seu pedido. Este último, muitas vezes,
envolvem uma seleção de uma carteira de pedidos disponíveis types.The
interfaces primárias com Cumprimento de Requisição incluem:
• Service Desk /Gerenciamento de Incidentes: Solicitações de serviços

pode vir em muitos através do Service Desk e pode ser inicialmente
tratado através do processo de Gerenciamento de Incidentes. Algumas
organizações podem escolher que todos os pedidos são tratados por esta
via - mas outros podem optar por ter um processo separado, por razões já
discutidas anteriormente neste capítulo.
• A forte ligação também é necessário entre Cumprimento de Requisição,
Solte, Ativos e Gerenciamento da Configuração - Como alguns pedidos
será para o desenvolvimento de novo ou atualizado componentes que
pode ser implantado automaticamente. Em tais casos, a "libertação" pode
ser pré-definido, construído e testado, mas só implantada a pedido por
aqueles que querem a "libertação". Após a implantação, o CMS terá que
ser atualizado para refletir a mudar. Se for o caso, os cheques de licença
de software / atualizações também será necessário.

Se for caso disso, será necessário relacionar Pedidos relacionados a TI de
serviço para qualquer incidentes ou problemas que iniciaram a necessidade para
o pedido (como seria o caso em qualquer outro tipo de modificação).
Cumprimento de Requisição depende das informações das seguintes fontes:
• As solicitações de serviço conterá informações sobre:

• O que serviço está sendo solicitado
• Que tenha solicitado e autorizado o serviço
• Que processo será usada para executar o pedido
• A quem foi atribuído e que medidas foram tomadas
• A data ea hora em que o pedido foi registrado, bem como a data e
hora de todas as ações tomadas
• Detalhes encerramento.
• Pedidos de Alteração: Em alguns casos, a Cumprimento de Requisição
processo será iniciado por um RFC. Isto é típico em que o Solicitação de
Serviço refere-se a um IC
• O Portfólio de Serviços, Para permitir que o escopo de solicitação de
serviço concordou em ser identificado
• Políticas de Segurança irá prescrever qualquer controle a ser executado
ou cumprido aquando da prestação do serviço, por exemplo garantia de
que o solicitante está autorizado a acessar o serviço, ou que o software
está licenciado.
4.3.8 Métricas
O métricos necessária para julgar a eficácia e eficiência de Cumprimento de

Requisição irá incluir o seguinte (cada métrica precisa ser discriminadas por tipo
de pedido, dentro do prazo):
• O número total de solicitações de serviço (como um controlar medida)

• Composição da solicitação de serviços, em cada fase (e.g. logged WIP,
fechado, Etc)
• O tamanho da carteira atual de pedidos de serviço pendentes
• A média de tempo para lidar com cada tipo de solicitação de serviço
• O número ea porcentagem de solicitações de serviço concluído dentro de
vezes alvo acordados
• A média custar por tipo de solicitação de serviço
• Nível de cliente satisfação com o tratamento de solicitações de serviço
(medido em alguma forma de pesquisa de satisfação).
4.3.9.1 Desafios

Os seguintes desafios serão enfrentados ao introduzir Cumprimento de
Requisição:
• Claramente definir e documentar o tipo de solicitações que serão tratadas

no processo de Cumprimento de Requisição (e aqueles que quer passar
pelo Service Desk e ser tratado como um incidente ou aqueles que
precisam passar por formais Gestão da Mudança) - Para que todos os
partidos são absolutamente clara sobre o alcance.
• Estabelecimento de auto-ajuda de front-end capacidades que permitem a
usuários para interagir com sucesso com o Cumprimento de Requisição
processo.
A realização de pedido depende do seguinte Fator Crítico de Sucessos:
• Acordo de que os serviços serão normalizados e que está autorizado a

solicitá-los. O custar destes serviços também deve ser acordado. Isto
pode ser feito como parte do processo de SLM. Qualquer variaçãos dos
serviços também deve ser definido.
• Publicação dos serviços aos usuários, como parte do Catálogo de
Serviços. É importante que essa parte do Catálogo de Serviços deve ser
facilmente acessados, talvez na Intranet, e deve ser reconhecida como a
primeira fonte de informação para os usuários que buscam acesso a um
serviço.
• Definição de um padrão cumprimento procedimento para cada um dos
serviços a ser solicitados. Isto inclui todas as políticas de aquisição e
capacidade de gerar ordens de compra e ordens de serviço
• Aúnico ponto de contato que pode ser usado para solicitar o serviço. Isso
é muitas vezes fornecido pelo Service Desk ou por meio de um pedido de
intranet, mas pode ser por meio de um pedido automatizado directamente
para o cumprimento de solicitação ou aquisição sistema.
• De auto-atendimento ferramentas necessárias para fornecer uma
interface de front-end para os usuários. É essencial que estes integração
com as ferramentas de back-end de atendimento, muitas vezes geridos
através de Incidente ou Gestão da Mudança.
4.3.9.3 Riscos
Riscos que podem ser encontrados com Cumprimento de Requisição incluem:
• Mal definidas escopo, Onde as pessoas não são claras sobre o que
exatamente o processo é esperado para lidar com
• Interfaces de usuário mal projetadas ou implementadas para que os
usuários têm dificuldade em obter os pedidos que eles precisam

• Mal projetados ou operados de back-end processos de atendimento, que
são incapazes de lidar com o volume ou a natureza dos pedidos que
estão sendo feitos
• Inadequado monitoramento de modo que as capacidades exactas
métricos não podem ser recolhidas.

4,4 Gerenciamento de Problemas
ITIL define um "problema'Como a causa de um ou mais incidentes.
Gerenciamento de Problemas é o processo responsável pela gestão do ciclo de

vida de todos os problemas. O primário objetivos de Gerenciamento de
Problemas são para evitar problemas e incidentes resultantes de acontecer,
para eliminar incidentes recorrentes e minimizar o impacto de incidentes que não
podem ser evitados.
4.4.2 Âmbito
Gerenciamento de Problemas inclui as atividades necessárias para diagnosticar

o causa raiz de incidentes e determinar o resolução para aqueles problemas.
Também é responsável por assegurar que a resolução é implementado através
da adequada controlar procedimentos, especialmente Gestão da Mudança e
Gerenciamento de Liberação.
Gerenciamento de Problemas também vai manter as informações sobre os

problemas e apropriado solução alternativas e resoluções, de modo que os
organização é capaz de reduzir o número e impacto de incidentes ao longo do
tempo. A este respeito, Gestão de Problemas tem uma interface com forte
Gestão do Conhecimento, E ferramentas como o Banco de Dados de erro
conhecido serão utilizados para ambos.
Apesar de Incidentes e Gestão de Problemas são processos separados, eles

estão intimamente relacionados e geralmente usam as mesmas ferramentas, e
podem usar categorização semelhante, impacto e prioridade codificação
sistemas. Isto irá assegurar a comunicação eficaz ao lidar com incidentes e
problemas relacionados.
Gerenciamento de Problemas trabalha em conjunto com Gerenciamento de

Incidentes e Gestão da Mudança para garantir que De serviços de TI
disponibilidade e qualidade são aumentados. Quando os incidentes são
resolvidos, informações sobre a resolução é gravado. Com o tempo, esta
informação é utilizada para acelerar o tempo de resolução e identificar soluções
permanentes, reduzindo o número eo tempo de resolução de incidentes. Isto
resulta em menos tempo de inatividade e menos interrupções dos sistemas
críticos de negócio.
Valor adicional é derivado a partir do seguinte:

• Maior disponibilidade de serviços de TI
• Maior produtividade do negócio ea equipe de TI
• Redução das despesas em soluções ou correções que não funcionam
• Redução em custar esforço em combate a incêndios ou resolver
incidentes repetidos.
Existem alguns conceitos importantes de Gerenciamento de Problemas que

devem ser levados em conta desde o início. Estes incluem:
4.4.4.1 Modelos de problemas
Muitos problemas será única e vai exigir gerir de forma individual -, mas é
possível que alguns incidentes possam ocorrer por causa de problemas
dormentes ou subjacente (por exemplo, onde o custo de uma resolução
permanente será elevada e uma decisão foi tomada não ir em frente com uma
solução cara - mas para "viver com o problema).
Bem como a criação de um Grave erro conhecido no banco de dados de erros

conhecidos (ver parágrafo 4.4.5.7) para garantir mais rápido diagnóstico, A
criação de um Problema Modelo para lidar com esses problemas no futuro pode
ser útil. Isto é muito similar em conceito à idéia de Modelos de incidentes já
descritos no parágrafo 4.2.4.2, mas aplicada a problemas, bem como incidentes.
Gestão problema consiste em dois processos principais:
• Reativo Gerenciamento de Problemas, O qual é geralmente executado

como parte da operação de serviço - e é, portanto, abrangidos nesta
publicação
• Gerenciamento de Problemas pró-ativa que é iniciada em Operação de
Serviço, Mas geralmente conduzido como parte da Melhoria de Serviço
Continuada.
O Gerenciamento de Problemas reativa processo é mostrada na Figura 4.4. Este

é um gráfico simplificada para mostrar o fluxo de processo normal, mas na
realidade, alguns estados pode ser iterativo ou variações podem ter que ser
feitas, a fim de lidar com situações particulares.

Figura 4.4 problema de fluxo de processo de Gestão de
4.4.5.1 detecção de problemas
É provável que as múltiplas formas de detectar problemas vai existir em todas as

organizações. Estas incluem:

• Suspeita ou detecção de uma causa de um ou mais incidentes pela
central de serviços, o que resulta numa Grave problema sendo
levantadas - a mesa pode ter resolvido o incidente mas não determinou
uma causa definitiva e suspeita que é provável que volte a ocorrer, então
vai levantar um registro de problema para permitir que a causa subjacente
para ser resolvido. Alternativamente, pode ser imediatamente óbvio desde
o início que um incidente, ou incidentes, foi causado por um problema
importante, portanto, um registro de problema será levantado sem
demora.
• Análise de um incidente por um técnico grupo de apoio o que revela que
existe um problema subjacente, ou seja susceptível de existir.
• Detecção automática de uma infra-estrutura ou aplicação culpa, Usando
evento/alertar ferramentas automaticamente para levantar um incidente
que pode revelar a necessidade de um registro de problema.
• A notificação de um fornecedor ou contratante que existe um problema
que tem de ser resolvido.
• Análise de incidentes como parte de Gerenciamento de Problemas pró-
ativa - Resultando na necessidade de levantar um registro de problema,
de modo que a falha subjacente pode ser investigada.
Análise frequente e regular de dados de incidentes e problemas devem ser

realizados para identificar as tendências que se tornam perceptíveis. Isso vai
exigir categorização significativo e detalhado de incidentes / problemas e
apresentação de relatórios regulares de padrões e áreas de grande ocorrência.
'Top 10' de relatórios, com drill-down capacidades para níveis mais baixos, é útil
na identificação de tendências.
Mais detalhes de como detectado tendências devem ser manipulados são

incluídos na publicação Melhoria de Serviço Continuada.
4.4.5.2 registro Problema
Independentemente do detecção método, todos os detalhes relevantes do

problema devem ser registrados para que um histórico completo registro existe.
Esta deve ser a data ea hora estampadas para permitir adequada controlar e
escalada.
Uma referência cruzada deve ser feito para o incidente (s) que iniciou o registro
de problema - e todos os detalhes relevantes devem ser copiados do Grave
incidente(S) para o registro de problema. É difícil ser exato, como casos podem
variar, mas geralmente isso irá incluir detalhes, tais como:
• Usuário detalhes
• Detalhes do serviço
• Detalhes do equipamento
• Data / hora inicialmente logado

• Prioridade e detalhes de categorização
• Descrição incidente
• Detalhes de todos diagnóstico ou tentativa de recuperação ações
tomadas.
4.4.5.3 Categorização Problema
Os problemas devem ser classificados na mesma maneira como incidentes (e é

aconselhável utilizar os mesmos códigos sistema) De modo que a verdadeira
natureza da problema pode ser facilmente rastreada no futuro e significativa
gestão da informação podem ser obtidos.
4.4.5.4 Priorização de Problemas
Os problemas devem ser priorizados na mesma forma e pelas mesmas razões

como incidentes - mas a frequência e impacto de incidentes relacionados
também devem ser levados em conta. A codificação sistema descrita
anteriormente na Tabela 4.1 (que combina com impacto urgência para dar um
nível de prioridade global) pode ser usado para dar prioridade problemas da
mesma forma que ele pode ser utilizado em caso de incidentes, embora as
definições e orientação para suportar pessoal sobre o que constitui um
problema, e as respectivas serviço alvos em cada nível, tem, obviamente, ser
concebido em separado.
Prioritização problema deve também ter em conta a gravidade dos problemas.

Gravidade neste contexto refere-se a quão sério é o problema do ponto de vista
de infra-estrutura, por exemplo:
• O sistema pode ser recuperado, ou ele precisa ser substituído?

• Quanto vai custar?
• Quantas pessoas, com o que habilidades, que serão necessários para
corrigir o problema?
• Quanto tempo vai demorar para resolver o problema?
• Quão extenso é o problema (por exemplo, quantos são afetados CIs)?
4.4.5.5 Investigação e Diagnóstico de Problemas
Uma investigação deve ser conduzida para tentar diagnosticar o causa raiz do
problema - a velocidade e natureza desta investigação irá variar dependendo da
severidade do impacto, e urgência do problema - mas o nível apropriado de
recursos e perícia deve ser aplicada para encontrar um resolução proporcional
ao código atribuída prioridade e o alvo de serviço no local para que o nível de
prioridade.
Há uma série de técnicas de resolução de problemas úteis que podem ser

usados para ajudar a diagnosticar e resolver problemas - e estes devem ser

utilizadas como apropriado. Tais técnicas são descritas em mais detalhe mais
adiante nesta secção.
O CMS deve ser usada para ajudar a determinar o nível de impacto e para
ajudar a identificar e diagnosticar o ponto exacto de falha. O Know banco de
dados de erros (BDEC) também deve ser acessado e problema de
correspondência de técnicas (como pesquisas por palavras-chave) deve ser
usado para ver se o problema ocorreu antes e, em caso afirmativo, para
encontrar a resolução.
Muitas vezes, é valiosa para tentar recriar o fracasso, de modo a entender o que
deu errado, e então tentar várias formas de encontrar o mais adequado e
rentável resolução ao problema. Para fazer isso de forma eficaz, sem causar
mais perturbações ao usuários, uma teste sistema Será necessário que espelha
a ambiente de produção.
Há muitos problemas de análise, diagnóstico e técnicas de resolução de

pesquisas disponíveis e muito tem sido feito nesta área. Algumas das técnicas
mais úteis e freqüentemente usados incluem:
• Análise cronológica: Ao lidar com um problema difícil, muitas vezes há

relatos conflitantes sobre o que exatamente aconteceu e quando. É,
portanto, muito útil brevemente para documentar todos os eventos em
ordem cronológica - para fornecer um cronograma de eventos. Isso
muitas vezes faz com que seja possível ver os eventos que pode ter sido
provocado por outros - ou para descontar quaisquer reivindicações que
não são suportados pela seqüência de eventos.
• Análise de Valor dor: Este é o lugar onde uma visão mais ampla é tomado
da impacto de um incidente ou problema ou incidente / problema tipo. Em
vez de apenas analisar o número de incidentes / problemas de um
determinado tipo em um determinado período, uma análise mais profunda
é feito para determinar exatamente qual o nível de dor foi causada ao
organização/ Negócio por estes incidentes / problemas. A fórmula pode
ser concebido para calcular este nível de dor. Normalmente, isso pode
incluir tendo em conta:
• O número de pessoas afetadas
• A duração do tempo de inatividade causado
• O custar para o negócio (se este pode ser facilmente calculada ou
estimada).
Ao tomar todos esses fatores em conta, uma imagem muito mais

detalhada dos incidentes / problemas ou incidentes / problemas tipos que
estão causando mais dor pode ser determinado - para permitir um foco
melhor sobre as coisas que realmente importam e merecem maior
prioridade na resolução

• Kepner e Tregoe: Charles Kepner e Benjamin Tregoe desenvolveu uma
maneira útil de análise do problema, que pode ser usado formalmente
para investigar mais profundamente enraizados problemas. Eles definida
pelas seguintes etapas:
• definindo o problema
• descrevendo o problema em termos de identidade, localização,
tempo e tamanho
• determinar eventuais causas
• testando a causa mais provável
• verificar a verdadeira causa.
O método é descrito em maior detalhe no Apêndice C.
• Brainstorming: Muitas vezes pode ser valiosa para reunir as pessoas

relevantes, seja fisicamente ou por meios electrónicos, e para "debater" o
problema - com pessoas jogando idéias sobre o que a causa potencial
pode ser e possíveis ações para resolver o problema. Sessões de
brainstorming pode ser muito construtiva e inovadora, mas é igualmente
importante que alguém, talvez Gestor do Problema, documenta a
resultado e as ações acordadas e mantém um grau de controlar na
sessão (s).
• Diagrama de Ishikawas: Kaoru Ishikawa (1915-1989), um líder em
japonês qualidade controle, desenvolveu um método de documentar as
causas e efeitos que podem ser úteis para ajudar a identificar onde algo
pode estar errado, ou ser melhorado. Tal esquema é tipicamente o
resultado de um de brainstorming sessão em que solucionadores de
problemas pode oferecer sugestões. O objectivo principal é representado
pelo tronco do diagrama, e os factores principais são representados como
ramos. Factores secundários são então adicionados como hastes, e
assim por diante. Criando o diagrama estimula a discussão e muitas
vezes leva a uma maior compreensão de um complexo problema. Um
diagrama de exemplo é dado no Apêndice D.
• Análise de Pareto: Esta é uma técnica de separação de importantes
causas potenciais de questões mais triviais. Os seguintes passos devem
ser tomados:
1. Faça uma tabela listando as causas e sua freqüência como uma

porcentagem.
2. Organize as linhas na ordem decrescente de importância das causas, ou
seja, a causa mais importante primeiro.
3. Adicionar uma coluna de percentagem cumulativa para a mesa. Por esta
etapa, o gráfico deve ser algo como a Tabela 4.2, que ilustra 10 causas
de rede falha num organização.
Falhas na rede

Causas Percentagem do total Computação Acumulativo
Controlador de Rede 35 0% 35 35
Corrupção de arquivo 26 35% 26% 61
Resolução de conflitos 19 61% 19% 80
Servidor OS 6 80% 6% 86
Scripting erro 5 86% 5% 91
Não testado mudar 3 91% 3% 94
Erro do operador 2 94% 2% 96
Falha de backup 2 96% 2% 98
Tentativas de intrusão 1 98% 1% 99
Falha de disco 1 99% 1% 100

Tabela 4.2 Pareto ranking de causa
4. Criar um gráfico de barras com as causas, na ordem de sua porcentagem

do total.
5. Sobrepor um gráfico de linha das percentagens cumulativas. O gráfico
completo é ilustrado na Figura 4.5.
6. Desenhar linha a 80% em relação ao eixo y paralelo ao eixo x. Em
seguida, cair na linha, no ponto de intersecção com a curva sobre o eixo
x. Este ponto do eixo x separa as causas importantes e causas triviais.
Esta linha é representada como uma linha tracejada na Figura 4.5.

Figura 4.5 Importantes causas contra trivial
A partir deste gráfico, é claro, para ver que há três causas principais para a rede
falha no organização. Estes devem, por conseguinte, ser dirigida em primeiro
lugar.
4.4.5.6 Soluções Alternativas
Em alguns casos, pode ser possível encontrar um solução alternativa aos

incidentes causados pela problema - Forma temporária de superar as
dificuldades. Por exemplo, uma alteração manual pode ser feita a um ficheiro de
entrada para permitir que um programa de completar com sucesso o seu

funcionamento e permitir a facturação processo para completar
satisfatoriamente, mas é importante que o trabalho de um permanente resolução
continua quando tal se justifique - neste exemplo, a razão para o arquivo se
tornar corrompido, em primeiro lugar deve ser encontrada e corrigida para evitar
que isso aconteça novamente.
Nos casos em que uma solução é encontrada, por isso é importante que o
registro de problema permanece em aberto, e os detalhes da solução são
sempre documentado dentro do Grave problema.
4.4.5.7 Levantando um registro de Erro Conhecido
Logo que o diagnóstico está completa, e em particular quando a solução foi

encontrado (ainda que isto pode não ser ainda uma resolução permanente), uma
Grave erro conhecido devem ser levantadas e colocadas na Banco de Dados de
erro conhecido - De modo que, se mais incidentes ou problemas, eles podem
ser identificados e a serviço restaurarD mais rapidamente.
No entanto, em alguns casos, pode ser vantajoso aumentar a Gravar Erro

Conhecido ainda mais cedo no processo global - apenas para efeitos de
informação, por exemplo, - o mesmo que o diagnóstico não pode ser completa
ou uma solução encontrada, por isso não é aconselhável para definir um
questão processual concreta exatamente quando um registro de Erro Conhecido
deve ser levantada. Isso deve ser feito tão logo torna-se útil para o fazer!
A base de dados de erro conhecido e a forma como deve ser usada são
descritas em mais pormenor no ponto 4.4.7.2.
4.4.5.8 A resolução de problemas
Idealmente, assim que uma solução foi encontrado, deverá ser aplicada para
resolver o problema - mas na realidade salvaguardas podem ser necessários
para assegurar que este não causa dificuldades adicionais. Se algum mudar em
termos de funcionalidade é necessária isto exigirá um RFC para ser levantada e
aprovados antes a resolução pode ser aplicado. Se o problema é muito grave e
uma correção urgente é necessária por razões de negócios, então uma RFC de
emergência deve ser tratado pelo Emergency Change Advisory Board (ECAB).
Caso contrário, o RFC deve seguir o estabelecido Gestão da Mudança processo
para esse tipo de mudança - ea resolução deve ser aplicada apenas quando a
mudança foi aprovada e agendada para liberar. Enquanto isso, o BDEC deve ser
usado para ajudar a resolver rapidamente quaisquer outras ocorrências de
incidentes / problemas que ocorrem.
Nota: Pode haver alguns problemas para os quais um Business Case para a
resolução não pode ser justificado (por exemplo, onde o impacto é limitado, mas
o custar de resolução seria extremamente elevado). Nesses casos, uma decisão

pode ser tomada para deixar o Grave problema abrir, mas de usar uma
descrição solução no registro de erro Conhecido para detectar e resolver
quaisquer recorrências rapidamente. Cuidados devem ser tomados para usar o
código apropriado para marcar o registro de problema aberto para que ele não
conta contra o atuação da equipa de execução do processo e de forma que o
retrabalho não autorizado não ocorre.
4.4.5.9 Encerramento Problema
Quando qualquer mudar foi concluído (e com sucesso revered), e a resolução

tem sido aplicada, o Grave problema Deve ser formalmente fechado - Como no
caso de ocorrerem relacionado Grave incidentes que ainda estão abertos. A
verificação deve ser executada neste momento para garantir que o registro
contém uma descrição histórico completo de todos eventos - e se não, o registro
deve ser atualizado.
O estado de qualquer relacionado Grave erro conhecido deve ser atualizado

para mostra que a resolução tenha sido aplicada.
4.4.5.10 Revisão grande problema
Depois de todos os grandes problema (Conforme determinado pela

organização'S prioridade sistema), Enquanto ainda estão frescas as memórias
de análise deverá ser conduzida para aprender quaisquer lições para o futuro.
Especificamente, a revisão deverá analisar:
• Essas coisas que foram feitas corretamente

• Essas coisas que foram feitas erradas
• O que poderia ser feito melhor no futuro
• Como prevenir a recorrência
• Se houve qualquer responsabilidade de terceiros e se as ações de
acompanhamento são necessários.
Estas revisões podem ser usados como parte de atividades de treinamento e

conscientização para os funcionários de apoio - e as lições aprendidas devem
ser documentados em apropriada procedimentos, instrução de trabalhos, script
de diagnósticos ou registros de erro conhecidas. O Gestor de Problemas facilita
a sessão e documentos todas as ações acordadas.
O conhecimento aprendido com a revisão deve ser incorporado em uma serviço

rever reunião com o empresa cliente para assegurar a cliente está ciente das
ações e os planos para evitar futuras incidente graves ocorra. Isso ajuda a
melhorar a satisfação do cliente e assegurar o negócio que Operação de
Serviços está a lidar com incidentes de maior responsabilidade e trabalhando
ativamente para evitar que se repitam no futuro.

4.4.5.11 Os erros detectados no ambiente de desenvolvimento
É raro para qualquer novo aplicaçãos, ou sistemas de software liberars para ser
completamente erroLivre. É mais provável que, durante o teste de tais novas
aplicações, sistemas ou versões de um sistema de prioridades serão utilizados
para erradicar o mais sério culpas, mas é possível que pequenas falhas não são
rectificadas - muitas vezes por causa do equilíbrio que tem de ser feita entre o
fornecimento de novas funcionalidades para o negócio, o mais rapidamente
possível e garantir código totalmente livre de falhas ou componentes.
Quando uma decisão é feita para lançar algo para o ambiente de produção que
inclui deficiências conhecidas, estes devem ser registrados como Erros
Conhecidos no BDEC, juntamente com detalhes de solução alternativas ou
atividades de resolução. Deve haver um passo formal no teste de sinal fora-de
que assegura que esta transferência ocorre sempre (ver Transição de Serviço
publicação).
A experiência tem mostrado, se isso não acontecer, ele vai levar a um apoio
muito maior custars quando o usuários começar a sentir as falhas e aumentar os
incidentes que têm de voltar a ser diagnosticado e resolvido tudo de novo!
A grande maioria dos Grave problemas será desencadeada em reação a um ou

mais incidentes, e muitos vão ser levantada ou iniciada através equipe de
Service Desk. Registros outro problema, e os correspondentes Registros de erro
conhecido, pode ser desencadeada em testes, particularmente as últimas fases
de testes, como Usuário Teste de aceitação / Trials (UAT), se for tomada a
decisão de ir em frente com um liberar mesmo que alguns culpas são
conhecidos. Fornecedores podem desencadear a necessidade de algum Grave
problemas através da notificação de possíveis falhas ou deficiências conhecidas
em seus produtos ou serviços (por exemplo, um aviso pode ser dado em relação
ao uso de um CI em particular e um registro de problema pode ser aumentado
para facilitar a investigação pela equipe técnica da condição de CIs no prazo o
organização'S Infraestrutura de TI).
O primário relação entre Incidentes e Gerenciamento de Problemas foi discutido

em pormenor nos pontos 4.2.6 e 4.4.5.1. Outras interfaces-chave incluem o
seguinte:
• Gestão da Mudança: Gerenciamento de Problemas assegura que
todo resoluçãos ou solução alternativas que requerem um mudar a
um CI são submetidas através do Gerenciamento de Mudança
através de um RFC. Gestão da Mudança irá monitorar o progresso
dessas alterações e manter Gerenciamento de Problemas

aconselhou. Gerenciamento de Problemas também está envolvido
em corrigir a situação causada pelas mudanças fracassadas.
• Gerenciamento da Configuração: Gerenciamento de Problemas
usa o CMS para identificar CIs com defeito e também para
determinar a impacto de problemas e resoluçãos. O CMS também
pode ser utilizado para formar a base para a BDEC e manter ou
integrar-se com os registos de problemas.
• Gerenciamento de Liberação e Implantação: É responsável por
rolando correções de problemas fora no viver ambiente. Ela
também ajuda a assegurar que o associado erro conhecidos são
transferidos do desenvolvimento Banco de Dados de erro
conhecido no banco de dados de erro vivos conhecidos.
Gerenciamento de Problemas irá auxiliar na resolução de
problemas causados por falhas durante o processo de liberação.
• Gerenciamento de Disponibilidade: Está envolvido com a
determinação de como reduzir tempo de inatividade e aumentar a
produtividade. Como tal, tem uma estreita relação com a Gestão
de Problemas, especialmente as áreas pró-ativas. Grande parte da
gestão da informação disponível no Gerenciamento de Problemas
será comunicada ao Gerenciamento de Disponibilidade.
• Gerenciamento da Capacidade: Alguns problemas requerem
investigação pelas equipes de capacidade de gestão e técnicas,
por exemplo, atuação questões. Gerenciamento da Capacidade irá
também ajudar a avaliar as medidas pró-ativas. Gerenciamento de
Problema fornece informações gerenciais em relação ao qualidade
das decisões tomadas durante o Planejamento de Capacidade
processo.
• De serviços de TI Continuidade: Problema atos de gestão como
um ponto de entrada Gerenciamento da Continuidade do Serviço
onde um problema significativo não for resolvido antes de começar
a ter um grande impacto sobre o negócio.
• Melhoria de Serviço Continuada
• Gerenciamento de Nível de Serviço: A ocorrência de incidentes e
problemas afeta o nível de prestação de serviços medidos pela
SLM. Gerenciamento de Problemas contribui para melhorias na
nível de serviços, e suas informações de gestão é utilizado como a
base de uma parte do SLA rever componentes. SLM também
fornece parâmetros dentro dos quais obras Problema de gestão,
como impacto informação e os efeitos sobre os serviços de
propostas de resoluções e medidas pró-ativas.
• Gestão Financeira: Auxilia na avaliação do impacto das propostas
resoluçãos ou solução alternativas, bem como Análise de Valor
dor. Gerenciamento de Problema fornece gestão da informação
sobre o custar de resolver e prevenir problemas, que é usado

como entrada para o orçamentação e contabilidade sistemas e
Custo Total de Propriedade cálculos.
4.4.7.1 CMS
O CMS vai realizar detalhes de todo o componentes da Infraestrutura de TI bem

como o relaçãos entre estes componentes. Ele vai atuar como uma fonte valiosa
para o problema diagnóstico e para avaliar o impacto dos problemas (por
exemplo, se este disco é baixo, os dados que estão no disco, o que serviços
usar esses dados, o que usuários usar esses serviços?). Como ele também irá
realizar detalhes das atividades anteriores, ele também pode ser usado como
uma fonte valiosa de dados históricos para ajudar a identificar as tendências ou
fraquezas potenciais - uma parte essencial do Gerenciamento de Problemas
pró-ativa (Ver Melhoria de Serviço Continuada publicação).
4.4.7.2 Banco de Dados Erro Conhecido
A finalidade de um Banco de Dados de erro conhecido é permitir o

armazenamento de conhecimento prévio de incidentes e problemas - e como
eles foram superados - para permitir mais rápido diagnóstico e resolução se
repitam.
O Grave erro conhecido deve manter detalhes exatos da culpa e os sintomas

que ocorreram, juntamente com detalhes precisos de qualquer ação ou solução
alternativa de resolução que podem ser tomadas para restaurar o serviço e / ou
resolver o problema. Um incidente contagem também será útil para determinar a
frequência com que os incidentes são susceptíveis de se repetir e influenciar as
prioridades, etc
Deve notar-se que um Business Case para uma solução permanente para
alguns problemas pode não existir. Por exemplo, se um problema não provocar
perturbações graves e existe uma solução e / ou o custar de resolver o problema
supera de longe os benefícios de uma solução permanente - então uma decisão
pode ser tomada a tolerar a existência do problema. No entanto, será ainda
desejável diagnosticar e implementar uma solução tão rapidamente quanto
possível, que é onde o BDEC pode ser de ajuda.
É essencial que os dados colocados na base de dados podem ser recuperados

rapidamente e com precisão. O Gerente de problema deve ser totalmente
treinado e familiarizado com os métodos de pesquisa / algoritmos usados pelo
banco de dados selecionado e deve garantir que, quando cuidadosamente novo
registros são adicionados, os principais critérios relevantes da pesquisa são
corretamente incluído.

Cuidados devem ser tomados para evitar a duplicação de registros (ou seja, o
mesmo problema descrito em duas ou mais formas como registros separados).
Para evitar isso, o Gerenciador de problema deve ser a única pessoa capaz de
entrar em um novo recorde. Outro grupo de apoios deve ser permitida, e até
incentivado, para propor novos registros, mas estes devem ser controlados pelo
Gerente problema antes de entrar no BDEC. Em grandes organizações, onde
Gerenciamento de Problemas agentes existir em vários locais, mas um único
BDEC é usado (recomendado!), um procedimento deve ser acordado entre
todos os funcionários Gerenciamento de Problema para garantir que essa
duplicação não pode ocorrer. Isso pode envolver a designação de apenas um
membro da equipe como Gerente BDEC central.
A BDEC deve ser utilizado durante as fases de diagnóstico de incidentes e

problemas para tentar acelerar a resolução processo - E novos registos deve ser
adicionado tão rapidamente quanto possível quando um novo problema foi
identificado e diagnosticadas.
Toda a equipe de suporte deve ser bem treinados e familiarizados com o valor
que o BDEC pode oferecer e da forma como deve ser usado. Eles devem ser
capazes prontamente para recuperar e utilizar os dados.
Nota: Algumas ferramentas / implementações podem optar por delinear Erro

Conhecidos simplesmente pela alteração de um campo no original Grave
problema. Isto é aceitável, desde que o mesmo nível de funcionalidade está
disponível.
A BDEC, como o CMS, faz parte de um grande Serviço do Sistema de Gestão

do Conhecimento (SKMS) ilustrado na Figura 4.6. Mais informação sobre os
SKMS pode ser encontrada na Transição de Serviço publicação.

Figura 4.6 Serviço do Sistema de Gestão do Conhecimento
4.4.8 Métricas
A seguir métricos devem ser usados para avaliar a eficácia e eficiência do

Gerenciamento de Problemas processo, Ou seu operação:
• O número total de problemas registados no período (como uma medida

de controlo)
• O percentual de problemas resolvidos dentro SLA metas (ea porcentagem
que não são!)
• O número ea porcentagem de problemas que ultrapassou a sua meta
resolução vezes
• O acúmulo de problemas pendentes e da tendência (estática, reduzindo
ou aumentando?)
• A média custar de tratamento de um problema
• O número de grandes problemas (aberto e fechado e backlog)
• A percentagem de grande problema Comentes realizados com sucesso
• O número de Erro Conhecidos adicionados ao BDEC
• A precisão da percentagem BDEC (a partir de auditars da base de dados)
• O percentual de Comentários grande problema concluída com sucesso e
no tempo.
Todas as medidas devem ser discriminadas por categoria,impacto, Gravidade,

urgência e prioridade e comparados com períodos anteriores.

Um grande dependência para Gerenciamento de Problemas é o

estabelecimento de um processo eficaz de Gestão de Incidentes e ferramentas.
Isto irá assegurar que os problemas são identificados, logo que possível, e que à
medida que o trabalho é feito em grande parte pré-qualificação quanto possível.
No entanto, é também crucial que os dois processos têm interfaces formais e de
trabalho comum práticas. Isso significa o seguinte:
• Ligando ferramentas de gerenciamento de incidentes e problemas

• A capacidade de se relacionar e de Incidentes Grave problemas
• O pessoal de segunda e terceira linha deve ter um bom trabalho relação
com a equipe na primeira linha
• Certificar-se de que o negócio impacto é bem compreendida por todo o
pessoal que trabalha no problema resolução.
Além disso, é importante que Gerenciamento de Problemas é capaz de usar

todo o conhecimento e Gerenciamento de Configuração recursos disponível.
Outra CSF é a formação contínua de pessoal técnico em ambos os aspectos

técnicos do seu trabalho, bem como as implicações de negócios de serviços que
suportam e os processos que eles usam

4,5 Gerenciamento de Acesso
Gerenciamento de Acesso é o processo de concessão de autorização usuárioo
direito de usar um serviço, Enquanto impedindo o acesso a usuários não-
autorizados. Também tem sido referido como Direitos Gestão ou Gestão de
Identidade em diferentes organizações.
Gerenciamento de Acesso prevê o direito de que os usuários possam usar um

serviço ou grupo de serviços. É, portanto, a execução de políticas e ações
definidas no Segurança e Gerenciamento de Disponibilidade.
4.5.2 Âmbito
Gerenciamento de Acesso é efetivamente a execução de disponibilidade e

Gestão de Segurança da Informação, Na medida em que permite que o
organização para administrar o confidencialidade,disponibilidade e integridade
de dados da organização e de propriedade intelectual.
Gerenciamento de Acesso garante que os usuários têm o direito de usar um

serviço, mas não garante que esse acesso está disponível em todos os
momentos acordados - esta é fornecida pelo Gerenciamento de Disponibilidade.
Gerenciamento de Acesso é um processo que é executado por todos os

técnicos e Aplicação de Gestão de funçãos e não é geralmente uma função
separada. No entanto, não é provável que seja um único controlar ponto de
coordenação, geralmente em TI Gestão de Operações ou sobre o Service Desk.
Gestão de acesso pode ser iniciada por um Solicitação de Serviço através do

Service Desk.
Access Management fornece o seguinte valor:
• Acesso controlado aos serviços garante que a organização é capaz de

manter de forma mais eficaz o confidencialidade de suas informações
• Os funcionários têm o nível de direito de acesso a executar as suas
tarefas de forma eficaz
• Há menos probabilidade de erros feitos na entrada de dados ou na
utilização de um serviço crítico por um utilizador inexperiente (por
exemplo, produção controlar sistemas)
• A capacidade de auditar utilização dos serviços e traçar o abuso de
serviços

• A capacidade mais facilmente para revogar o acesso direitos quando
necessário - uma importante segurança consideração
• Pode ser necessária para regulamentar observância (Por exemplo, SOX,
HIPAA, COBIT).
Gerenciamento de Acesso é o processo que permite usuários para utilizar os

serviços que estão documentados no Catálogo de Serviços. É composto pelos
seguintes conceitos básicos:
• Acesso se refere ao nível e extensão da funcionalidade de um serviço ou

de dados que um usuário tem o direito de usar.
• Identidade refere-se à informação sobre eles que os distingue como um
indivíduo e que verifica a sua estado dentro do organização. Por
definição, a identidade de um usuário é único para o usuário. (Isto é
abordado com mais detalhe no ponto 4.5.7.1.)
• Direitos (Também chamados de privilégios) referem-se às configurações
reais em que um usuário é fornecido acesso a um serviço ou grupo de
serviços. Direitos típicos, ou níveis de acesso, incluem ler, escrever,
executar, alterar, excluir.
• Serviços ou grupos de serviços. A maioria dos usuários não usam
apenas um serviço, E os usuários que executam um conjunto semelhante
de atividades irá usar um conjunto semelhante de serviços. Em vez de
fornecer acesso a cada serviço para cada usuário separadamente, é mais
eficiente para ser capaz de conceder a cada usuário - ou um grupo de
usuários - o acesso a todo o conjunto de serviços que eles têm o direito
de usar, ao mesmo tempo. (Isto é discutido em mais pormenor no ponto
4.5.7.2.)
• Serviços de Diretório refere-se a um tipo específico de ferramenta que é
utilizada para gerenciar o acesso e direitos. Estes são discutidos na
seção 5.8.
4.5.5.1 Solicitação de acesso
De acesso (ou restrição) pode ser solicitado através de um qualquer número de

mecanismos, incluindo:
• Um pedido padrão gerada pelo Recursos Humanos sistema. Isso

geralmente é feito sempre que uma pessoa for contratado, promovido,
transferido ou quando deixam a empresa
• ARequisição de Mudança
• ASolicitação de Serviço apresentadas através do Cumprimento de
Requisição sistema

• Ao executar um script pré-autorizado ou opção (por exemplo, o download
de um aplicação a partir de uma preparação servidor como e quando ela
é necessária).
Regras para o pedido de acesso são normalmente documentados como parte do

Catálogo de Serviços.
4.5.5.2 Verificação
Gestão de acesso precisa verificar cada pedido de acesso a uma De serviços de

TI a partir de duas perspectivas:
• Que o usuário solicitar o acesso é que eles dizem que são

• Que eles têm um legítimo exigência para esse serviço.
O primeiro categoria é geralmente obtida pelo usuário fornecendo o seu nome

de usuário e senha. Dependendo da organização segurança políticas, o uso do
nome de usuário e senha são geralmente aceitos como prova de que a pessoa é
um legítimo usuário. No entanto, para os serviços mais sensíveis identificação
adicional pode ser necessária (uso, biométricos de uma chave de acesso
eletrônico ou dispositivo de criptografia, etc.)
A segunda categoria vai exigir algum independente verificação, Que não seja o
pedido do utilizador. Por exemplo:
• Notificação de Recursos Humanos que a pessoa é um funcionário novo e

requer tanto um nome de usuário e acesso a um conjunto padrão de
serviços
• Notificação de Recursos Humanos que o usuário tenha sido promovido e
requer acesso a adicional recursos
• Autorização a partir de uma (adequada definida no processo) Gerente
• Apresentação de um Solicitação de Serviço (Com provas), através da
Service Desk
• Apresentação de um RFC (com provas) através de Change Management,
ou a execução de um pré-definido Mudança Padrão
• Apolítica afirmando que o usuário pode ter acesso a um serviço opcional,
se eles precisarem.
Para novos serviços, a Alteração do registro deve especificar quais usuários ou

grupos de usuários terão acesso ao serviço. Gerenciamento de Acesso Em
seguida, verifique se todos os usuários ainda são válidos e fornecer
automaticamente o acesso, conforme especificado no RFC.
4.5.5.3 Prever direitos

Gerenciamento de Acesso não decide quem tem acesso a que De serviços de
TIs. Em vez disso, Gestão de Acesso executa as políticas e regulamentos
definidos durante Estratégia de Serviço e Design de Serviços. Gerenciamento de
Acesso impõe decisões para restringir ou fornecer acesso, em vez de tomar a
decisão.
Assim que um usuário tenha sido verificada, Gestão de Acesso irá fornecer o
usuário com direitos utilizar o requerido serviço. Na maioria dos casos, isso vai
resultar em um pedido para cada equipe ou departamento envolvido no apoio
que o serviço para tomar as medidas necessárias. Se possível, essas tarefas
devem ser automatizadas.
Quanto mais papels e grupos que existem, o mais provável é que o conflito do
papel irá surgir. Conflito papel neste contexto se refere a uma situação em que
dois papéis ou grupos específicos, se pertencer a um único usuário, vai criar
problemas com a separação de funções ou conflito de interesse. Exemplos
incluem:
• Um papel requer acesso detalhado, enquanto um outro papel que impede

o acesso
• Dois papéis permitir que um usuário para executar duas tarefas que não
devem ser combinados (por exemplo, um empreiteiro pode registrar sua
folha de tempo para uma projeto e aprovar todos os pagamentos no
trabalho para o mesmo projeto).
Conflito papel pode ser evitada pela criação cuidadosa de funções e grupos,
mas mais frequentemente são causadas por políticas e decisões tomadas fora
do Operação de Serviço - Seja pela empresa ou por diferentes equipes de
projeto de trabalho durante Design de Serviços. Em cada caso, o conflito deve
ser documentado e encaminhado para a das partes interessadass para resolver.
Sempre funções e grupos são definidos, é possível que eles poderiam ser
definidas de forma demasiado ampla ou demasiado restritiva. Haverá sempre os
usuários que precisam de algo um pouco diferente dos papéis pré-definidos.
Nestes casos, é possível a utilização de papéis padrão e, em seguida, adicionar
ou subtrair direitos específicos, conforme necessário - semelhante ao conceito
de linhas de base e Variantes em Gerenciamento da Configuração (Ver
Transição de Serviço publicação). No entanto, a decisão de fazer isso não está
nas mãos do indivíduo operacional funcionários. Cada exceção deve ser
coordenado pela Gerência de Acesso e aprovado através do processo de
origem.
Gerenciamento de Acesso deve realizar um regular rever do papels e grupos

que ele criou e gerenciar para garantir que eles são apropriados para os
serviços que ele oferece e apóia - e obsoletos ou indesejados papéis / grupos
devem ser removidos.

4.5.5.4 status de identidade de Monitoramento
Como usuárioO trabalho na organização, Seus papéis mudam e assim também

fazer as suas necessidades de acesso aos serviços. Exemplos de alterações
incluem:
• Mudanças de emprego. Neste caso, o utilizador terá possivelmente

necessidade de acesso a serviços diferentes ou adicionais.
• Promoções ou rebaixamentos. O usuário provavelmente vai usar o
mesmo conjunto de serviços, mas terá acesso a diferentes níveis de
funcionalidade ou dados.
• Transferências. Nesta situação, o utilizador pode ter acesso a
exactamente o mesmo conjunto de serviços, mas de uma região
diferente, com trabalho diferente práticas e diferentes conjuntos de dados.
• Demissão ou morte. De acesso precisa de ser completamente removida
para impedir que o nome de utilizador a ser utilizado como um segurança
brecha.
• Aposentadoria. Em muitas organizações, um empregado que se
aposenta ainda pode ter acesso a um conjunto limitado de serviços,
incluindo benefícios sistemas ou sistemas que lhes permitem adquirir os
produtos da empresa a uma taxa reduzida.
• Ação disciplinar. Em alguns casos, a organização exigirá uma restrição
temporária para impedir o utilizador de aceder a alguns ou a todos os
serviços que normalmente têm acesso. Deve haver um recurso no
processo e ferramentas para fazer isso, ao invés de ter que excluir e
restabelecer o acesso do usuário direitos.
• Demissões. Se um trabalhador é demitido ou contratado, ou quando uma
ação legal seja tomada contra um cliente (Por exemplo, para falta de
pagamento para produtos comprados na internet), o acesso deve ser
revogada imediatamente. Além disso, gerenciamento de acesso,
trabalhando em conjunto com a Gestão de Segurança da Informação,
deve tomar medidas activas para prevenir e detectar ações maliciosas
contra a organização daquele usuário.
Gerenciamento de Acesso deve entender e documentar o usuário típico Ciclo de

Vida para cada tipo de usuário e usá-lo para automatizar o processo. As
ferramentas de gerenciamento de acesso deve fornecer recursos que permitem
que um usuário para ser movida de um estado para outro, ou de um grupo para
outro, de forma fácil e com um auditar trilha.
4.5.5.5 acesso acompanhamento e rastreamento
Gestão de acesso não só deve responder às solicitações. Também é

responsável por garantir que os direitos que eles têm prestado estão sendo
usados corretamente.

A este respeito, monitorização e controlo de acesso devem ser incluídos no
monitoramento atividades de todos os técnicos e Aplicação de Gestão de
funçãos e tudo Operação de Serviço processos.
As exceções devem ser tratadas por Gerenciamento de Incidentes,

Possivelmente usando Incident Modelos projetado especificamente para lidar
com o abuso de direitos de acesso. Deve notar-se que a visibilidade de tais
acções deve ser restrito. Tornar esta informação disponível a todos os que têm
acesso ao Gerenciamento de Incidentes sistema irá expor vulnerabilidades.
Gestão de Segurança da Informação desempenha um papel vital papel para

detectar o acesso não autorizado e comparando-o com o direitos que foram
fornecidos pela Gerenciamento de Acesso. Isso vai exigir o envolvimento de
gerenciamento de acesso na definição dos parâmetros para uso em ferramentas
de detecção de intrusão.
Gerenciamento de acesso também pode ser necessária para fornecer um

registro de acesso para serviços específicos durante as investigações forenses.
Se um usuário é suspeito de violação de política, Uso inadequado de recursos,
ou utilização fraudulenta de dados, gerenciamento de acesso pode ser obrigado
a fornecer provas de datas, horas e até mesmo conteúdo de acesso do usuário
aos serviços específicos. Isto é normalmente fornecido pelo Operacional pessoal
de que serviço, Mas trabalhando como parte do Gerenciamento de Acesso
processo.
4.5.5.6 Remoção ou restritiva de direitos
Assim como Access Management fornece direitos Para usar um serviço,

também é responsável pela revogação de tais direitos. Novamente, isto não é
uma decisão de que faz por si próprio. Em vez disso, ele irá executar as
decisões e políticas feitas durante Estratégia de Serviço e decisões de design e
também de gestores no organização.
Removendo o acesso geralmente é feito nas seguintes circunstâncias:
• Morte
• Renúncia
• Demissão
• Quando o usuário mudou os papéis e não requer mais o acesso ao
serviço
• Transferência ou viajar para uma área onde o acesso regional diferente
se aplica.
Em outros casos, não é necessário para remover o acesso, mas apenas para
proporcionar restrições mais severas. Estas podem incluir a redução do nível de

tempo, ou a duração do acesso. Situações em que o acesso deve ser restrito
incluem:
• Quando o usuário mudou de função ou foi rebaixado e já não requer o

mesmo nível de acesso
• Quando o usuário está sob investigação, mas ainda requer acesso a
serviços básicos, tais como e-mail. Neste caso seu e-mail pode ser
objecto de digitalização adicional (mas isso precisa ser tratado com muito
cuidado e em total conformidade com a organização do política de
segurança)
• Quando um usuário está fora da organização em uma missão temporária
e não vai exigir o acesso a esse serviço por algum tempo.
Gerenciamento de Acesso é desencadeada por um pedido de um ou mais

usuários para acessar um serviço ou grupo de serviços. Isto poderia ser
provenientes de qualquer dos seguintes:
• Uma RFC. Este é mais freqüentemente usado para apresentações em

grande escala de serviços ou atualizações onde o direitos de um número
significativo de usuários precisam ser atualizados como parte do projeto.
• ASolicitação de Serviço. Isso geralmente é iniciado através do Service
Desk, Ou diretamente no Cumprimento de Requisição sistema, E
executado pelo técnico relevante ou Aplicação de Gestão de equipes.
• A pedido dos humanos adequados pessoal Gestão de Recursos (que
deve ser canalizada através do Service Desk). Isto é normalmente
gerada, como parte do processo para contratação, promoção, realocação
e rescisão ou aposentadoria.
• O pedido do gerente de um departamento, que poderia ser a realização
de um RH papel, Ou que poderia ter tomado a decisão de começar a usar
um serviço pela primeira vez.
Gerenciamento de Acesso deve ser ligada aos processos de Recursos

Humanos para verificar a usuário'S identificar, bem como para garantir que eles
têm direito aos serviços que estão sendo solicitadas.
Gestão de Segurança da Informação é uma tecla motorista para Gerenciamento

de Acesso vez que irá proporcionar o segurança e as políticas de proteção de
dados e ferramentas necessárias para executar Gerenciamento de Acesso.
Gestão da Mudança desempenha um importante papel como meio para

controlar os pedidos de acesso reais. Isto é porque qualquer pedido de acesso a
um serviço é uma mudar, Embora seja geralmente processada como um
Mudança Padrão ou Solicitação de Serviço (Possivelmente usando uma modelo)
Uma vez que os critérios de acesso foram acordados por SLM.

SLM mantém a acordos para o acesso a cada serviço. Isso irá incluir os critérios
de quem tem direito de acesso a cada serviço, o que o custar de que o acesso
será, se o nível adequado e que o acesso será concedido a diferentes tipos de
usuário (por exemplo, gerentes ou funcionários).
Há também uma forte relação entre a Gestão de Acesso e Gerenciamento da

Configuração. O CMS pode ser usado para armazenamento de dados e
interrogados para determinar os detalhes de acesso atuais.
4.5.7.1 Identidade
O identidade de um usuário é a informação sobre eles que os distingue como

um indivíduo e que verifica seu status dentro da organização. Por definição, a
identidade de um usuário é único para o usuário. Uma vez que há casos em que
dois usuários compartilham um pedaço comum de informação (por exemplo,
eles têm o mesmo nome), a identidade é geralmente estabelecido usando mais
do que um pedaço de informação, por exemplo:
• Nome
• Endereço
• Detalhes de contato, por exemplo, de telefone, endereço de e-mail, etc
• Documentação física, por exemplo, carteira de motorista, passaporte,
certidão de casamento, etc
• Os números que se referem a um documento ou uma entrada numa base
de dados, por exemplo, número de funcionários, número de contribuinte,
número de identidade do governo, o número de carteira de motorista, etc
• A informação biométrica, por exemplo, impressões digitais, imagens da
retina, padrões de reconhecimento de voz, DNA, etc
• Data de validade (se aplicável).
A identidade do usuário é fornecida para qualquer pessoa com um legítimo

exigência para acessar De serviços de TIs ou informação organizacional. Estas
podem incluir:
• Funcionários
• Empreiteiros
• Vendedor pessoal (por exemplo, gerente de contass, pessoal de apoio,
etc)
• Clientes (especialmente na compra de produtos ou serviços através da
Internet).
A maioria das organizações vai verificar uma usuário'S identidade antes de se

juntar a organização solicitando um subconjunto da informação acima. O mais

seguro a organização, os tipos mais informações são necessárias e quanto mais
completamente eles são verificados.
Muitas organizações serão confrontados com a necessidade de acesso direitos

para pessoal temporário ou ocasional ou contratantes /fornecedors. A gestão do
acesso a esse pessoal muitas vezes se torna problemático - o acesso de
fechamento após o uso é muitas vezes tão difícil de gerir, ou mais, do que
proporcionar acesso inicialmente. Bem definido procedimentos entre TI e RH
deve ser estabelecido que incluem prova de falhas cheques que garantem
direitos de acesso são removidos imediatamente que já não se justificam ou
requerido.
Quando um usuário tem acesso a um aplicação, Que já deveria ter sido

estabelecido pela organização (geralmente os Recursos Humanos ou
Segurança Departamento) que o usuário é quem dizem que são.
Neste ponto, todas as informações que está arquivado eo arquivo está

associado a uma identidade corporativa, geralmente um número de empregado
ou contratante e uma identidade que pode ser usado para acessar corporativo
recursos e informações, geralmente uma identidade de usuário ou 'username' e
uma senha de associado.
4.5.7.2 Os usuários, grupos, funções e grupos de serviço
Enquanto cada usuário tem uma identidade individual, e cada De serviços de TI

pode ser visto como uma entidade em seu próprio direito, muitas vezes é útil
para agrupá-los de modo que eles podem ser gerenciados mais facilmente. Às
vezes, os termos "perfil do usuário"Ou" modelo de usuário 'ou' usuário papel'São
usados para descrever este tipo de agrupamento.
A maioria das organizações tem um conjunto padrão de serviços para todos os

usuários individuais, independentemente da sua posição ou emprego (excluindo
clientes - que não têm qualquer visibilidade aos serviços e processos internos).
Estas incluem serviços como mensagens, automação de escritório, suporte a
desktop, telefonia, etc Novos usuários são automaticamente fornecidos com
direitos de usar esses serviços.
No entanto, a maioria dos usuários também têm algum papel especializado que
eles desempenham. Por exemplo, para além dos serviços padrão, o utilizador
também executa uma função de gestão de marketing, o que requer que eles têm
acesso a alguns especializada de marketing e financeiros modelagem
ferramentas e dados.
Alguns grupos podem ter única exigências - como campo ou trabalhadores

domésticos que podem ter que discar ou usar Virtual Private Network (VPN),
com implicações de segurança que podem ter de ser mais bem gerenciado.

Para tornar mais fácil para Gerenciamento de Acesso para fornecer os direitos
apropriados, ele usa um catálogo de todas as funções na organização e quais os
serviços que suportam cada função. Este catálogo de funções deverá ser
compilado e mantido pela Administração Acesso em conjunto com o RH e,
muitas vezes, ser automatizado no Serviço de Diretórios ferramentas (ver
secção 5.8).
Além de jogar diferentes papéis, os usuários também podem pertencer a

diferentes grupos. Por exemplo, todos os contratantes são obrigados a registrar
seus quadros de horários em um cartão de tempo dedicado Sistema, Que não é
usado pelos funcionários. Gerenciamento de Acesso irá avaliar todas as funções
que um usuário desempenha, bem como os grupos que eles pertencem e
garantir que eles fornecem direitos de usar todos os serviços associados.
Nota: Todos os dados sobre os usuários estarão sujeitos a legislação de

protecção de dados (isso existe na maioria das localizações geográficas de uma
forma ou outra) por isso deve ser tratada e protegida como parte dos
procedimentos de segurança da organização.
4.5.8 Métricas
Métricos que podem ser usados para medir a eficiência e eficácia de

Gerenciamento de Acesso incluem:
• Número de pedidos de acesso (Solicitação de Serviço, RFC, etc)

• Instâncias de acesso concedido, por serviço,usuário, Departamento, etc
• Instâncias de acesso concedida pelo departamento ou individuais
concessão de direitos
• Número de incidentes que requerem uma redefinição do acesso direitos
• Número de incidentes causados por configurações de acesso incorretas.
Condições para sucesso Gerenciamento de Acesso incluem:
• A capacidade de verificar a identidade de um usuário (que a pessoa é que

eles dizem que são)
• A capacidade de verificar a identidade da pessoa que aprova ou
organismo
• A capacidade de verificar que um utilizador se qualifica para o acesso a
um serviço específico
• A capacidade de vincular os direitos de acesso múltiplo a um usuário
individual
• A capacidade para determinar o estado do utilizador em qualquer altura
(por exemplo, para determinar se eles ainda são empregados do
organização quando fazer logon em um sistema)

• A capacidade de gerenciar mudanças acesso de um usuário exigências
• A capacidade de restringir direitos de acesso a usuários não autorizados
• Um banco de dados de todos os usuários e os direitos que foram
concedidos.

4,6 As atividades operacionais de processos cobertos de
fases do ciclo de vida de outros
4.6.1 Gestão da Mudança
Gestão da Mudança é primeiramente coberta no Transição de Serviço

publicação, mas há alguns aspectos da gestão da mudança que Operação de
Serviço funcionários estarão envolvidos em uma base dia-a-dia. Estes incluem:
• Levantar e submeter RFCs como necessário para tratar de questões

operação de serviço
• Participação em reuniões ou CAB CAB / CE para garantir que a Operação
de Serviço riscos, questões e opiniões são tidas em conta
• Mudanças de execução, dirigidos pelo Gerenciamento de Mudanças,
onde envolvem Operação de Serviço componente ou serviços
• Fazendo as mudanças como dirigido por Gestão da Mudança onde eles
envolvem Operação de Serviço componente ou serviços
• Ajudar a definir e manter alterar modelos relativas à Operação de Serviço
componentes ou serviços
• Receber alteração de horários e garantir que todo o pessoal Operação de
Serviço estão cientes e preparados para todas as alterações relevantes
• Usando o Gerenciamento de Mudança processo por norma,
operacionalTipo muda.
4.6.2 Gerenciamento da Configuração
Gerenciamento da Configuração é primeiramente coberta no Transição de

Serviço publicação, mas há alguns aspectos do Gerenciamento de Configuração
que o pessoal Operação de Serviço serão envolvidos em uma base dia-a-dia.
Estes incluem:
• Gerenciamento de Configuração informar de quaisquer discrepâncias

encontradas entre qualquer CIs e do CMS
• Fazendo as alterações necessárias para corrigir eventuais discrepâncias,
sob a autoridade do Gerenciamento da Configuração, Onde se envolve
quaisquer componentes do serviço de operação ou serviços.
Responsabilidade pela actualização do CMS permanece com gerenciamento de

configuração, mas em alguns casos equipe de operações pode ser solicitado,
sob a direção de Gerenciamento de Configuração, para atualizar relaçãos, ou
até mesmo para adicionar novo CIS ou marca CIS como 'eliminados' no CMS,
se essas atualizações são relacionadas às atividades operacionais efetivamente
realizadas pela equipe de Operações.

4.6.3 Gerenciamento de Liberação e Implantação
Gerenciamento de Liberação e Implantação é principalmente coberta na

publicação Transição de Serviço, mas há alguns aspectos deste processo que o
pessoal Operação de Serviço será envolvido em uma base dia-a-dia. Estes
podem incluir:
• Reais ações de implementação em relação ao desenvolvimento de novo

liberars, sob a direção de Gerenciamento de Liberação e Implantação,
onde eles se relacionam com os componentes de serviço de operação ou
serviços
• A participação no planejamento estágios de grandes lançamentos para
aconselhar sobre questões operação de serviço
• A movimentação física de instituições de crédito de / para o DML como
necessário para cumprir seu operacional papels - ao aderir ao lançamento
relevante e Gestão de Implantação procedimentos, como garantir que
todos os itens são devidamente reservado e para trás dentro
4.6.4 Gerenciamento da Capacidade
Gerenciamento da Capacidade deveria operar em três níveis: Gerenciamento da

Capacidade de negócios,Gerenciamento da Capacidade de serviço e Recurso
Gerenciamento da Capacidade.
• Gerenciamento da Capacidade de negócios envolve o trabalho com a

empresa para planejar e antecipar tanto de longo prazo estratégico
questões e de curto prazo tático iniciativas que possam vir a ter um
impacto em TI capacidade.
• Gerenciamento da Capacidade de serviço é sobre a compreensão das
características de cada um dos De serviços de TIs, e, em seguida, a
exigência de que os diferentes tipos de usuários ou transaçãos ter sobre
a infra-estrutura subjacente - e como estes variam ao longo do tempo e
pode ser afetado pelo negócio mudar.
• Recurso Gerenciamento da Capacidade envolve a compreensão da
atuação características e capacidades e níveis de utilização de correntes
de todos os aspectos técnicos componentes (IC) que compõem o
Infraestrutura de TI, E prever a impacto de quaisquer alterações ou
tendências.
Muitas dessas atividades são de caráter estratégico ou de longo prazo

planejamento natureza e são abordados na Estratégia de Serviço, Design de
Serviços e Transição de Serviço publicações. No entanto, há um número de
operacional Capacidade de actividades de gestão que devem ser executadas
em uma base regular e contínua, como parte de Operação de Serviço. Estes
incluem os seguintes.

4.6.4.1 Capacidade e Performance Monitoring
Todos componentes da Infraestrutura de TI deve ser continuamente monitorado

(em conjunto com Gestão de Eventos) De modo que qualquer potencial
problemas ou tendências podem ser identificadas antes falhas ou atuação
degradação ocorre. Idealmente, tais monitoramento deve ser automatizada e
limiars deve ser definido de modo que a exceção alertars são criados em tempo
de permitir adequada evitando ou recuperação ação a ser tomada antes do
impacto adverso ocorre.
Os componentes e os elementos a serem monitorizadas irá variar dependendo

da infra-estrutura a ser utilizado, mas será tipicamente incluem:
• Utilização da CPU (global e discriminadas por sistema/serviço uso)

• Utilização de memória
• Taxas de ES (física e buffer) e utilização de dispositivo
• Comprimento da fila (máxima e média)
• Utilização arquivo de armazenamento (discos, partições segmentos)
• Aplicaçãos (rendimento taxas, taxas de falha)
• Bancos de dados (utilização, registro fechaduras, indexação, de
contenção)
• Rede transação taxas, erro e repetir as taxas de
• Transação tempo de resposta
• Duração perfis lote
• Internet / intranet do site / página taxas de acerto
• Internet tempos de resposta (externos e internos para firewalls)
• Número de sistema / aplicação de log-ons e usuários simultâneos
• Número de nós de rede em uso, e os níveis de utilização.
Existem diferentes tipos de ferramentas de monitoramento necessários para

coletar e interpretar dados em cada nível. Por exemplo, algumas ferramentas
permitem o desempenho de transações de negócios a ser monitorado, enquanto
outros vão monitorar CI comportamento.
Gerenciamento da Capacidade deve configurar e calibrar alarme limiars (quando

necessário, em conjunto com Gestão de Eventos, Como é muitas vezes
ferramentas de monitorização de eventos que podem ser utilizados), de modo
que a correcta alertar níveis são estabelecidos, e que qualquer filtragem é
estabelecido como necessário de modo a que apenas significativo eventos são
levantadas. Sem essa filtragem é possível que a "informação apenas 'alertas
podem obscurecer alertas mais significativos que exigem atenção imediata.
Além disso, é possível que grave falhas para causar "alerta tempestades" devido
a volumes muito altos de alertas repetidos, que novamente deve ser filtrada para
que as mensagens mais significativas não são obscurecidos.

Pode ser apropriado para uso externo, de terceiros, monitoramento capacidades
para alguns itens de configuração ou componentes da Infraestrutura de TI (Por
exemplo, sites de Internet Key / páginas). Gestão de capacidade deve ser
envolvido em ajudar especificar e selecionar qualquer capacidade de
acompanhamento e na integração dos resultados ou eventuais alertas com
acompanhamento outro e manipulação sistemas.
Gerenciamento da Capacidade de trabalhar com todas as medidas adequadas

grupo de apoios para tomar decisões sobre onde os alarmes são encaminhadas
e em escalada caminhos e prazos. As indicações deverão ser registrados no
Service Desk bem como para o pessoal de apoio apropriado, de modo que
adequado Grave incidentes pode ser levantado para uma permanente registro
do evento existe - e equipe de Service Desk ter uma visão de como o grupo de
apoio(S) está lidando com a culpa e pode intervir se necessário.
Fabricantes alegou atuação capacidades e concordou meta de nível de serviços,

juntamente com o desempenho histórico real monitorados e os dados de
capacidade, devem ser utilizados para definir níveis de alerta. Isto pode
necessitar de ser um processo iterativo processo inicialmente, realizar alguns
ajustes de tentativa e erro, até que os níveis corretos sejam alcançados.
Nota: Gerenciamento da Capacidade pode ter que se envolver no capacidade

exigências e capacidades de IT Service Management. Se o organização A
equipe tem bastante serviço para lidar com a taxa de incidentes; se a estrutura
CAB pode lidar com o número de mudanças que está sendo solicitada a rever e
aprovar, se ferramentas de suporte pode lidar com o volume de dados que estão
sendo coletados são questões capacidade de gestão, que a equipe de Gestão
de Capacidade podem ser feitas para ajudar a investigar e responder.
4.6.4.2 capacidade ou manipulação desempenho incidentes

relacionados
Se um alerta é acionado, ou um incidente é gerado no Service Desk, causada

por uma capacidade de corrente ou em curso ou Gestão de Desempenho
problema, Gerenciamento de Capacidade deve envolver-se para identificar a
causa e encontrar uma resolução. Trabalhando em conjunto com a adequada
suporte técnico grupos, e ao lado Gerenciamento de Problemas, Todas as
investigações necessárias devem ser realizados para detectar exatamente o que
deu errado eo que é necessário para corrigir a situação.
Pode ser necessário mudar a monitorização mais detalhada durante a fase de

investigação para determinar a causa exata. O monitoramento é geralmente
definida em um "fundo" nível em circunstâncias normais devido à grande
quantidade de dados que podem ser gerados e evitar colocar muito alto um
fardo sobre a infra-estrutura de TI - mas quando as dificuldades específicas

estão sendo investigados monitoramento mais detalhado pode ser necessária
para identificar a causa exata.
Quando uma solução ou uma solução potencial, foi encontrado, as alterações

necessárias para resolver o problema deve ser aprovada através formais Gestão
da Mudança antes da implementação. Se a falha está causando graves
perturbações e uma resolução de urgência é necessária, urgente mudar
processo deve ser usado. É muito importante que não "afinação"Ocorre sem
submissão através do Gerenciamento de Mudança, pois mesmo aparentemente
pequenos ajustes muitas vezes pode ter grandes efeitos cumulativos - por vezes
em toda a infraestrutura de TI inteira.
4.6.4.3 Capacidade e tendências de desempenho
Gerenciamento da Capacidade tem um papel a desempenhar na identificação

de qualquer capacidade ou as tendências de desempenho como eles se tornam
perceptíveis. Mais pormenores sobre as acções necessárias para resolver tais
tendências estão incluídos no Melhoria de Serviço Continuada publicação.
4.6.4.4 Armazenamento de dados de gerenciamento de capacidade
Grandes quantidades de dados são usualmente gerados através capacidade e

atuação monitoramento. Monitoramento de metros e tabelas de apenas alguns
poucos kbytes cada um pode crescido rapidamente em arquivos enormes se
muitos componentes estão a ser monitorizados em intervalos relativamente
curtos. Outro problema com o controlo muito curto prazo é de que não é possível
a obtenção de uma informação significativa sem olhar ao longo de um período
mais longo. Por exemplo, um único instantâneo de um processador irá mostrar o
dispositivo a ser ou "ocupado" ou "inactivo" - mas um resumo sobre, por
exemplo, um período de 5 minutos irá mostrar o nível médio de utilização
durante o mesmo período, o que é um tanto medida mais significativa se o
dispositivo é capaz de trabalhar confortavelmente, ou se o desempenho
potencial problemas são prováveis de ocorrer.
Em qualquer organização é provável que os instrumentos de controlo utilizados

irá variar muito - com uma combinação de sistemaFerramentas específicas,
muitos deles parte do sistema operacional básico, e ferramentas especializadas
de monitoramento a ser utilizados. A fim de coordenar os dados que estão
sendo gerados e permitir a retenção de dados úteis para fins de análise e
tendências, alguma forma de repositório central de dados para a realização
desta resumo é necessário: um Gerenciamento da Capacidade Sistema de
Informação (CMIS).
O formato, localização e projeto dessa base de dados deve ser planejado e

implementado com antecedência - ver o Design de Serviços publicação para

mais detalhes - mas haverá algum operacional para lidar com aspectos, tais
como limpeza de banco de dados e apoios.
4.6.4.5 Gerenciamento da Demanda
Gerenciamento da Demanda é o nome dado a uma série de técnicas que podem

ser usadas para modificar a procura de um determinado recurso ou serviço.
Algumas técnicas de gestão da procura pode ser planejado com antecedência, e
estes são abordados com mais detalhes na publicação Service Design. No
entanto, há outros aspectos da gestão da procura, que são de natureza mais
operacional, exigindo mais curto prazo a ação.
Se, por exemplo, o desempenho de um determinado serviço, está a causar

preocupação, a curto prazo e restrições simultaneidade de usuários são
necessárias para permitir melhorias de desempenho para um pequeno grupo
restrito, em seguida, Operação de Serviço funçãos terá que tomar medidas para
implementar tais restrições - geralmente acompanhada de acções concorrentes
para implementar o registro fora de usuários que estiveram inativos por um
período de tempo acordado para liberar recursos para outros.
4.6.4.6 Workload Management
Pode haver ocasiões em que a otimização dos recursos de infra-estrutura é

necessária para manter ou melhorar o desempenho ou rendimento. Isso muitas
vezes pode ser feito através de Workload Gestão, que é um termo genérico para
cobrir tais ações como:
• Reprogramação de um determinado serviço ou carga de trabalho para

executar em um horário diferente do dia, ou do dia da semana, etc
(geralmente longe do pico vezes para fora do pico janelas) - que, muitas
vezes, significa ter que fazer ajustes para trabalho de agendamento de
software.
• Mover um serviço ou carga de trabalho de um local ou conjunto de CIs
para outro - muitas vezes para equilibrar a utilização ou tráfego.
• Virtualização técnica: criação e utilização de sistemas de virtualização
para permitir o movimento de processamento em torno da infra-estrutura
para dar um melhor desempenho /resiliência de um modo dinâmico.
• Limitar ou mover demanda de recursos por meio de técnicas de gestão da
demanda (ver acima e também a publicação de Desenho de Serviço).
Só será possível gerenciar cargas de trabalho de forma eficaz se existe um bom

entendimento de que as cargas de trabalho será executado em que momento e
quanto a utilização de recursos cada lugares de carga de trabalho sobre a infra-
estrutura de TI. Diligente monitoramento e análise de carga de trabalhos é
necessário, portanto, uma base operacional em andamento.

4.6.4.7 Modelação e aplicações de dimensionamento
Modelagem e / ou dimensionamento de novos serviços e / ou aplicaçãos devem,

se adequado, ser feito durante o planejamento fases e de transição - ver a
Design de Serviços e Transição de Serviço publicações. No entanto, o Operação
de Serviço funçãos têm uma papel a desempenhar na avaliação da precisão das
previsões e realimentando quaisquer problemas ou discrepâncias.
4.6.4.8 Planejamento de Capacidade
Durante Design de Serviços e Transição de Serviço, o capacidade exigências de

De serviços de TIs são calculados. A prospectiva plano de capacidade deve ser
mantido e atualizado regularmente e Operação de Serviço terá um papel a
desempenhar. Tal plano deve olhar para a frente até dois anos ou mais, mas
deve ser revered regularmente a cada três a 12 meses, dependendo da
volatilidade e dos recursos disponíveis.
O plano deve ser ligada ao organizaçãoO ciclo de planejamento financeiro, de

modo que qualquer despesa necessária para atualizações de infra-estrutura,
melhorias ou adições podem ser incluídos no orçamento estimativas e
aprovados com antecedência.
O plano deve prever o futuro, mas também deve examinar e informar sobre as
previsões anteriores, particularmente para dar alguma confiança nas previsões
futuras. Onde as discrepâncias foram encontradas, elas devem ser explicadas e
medidas correctivas futuro descrito.
O Plano de Capacidade pode geralmente cobrem:
• Atuais detalhes de desempenho e utilização, com as recentes tendências

para todos os itens de configuração chave, incluindo
• Redes de backbone
• LANs
• Mainframes (se ainda utilizado)
• Chave servidors
• Principais dispositivos de armazenamento de dados
• Equipamentos selecionados desktop (representante) e laptop
• Principais sites
• Bases de dados-chave
• Chave aplicaçãos
• Operacional capacidade - eletricidade espaço, capacidade,
ambientais (ar-condicionado), com peso de piso, a geração de
calor e saída, a demanda elétrica e abastecimento de água e etc
• Meios magnéticos.
• Estimado atuação e utilização para todos os CIs tal durante o período de
planejamento (por exemplo, os próximos três meses)

• Os dados comparativos com as estimativas anteriores - para permitir que
a confiança nas estimativas futuras para ser julgado
• Relatórios sobre qualquer específico capacidade dificuldades encontradas
no período passado, com detalhes de recuperação e as ações
preventivas tomadas para o futuro
• Pormenores de quaisquer atualizações necessárias ou dos contratos
necessários e previstos para o futuro, com indicativos custars e prazos.
• Quaisquer riscos capacidade potencial que provavelmente - com sugerido
contramedidas caso venham a ocorrer.
4.6.5 Gerenciamento de Disponibilidade
Durante Design de Serviços e Transição de Serviço,De serviços de TIs são

concebidos para disponibilidade e recuperação. Operação de Serviço é
responsável por realmente fazer o serviço de TI disponíveis para o especificado
usuários no momento necessário e nos níveis acordados.
Durante operação de serviço as equipes de TI e usuários estão na melhor

posição para detectar se os serviços realmente cumprir o acordado exigências, e
se o projeto destes serviços é eficaz.
O que parece ser uma boa idéia durante a fase de projeto não pode realmente
ser prático ou ótima. A experiência dos usuários e operacional funçãos faz uma
entrada principal para a melhoria contínua dos serviços existentes e do design.
No entanto, há um número de desafios com acesso a este conhecimento:
• A maioria das experiências das equipes operacionais e os usuários são

ou informal, ou se espalhar através de múltiplas fontes.
• O processo para recolha e tratamento destes dados precisa ser
formalizado.
• Usuários e do pessoal operacional geralmente são totalmente ocupado
com suas atividades regulares e tarefas e é muito difícil para eles se
envolver em regular planejamento e atividades de design. Um argumento
freqüentemente feita aqui é que se o projeto é melhorada, as equipes
operacionais serão menos ocupado resolvendo problemas e, portanto,
têm mais tempo para se envolver em atividades de projeto. No entanto,
prática mostra que, assim como o pessoal são liberados, eles muitas
vezes se tornam o alvo de exercícios de redução de efectivos.
Dito isto, há três principais oportunidades para o pessoal operacional a ser

envolvidos em Melhoria de disponibilidade, uma vez que estes são geralmente
vistos como parte da sua responsabilidade em curso:
• Comente das atividades de manutenção. Design de Serviços irá definir

as programações de manutenção detalhada e actividades, que são

necessários para mantê-lo funcionando serviços no nível requerido de
atuação e disponibilidade. Comparação regular de atividades reais de
manutenção e horas com a planos vai destacar as áreas potenciais de
melhoria. Uma das fontes dessas informações é uma revisão de se
Objetivo de manutenção do serviços foram atendidas e, se não, por que
não.
• Principais opiniões problema. Problemas podem ser o resultado de
qualquer número de factores, um dos quais é má concepção. Opiniões
problema, portanto, pode incluir oportunidades para identificar melhorias
para o design de serviços de TI, que incluem disponibilidade e melhoria
da capacidade.
• Envolvimento em iniciativas específicas, utilizando técnicas como a
Análise de Falhas de Serviço (SFA), Componente Análise de Impacto
falha (ACIA), ou Análise da Árvore de Falhas (FTA) ou como membros de
Observation técnica (TO) atividades - como parte do acompanhamento às
principais problemas ou como parte de um processo contínuo serviço
melhoria programa, Em colaboração com a dedicada Gerenciamento de
Disponibilidade pessoal. Estes Gerenciamento de Disponibilidade
técnicas são explicadas em mais detalhe no Design de Serviços
publicação.
Pode haver ocasiões em que Operacional Equipe se precisa tempo de

inatividade de um ou mais serviços para que possam realizar suas atividades
operacionais ou de manutenção - que pode impacto sobre a disponibilidade se
não for devidamente programado e controlado. Em tais casos, deve entrar em
contacto com SLM e equipe de gerenciamento de disponibilidade - que vai
negociar com os usuários de negócios /, muitas vezes usando o Service Desk
para efectuar esta papel, Concordar e agendar tais atividades.
4.6.6 Gestão do Conhecimento
É de vital importância que todos os dados e informações que podem ser úteis
para o futuro Operação de Serviço atividades são devidamente recolhidos,
armazenados e avaliados. Dados relevantes, métricos e informação deve ser
passada em cima da cadeia de gestão e de outro Serviço Ciclo de Vida fases
para que possa alimentar as camadas de conhecimento e sabedoria do
organização'S Serviço do Sistema de Gestão do Conhecimento, As estruturas
de que têm de ser definidas em Estratégia de Serviço e Serviço de Design e
refinado em Melhoria de Serviço Continuada (ver outro ITIL publicações nesta
série).
Repositórios chave da operação de serviço, que foram citados em outros

lugares, são a CMS ea BDEC, mas isso deve ser ampliado para incluir a
totalidade do Serviço de Operação das equipes e departamentos
"documentação, tais como operaçãos manuais, procedimentos manuais,
instrução de trabalhos, etc

4.6.7 Gerenciamento Financeiro para Serviços de TI
Operação de Serviço equipe deve participar e apoiar o global de TI

orçamentação e contabilidade sistema - E pode ser ativamente envolvidos em
qualquer carregamento sistema que podem estar no local.
Adequado planejamento é necessário para que despesas de capital (Capex) e

despesas operacionais (Opex) orçamento estimativas podem ser preparadas e
concordou em boa hora para atender os ciclos orçamentais.
O Gerente de Operação de Serviço também deve ser envolvido em regular, pelo

menos mensalmente, revers de despesas contra orçamentos - como parte do
orçamento de TI em andamento e contabilidade processo. Qualquer
irregularidade deve ser identificado e feito os ajustes necessários. Todas as
despesas comprometido deve passar pela organização de sistema de ordem de
compra, de modo que os compromissos podem ser acumulados e verificações
adequadas devem ser feitas em todos os bens recebidos para que as faturas e
pagamentos podem ser corretamente autorizado - ou discrepâncias investigadas
e corrigidas.
Deve notar-se que alguns propôs custar reduções por o negócio pode realmente
aumentar os custos de TI, ou pelo menos Custo unitários. Cuidados devem ser
tomados para garantir que a TI está envolvida na discussão de todas as
medidas de redução de custos e contribuir para as decisões globais. Gestão
Financeira é tratada em pormenor na publicação Estratégia de Serviço.
4.6.8 Gestão da Continuidade de Serviço de TI
Funções de operação de serviços são responsáveis pelo teste e execução de

sistema e serviço recuperação planos, tal como determinado no TI Plano de
Continuidade do Serviços para a organização. Além disso, os gerentes de todas
as funções de operação de serviço devem estar na equipe de Coordenação de
Negócios Continuidade Central.
Isto é discutido em detalhe na estratégia de serviço e design de serviço e não

serão aqui repetidas, excepto para indicar que é importante que a operação de
serviço funçãos devem estar envolvidos nas seguintes áreas:
• Avaliação de risco, Usando seu conhecimento da infra-estrutura e

técnicas como a ACIA e acesso à informação no CMS para identificar
pontos únicos de falha ou outras de altarisco situações
• Execução de qualquer Gestão de Risco medidas que estão acordados,
por exemplo implementação de contramedidas, ou aumentada resiliência
para componentes das infra-estruturas, etc
• Assistência por escrito o real recuperação planos para sistemas e
serviços sob sua controlar

• Participação nos testes dos planos (tais como envolvimento em off-site de
testes etc simulações,) em uma base contínua, sob a direção do Gerente
de Continuidade dos Serviços de TI (ITSCM)
• Manutenção contínua dos planos sob o controle do GCSTI e Gestão da
Mudança
• Participação em campanhas de formação e sensibilização para garantir
que eles são capazes de executar os planos e compreender a sua papels
em um desastre
• O Service Desk irá desempenhar um papel fundamental na comunicação
com a equipe, clientes e usuários durante um desastre real

5 atividades operação comum Serviço
Capítulo 4 tratadas com os processos necessários para a eficaz Operação de
Serviço e no Capítulo 6, serão abordados os aspectos organizacionais. Este
capítulo se concentra em um número de operacional actividades que assegurem
que a tecnologia está alinhado com o Serviço geral e Processo objetivos. Essas
atividades são às vezes descritos como processos, mas na realidade são
conjuntos de atividades técnicas especializadas todas destinadas a garantir que
a tecnologia necessária para entregar e suportar serviços está a funcionar de
forma eficaz e eficiente.
Estas actividades serão geralmente de natureza técnica - embora a tecnologia

exacta irá variar de acordo com o tipo de serviço a ser entregues. Esta
publicação incidirá sobre as atividades necessárias para gerenciar TI.
Nota importante na gestão de tecnologia
É tentador separar o conceito de Serviço de Gestão de da gestão da infra-

estrutura que é utilizada para prestar esses serviços.
Na realidade, é impossível alcançar qualidade serviços sem alinhamento e

'engrenagens' cada nível de tecnologia (e as pessoas que a gerenciam) para os
serviços que estão sendo prestados. Serviço de Gestão envolve pessoas,
processo e tecnologia.
Em outras palavras, as atividades de operação comum de serviço não são sobre

o gerenciamento da tecnologia para a questão de ter boa tecnologia atuação.
Eles estão sobre a realização de desempenho que irá integrar a componente de
tecnologia com as pessoas e componentes de processo alcançar serviço e
objetivos de negócio. Veja a Figura 5.1 para exemplos de como a tecnologia é
gerido em organizações de maturação.

Figura 5.1 atingir a maturidade em Gestão de Tecnologia
Figura 5.1 ilustra as etapas envolvidas no amadurecimento de uma tecnologia

centrada organização a uma organização que utiliza a tecnologia como parte de
sua estratégia de negócios. Figura 5.1 ainda descreve o papel de Gestores de
Tecnologia em organizações de diferentes maturidade. O diagrama não é
abrangente, mas fornece exemplos da forma em que a tecnologia é gerido em
cada tipo de organização. Os títulos em negrito indicam o papel importante
desempenhado pela TI na gestão de tecnologia. O texto nas linhas descreve as
características de um departamento de TI em cada nível.
A finalidade deste diagrama neste capítulo é como se segue:
• Este capítulo centra-se na Gestão Técnica actividades, mas não há

nenhum modo simples de os representar. A organização menos madura
tende a ver essas atividades como fins em si mesmos, e não um meio
para um fim. Uma organização mais madura tenderá a subordinar essas
atividades para nível superior Serviço de Gestão de objetivos. Por
exemplo, a Servidor Equipa de gestão vai passar de um departamento
isolado, focada exclusivamente no gerenciamento de servidores, para

uma equipe que trabalha em conjunto com outros gerentes de tecnologia
para encontrar formas de aumentar o seu valor para o negócio.
• Para fazer e reforçar o ponto de que não há nenhuma maneira "certa" de
agrupar e organizar os departamentos que realizam esses serviços.
Alguns leitores podem interpretar os títulos neste capítulo como os nomes
dos departamentos, mas este não é o caso. O objetivo deste capítulo é
identificar as atividades típicas técnicos envolvidos na Operação de
Serviço. Aspectos organizacionais são discutidas no Capítulo 6.
• As atividades de serviço de operação descritas no restante deste capítulo
não são típicos de qualquer um dos níveis de maturidade. Em vez disso,
as atividades são geralmente tudo presente de alguma forma em todos os
níveis. Eles só estão organizadas e geridas de forma diferente em cada
nível.
Em alguns casos, um grupo dedicado pode lidar com todos de um processo ou

atividade enquanto em outros casos de processos ou atividades podem ser
compartilhadas ou dividir entre os grupos. No entanto, por meio de orientações
gerais, as seções a seguir listam as atividades necessárias sob os grupos
funcionais mais provável de ser envolvido em sua operação. Isso não significa
que todas as organizações têm de usar essas divisões. Organizações menores
tendem a atribuir grupos de essas atividades (se eles são necessários em todos)
para os departamentos individuais, ou mesmo indivíduos.
Finalmente, o objetivo deste capítulo não é fornecer uma análise detalhada de

todas as atividades. Eles são especializados, e orientação detalhada está
disponível a partir dos fornecedores de plataformas e outros, mais técnicos,
quadros, novas categorias serão adicionadas continuamente como a tecnologia
evolui. Este capítulo simplesmente tem como objetivo destacar a importância ea
natureza da gestão de tecnologia para o gerenciamento de serviços de TI no
contexto.

5,1 Monitoramento e controle
A medição e controlar de serviços é baseado em um ciclo contínuo de
monitoramento, Relatórios e ações posteriores. Este ciclo é discutido em
detalhes nesta seção porque é fundamental para a prestação de suporte e
melhoria dos serviços.
É também importante notar que, embora o ciclo tem lugar durante a operação de
serviço, que fornece a base para a fixação estratégia, Projeto e testes de
serviços e alcançar a melhoria significativa. É também a base para a medição
SLM. Portanto, apesar de controlo é realizada por operação de serviço funçãos,
que não deve ser visto como uma forma puramente operacional assunto. Todas
as fases do Serviço Ciclo de Vida devem assegurar que as medidas e controles
estão claramente definidos e executados, e colocada em prática.
5.1.1 Definições
Refere-se a monitorização da atividade de observar uma situação para detectar

mudanças que ocorrem ao longo do tempo.
No contexto do Operação de Serviço, Isto implica o seguinte:
• Usando ferramentas para monitorar o estado de CIs chave e principais

atividades operacionais
• Assegurar condições especificadas forem satisfeitas (ou não atingida) e,
se não, para levantar um alertar para o grupo apropriado (por exemplo, a
disponibilidade de dispositivos de rede chave)
• Assegurar que o atuação ou a utilização de um componente ou sistema
está dentro de um intervalo especificado (espaço em disco, por exemplo,
ou a utilização de memória)
• Para detectar tipos anormais ou níveis de actividade na infra-estrutura
(por exemplo, o potencial segurança ameaças)
• Para detectar alterações não autorizadas (por exemplo, introdução de
software)
• Para garantir observância com a organização'S políticas (por exemplo,
uso inadequado de e-mail)
• Para acompanhar as saídas para o negócio e garantir que eles se
encontram qualidade e desempenho exigências
• Para rastrear qualquer informação que é usado para medir Key
Performance Indicators (KPIs).
Relatórios refere-se à análise da produção e distribuição de saída do

monitoramento atividade.
No contexto do Operação de Serviço, Isto implica o seguinte:

• Usando ferramentas para agrupar a saída de monitoramento a
informação que pode ser disseminada a vários grupos, funções ou
processos
• Interpretar o significado dessa informação
• Determinar onde essa informação poderia ser melhor utilizados
• A garantia de que os tomadores de decisão têm acesso às informações
que lhes permitam tomar decisões
• Encaminhamento das informações transmitidas para o apropriado
pessoa, grupo ou ferramenta.
Controlar refere-se ao processo de administrar a utilização ou o comportamento

de um dispositivo, sistema ou serviço. É importante notar, no entanto, que
simplesmente manipulando um dispositivo não é o mesmo que para a controlar.
Controle exige três condições:
• A ação deve assegurar que o comportamento está de acordo com um

padrão definido ou norma
• As condições levando a ação deve ser definida, entendida e confirmada
• A ação deve ser definido, aprovado e adequado para estas condições.
No contexto do Operação de Serviço, Controle implica o seguinte:
• Usando ferramentas para definir quais as condições que representam

normais operaçãos ou operações anormais
• Regular o desempenho de dispositivos, sistemas ou serviços
• Medir disponibilidade
• Iniciar ações corretivas, o que pode ser automatizado (por exemplo,
reiniciar um dispositivo remotamente ou executar um script) ou manual
(por exemplo, notificar a equipe de operações do estado).
5.1.2 Controle Loops monitor
O mais comum modelo para a definição de controle é o Monitor de Controle de

Loop. Apesar de ser um modelo simples, tem muitos complexos aplicaçãos
dentro IT Service Management. Esta seção irá definir os conceitos básicos do
modelo de malha de controle Monitor e seções irá mostrar o quão importante
esses conceitos são para o Serviço de Gestão de Ciclo de Vida.

Figura 5.2 a malha de controle do monitor
Figura 5.2 descreve os princípios básicos de controle. Uma única atividade e a

sua produção são medidos utilizando uma norma pré-definida, ou padrão, Para
determinar se ela está dentro de um intervalo aceitável de atuação ou qualidade.
Se não, são tomadas medidas para corrigir a situação ou para restaurar
desempenho normal.
Normalmente existem dois tipos de Malhas de Controle do Monitor:
• Open Loop Sistemas destinam-se a efectuar uma específica atividade

independentemente das condições ambientais. Por exemplo, um apoio
pode ser iniciada em um determinado momento e frequência - e será
executado independentemente de outras condições.
• Sistemas de circuito fechados monitorar uma ambiente e responder às
mudanças nesse ambiente. Por exemplo, no balanceamento de carga de
rede um monitor irá avaliar o tráfego em um circuito. Se o tráfego de rede
excede um determinado intervalo, o controlar sistema vai começar a rota
de tráfego através de um circuito de backup. O monitor vai continuar a
fornecer feedback para o sistema de controlo que vai continuar a regular
o fluxo de tráfego de rede entre os dois circuitos.

Para ajudar a esclarecer a diferença, resolvendo Gerenciamento da Capacidade
através de excesso de provisionamento é de malha aberta, um balanceador de
carga que detecta congestão /falha e capacidade de redirecionamentos é de
circuito fechado.
5.1.2.1 Controlo de Monitor Complexo Laço
O Monitor de Controle de Loop na Figura 5.2 é uma boa base para a definição
de como Gestão de Operações obras, mas dentro do contexto de ITSM, a
situação é muito mais complexa. A Figura 5.3 ilustra um processo composto por
três atividades principais. Cada um tem uma entrada e uma saída, e a saída
torna-se uma entrada para a actividade seguinte.
Neste diagrama, cada atividade é controlada pelo seu próprio loop Monitor de
controle, usando um conjunto de normas para que a atividade específica. O
processo como um todo também tem a sua própria malha de controle Monitor,
que abrange todas as atividades e garante que todas as normas sejam
adequadas e estão sendo seguidas.
Figura 5.3 Malha de Controle Complexo do Monitor
Na Figura 5.3 há um ciclo de feedback de casal. Um ciclo se concentra

exclusivamente na execução de um determinado padrão, E o segundo avalia o

atuação do processo, e também os padrões em que o processo é executado.
Um exemplo disto seria se o primeiro conjunto de laços de realimentação, na
parte inferior do diagrama representado estações individuais de uma linha de
montagem e o circuito de nível superior representada Garantia de Qualidade.
A malha de controle Complexo Monitor é uma boa ferramenta de aprendizagem

organizacional (como definido por Chris Argyris, (1976) Aumentar a eficácia da
liderança. Nova Iorque: Wiley). O primeiro nível de feedback no nível de
atividade indivíduo está preocupado com monitoramento e respondendo aos
dados (fatos individuais, códigos ou peças de informação). O segundo nível está
preocupado com a monitorização e resposta à informação (uma coleção de uma
série de fatos sobre os quais uma conclusão pode ser desenhada). Consulte o
Transição de Serviço publicação para um debate aprofundado sobre dados,
informações, conhecimento e sabedoria.
Tudo isso é teoria interessante, mas não explica como o Monitor conceito de
controle de loop pode ser usado para operar De serviços de TIs. E
especialmente - que define a norma? Com base no que foi descrito até agora,
Malhas de Controle do monitor pode ser usado para gerenciar:
• O atuação de atividades em um processo ou procedimento. Cada

actividade ea sua saída relacionado pode potencialmente ser medido
para assegurar que problemas com o processo são identificados antes do
processo como um todo é concluída. Por exemplo, em Gerenciamento de
Incidentes, O Service Desk monitora se uma equipe técnica aceitou um
incidente em um tempo especificado. Se não, o incidente é escalado. Isto
é feito antes de o alvo bem resolução tempo para que o incidente porque
o objectivo de escalada que uma actividade é o de assegurar que o
processo no seu conjunto é completado em tempo.
• O eficácia de um processo ou procedimento como um todo. Neste caso,
o 'atividade'Caixa representa todo o processo como uma única entidade.
Por exemplo, a Gestão da Mudança irá medir o sucesso do processo,
verificando se um mudar foi implementada em tempo, para especificação
e dentro orçamento.
• O atuação de um dispositivo. Por exemplo, a caixa de "atividade"
poderia representar o tempo de resposta de um servidor sob uma dada
carga de trabalho.
• O desempenho de uma série de dispositivos. Por exemplo, a
extremidade usuário tempo de resposta de um aplicação através da rede.
Para definir como utilizar o conceito de Monitor de Controle de Loops em Serviço

de Gestão de, As seguintes perguntas devem ser respondidas:
• Como podemos definir o que precisa ser monitorado?

• Quais são os adequados limiars para cada um deles?
• Como será monitoramento ser realizada (manual ou automático)?

• O que representa normais operação?
• Quais são as dependências para o funcionamento normal?
• O que acontece antes de se chegar a entrada?
• Com que freqüência deve a medição ocorrer?
• Será que precisamos para realizar medição ativa para verificar se o item
está dentro da norma ou vamos esperar até que uma exceção é relatado
(medição passiva)?
• É Gestão de Operações a única função que realiza um
acompanhamento?
• Se não, como são as outras instâncias de monitoramento relacionados à
Gestão de Operações?
• Se houver múltiplos loops, que são responsáveis por processos cada
loop?
As seções seguintes irão expandir o conceito de Malhas de Controle do Monitor

e demonstrar como essas questões são respondidas.
5.1.2.2 O ITSM Monitor de Controle Laço
Em ITSM, a malha de controle complexo Monitor pode ser representada como

mostrado na figura 5.4.

Figura 5.4 ITSM Monitor de Controle de Loop
Figura 5.4 pode ser utilizado para ilustrar o controlar de um processo ou de o

componenteé usado para entregar um serviço. Neste diagrama "atividade" a
palavra implica que ele se refere a um processo. Para aplicá-lo a um serviço,
uma "atividade" também poderia ser um "CI". Há um certo número de
características importantes na Figura 5.4:
• Cada atividade num Serviço de Gestão de processo (ou de cada

componente usado para fornecer um serviço) É monitorizada como parte
do Operação de Serviço processos. O operacional equipe ou
departamento responsável por cada atividade ou componente irá aplicar a
malha de controle do monitor, conforme definido no processo, E usando
as normas que foram definidos durante o Design de Serviços processos.
O papel da monitorização operacional e controlo é o de assegurar que o
processo ou o serviço funçãos exatamente como especificado, é por isso
que eles estão principalmente preocupados com a manutenção do status
quo.

• As normas e mecanismos de monitoramento e de controle são definidos
em Design de Serviços, mas eles são baseados no padrãos e
arquiteturas definido durante Estratégia de Serviço. Quaisquer alterações
ao organizaçãoEstratégia do Serviço, arquitetura, serviço carteiras ou
Exigência de Nível de Serviços vai precipitar mudanças para o que é
monitorado e como ele é controlado.
• O Monitor de Controle de Loops são colocados dentro do quadro do
sistema. Isto implica que a Estratégia de Serviço serão principalmente
executado por executivos de TI com o apoio do fornecedor gerente de
contass. Design de Serviços atua como ponte entre a Estratégia de
Serviço e Operação de Serviço e normalmente envolvem representantes
de todos os grupos. As atividades e controles geralmente será executado
pela equipe de TI (às vezes envolvendo usuários) e apoiada por gerentes
de TI e os fornecedores. Melhoria de Serviço abrange todas as áreas,
mas principalmente representa os interesses da empresa e seus
usuários.
• Observe que o segundo nível de monitoramento neste loop complexo
Monitor de controle é realizado por meio de processos de CSI Estratégia
de Serviço e Design de Serviço. Estes relaçãos são representadas pelas
setas numeradas na figura 5.4, como segue:
• Seta 1. Neste caso CSI tem reconhecido que o serviço será
melhorada através de uma mudar à Estratégia de Serviço. Isto
poderia ser o resultado da necessidade de uma mudança de
actividade para o Portfólio de Serviços, Ou que a arquitetura não
entregar o que era esperado.
• Arrow 2. Neste caso, os requisitos de nível de serviço precisam
ser ajustados. Pode ser que o serviço é muito caro, ou que o
configuração da infra-estrutura necessita de ser alterada para
melhorar atuação, Ou porque Gestão de Operações é incapaz de
manter o serviço qualidade na arquitetura atual.
• Seta 3. Neste caso, as normas especificadas em Design de
Serviços não estão a ser cumpridos. Isto poderia ser porque eles
não são apropriados ou executável, ou por causa de uma falta de
educação ou falta de comunicação. As normas ea falta de
observância precisam ser investigadas e as medidas tomadas para
corrigir a situação.
Transição de Serviço oferece um grande conjunto de freios e contrapesos

nestes processos. Fá-lo como se segue:
• De novos serviços, Transição de Serviço irá garantir que as arquiteturas

técnicas são adequadas e que os padrões operacionais de desempenho
pode ser executado. Este, por sua vez, irá garantir que as equipes de
serviço de operação ou departamentos são capazes de cumprir os
requisitos de nível de serviço.

• Para os serviços existentes, Gestão da Mudança irá gerenciar qualquer
uma das alterações que são necessárias, como parte de um controle (por
exemplo, afinação), Assim como quaisquer alterações representadas
pelas setas marcadas 1, 2 e 3. Apesar de Transição de Serviço não
define estratégia e projeto serviços, por si só, fornece coordenação e
garantia de que os serviços estão funcionando e vai continuar a trabalhar,
como planejado.
Porque é que este circuito coberto Operação de Serviço?
Figura 5.4 representa Monitoramento e Controle para o conjunto da IT Service

Management. Alguns leitores da publicação operação de serviço pode sentir que
ele deve ser mais adequadamente abordados na publicação Estratégia de
Serviço.
No entanto, Monitoramento e Controle só pode ser efetivamente implantado

quando o serviço é operacional. Isto significa que o qualidade de todo o conjunto
de processos de Gerenciamento de Serviço depende de como eles são
monitorados e controlados de Operação de Serviço.
As implicações disso são as seguintes:
• Operação equipe de serviço não são as únicas pessoas com um

interesse no que é monitorado e como eles são controlados.
• Enquanto Operação de Serviço é responsável por monitoramento e
controlar de serviços e componentes, eles estão agindo como
administradores de uma parte muito importante do conjunto de laços de
ITSM Monitoramento e Controle
• Se a equipe da Operação de Serviço definir e executar Monitoramento e
Controle procedimentos isoladamente, nenhum dos processos de
Gerenciamento de Serviço ou funçãos só será plenamente eficaz. Isso
ocorre porque as funções de operação de serviço não vai apoiar as
prioridades e informações exigências de outros processos, por exemplo, a
tentativa de negociar um SLA quando os dados disponíveis apenas é a
página de swap as taxas em um servidor e a utilização da largura de
banda de uma rede detalhada.
5.1.2.3 definir o que precisa ser monitorado
A definição do que precisa ser monitorado é baseada no entendimento do

desejado resultado de um processo, dispositivo ou sistema. Deve concentrar-se
no serviço e os seus impacto sobre o negócio, e não apenas os componentes
individuais de tecnologia. A primeira pergunta que precisa ser feita é "O que
estamos tentando alcançar? '.
5.1.2.4 Monitoramento Interno e Externo e Controle

No início, torna-se claro que existem dois níveis de controlo:
• Monitoramento e Controle Interno: A maioria das equipes ou

departamentos estão preocupados com a possibilidade de executar com
eficácia e eficiência as tarefas que foram atribuídas a eles. Por isso, eles
vão monitorar os itens e atividades que estão diretamente sob seu
controle. Este tipo de monitoramento e controle se concentra em
atividades que são auto-contido que a equipe ou departamento. Por
exemplo, a Service Desk Gerente vai monitorar o volume de chamadas
para determinar como muitos funcionários precisam estar disponíveis
para atender o telefone.
• Monitoramento e controle externo: Embora cada equipe ou
departamento é responsável por gerenciar sua própria área, eles não
agem de forma independente. Cada tarefa que eles executam, ou
dispositivo que eles conseguem, tem um impacto sobre o sucesso da
organização como um todo. Cada equipe ou departamento também vai
estar controlando itens e atividades em nome de outros grupos,
processos ou funçãos. Por exemplo, a Servidor Equipa de gestão vai
monitorar a CPU atuação em servidores principais e executar carga de
trabalho equilibrar, de modo que um crítico aplicação é capaz de
permanecer dentro de desempenho limiars definido pelo Aplicação de
Gestão de.
A distinção entre o controlo interno e externo é um passo importante. Se

Operação de Serviço incide apenas sobre monitoramento interno, que terá infra-
estrutura muito bem gerida, mas não há maneira de entender ou influenciar o
qualidade de serviços. Se ele se concentra apenas no monitoramento externo,
ele vai entender o quão pobre a serviço qualidade é, mas não tem idéia do que
está causando isso ou como mudar isso.
Na realidade, a maioria das organizações têm uma combinação de controlo

interno e externo, mas em muitos casos estes não estão ligados. Por exemplo, a
equipe de gerenciamento de servidor sabe exatamente o quão bem os
servidores estão executando as tarefas eo Nível de Serviço Gerente sabe
exatamente como os usuários percebem a qualidade do serviço prestado pelos
servidores. No entanto, nenhum deles sabe como ligar esses métricos para
definir qual o nível de desempenho do servidor representa a boa qualidade
serviço. Isso se torna ainda mais confuso quando o desempenho do servidor
que é aceitável no meio do mês, não é aceitável no final do mês.
5.1.2.5 Definir objectivos para monitoramento e controle
Muitas organizações começar por perguntar a pergunta "O que estamos a

gestão? '. Isso leva invariavelmente a um monitoramento interno forte Sistema,
Com ligação muito pouco para o real resultado ou serviço que é exigido pela
empresa.

A pergunta mais apropriada é "Qual é o resultado final das atividades e
equipamentos que a minha equipa consegue? '. Portanto, o melhor lugar para
começar, ao definir o que monitorar, é determinar o resultado necessário.
A definição de Monitoramento e Controle objetivos devem, idealmente, começar

com a definição da Exigência de Nível de Serviçosdocumentos (ver Design de
Serviços publicação). Estes irão especificar como o clientes e usuários vai medir
o desempenho do serviço, e são utilizados como entrada para os processos de
design de serviço. Durante Design de Serviços, vários processos irá determinar
como o serviço será entregue e gerenciado. Por exemplo, a Gerenciamento da
Capacidade vai determinar a forma mais adequada e econômica para entregar
os níveis de desempenho exigidos. Gerenciamento de Disponibilidade vai
determinar a forma como a infra-estrutura pode ser configurado para
proporcionar o menor número de pontos de falha.
Se houver qualquer dúvida sobre a validade ou integridade de objectivos, a

COBIT framework fornece uma abrangente, conjunto de alto nível dos objectivos
como uma lista de verificação. Mais informações sobre o COBIT é fornecido no
Apêndice A desta publicação.
O Processo de Design de Serviços irá ajudar a identificar os seguintes conjuntos

de insumos para a definição Operacional Monitoramento e Controle de normas e
mecanismos:
• Eles vão trabalhar com clientes e usuários para determinar como a saída
do serviço será medido. Isso irá incluir mecanismos de medição,
freqüência e amostragem. Esta parte do Design de Serviços incidirá
especificamente sobre os requisitos funcionais.
• Eles vão identificar CIs chave, como devem ser configurados e qual o
nível de desempenho e disponibilidade é necessária, a fim de cobrir a
Nível de Serviços.
• Eles vão trabalhar com os desenvolvedores e fornecedores da CEI que
compõem cada serviço para identificar quaisquer restrições ou limitações
naqueles componentes.
• Todo apoio e equipes de entrega e departamentos terão de identificar
quais informações irá ajudá-los a executar seu papel eficazmente. Parte
do Design de Serviços e desenvolvimento será instrumento cada serviço
para que ele possa ser controlado para fornecer essas informações, ou
para que possa gerar significativo eventos.
Tudo isso significa que uma parte muito importante de definir o que Operação de
Serviço monitores e como ela exerce o controle é identificar a das partes
interessadass de cada serviço.
As partes interessadas podem ser definidos como qualquer pessoa com

interesse na entrega e recepção de sucesso De serviços de TIs. Cada ator terá

uma perspectiva diferente do que vai demorar para entregar ou receber um
serviço de TI. Operação de Serviço precisa entender cada uma dessas
perspectivas, a fim de determinar exatamente o que precisa ser monitorado eo
que fazer com a saída.
Operação de Serviço, portanto, dependem de SLM para definir exatamente

quem são essas partes interessadas e como elas contribuem ou usar o serviço.
Isso é discutido com mais detalhes no design de serviço e publicações Melhoria
de Serviço Continuada.
Nota sobre Objetivos de monitoramento interno e externo
O requerido resultado pode ser interno ou externo à Operação de Serviço

funçãos, embora deva ser sempre lembrado que uma ação interna, muitas
vezes, ter um resultado externo. Por exemplo, a consolidação servidors para
torná-los mais fáceis de administrar pode resultar numa custar poupança, o que
afetará a negociação e SLM rever ciclo, bem como o Gestão Financeira
processos.
5.1.2.6 Tipos de monitoramento
Existem muitos tipos diferentes de monitoramento ferramenta e situações

diferentes em que cada um deles será utilizado. Esta seção focaliza alguns dos
diferentes tipos de controlo que podem ser realizadas e quando seria adequado.
Monitoramento ativa versus passiva
• Monitoramento ativo refere-se à "interrogação" contínuo de um dispositivo

ou sistema para determinar a sua estado. Esse tipo de monitoramento
pode ser recurso intensivo e é geralmente reservado para monitorar
proativamente o disponibilidade de dispositivos ou sistemas críticos, ou
como um passo de diagnóstico quando se tenta resolver um incidente ou
diagnosticar um problema.
• Monitoramento passivo é mais comum e refere-se a geração e
transmissão de eventos de um "dispositivo de escuta", ou agente de
monitoramento. Monitoramento passivo depende de definição bem
sucedida de eventos e instrumentação do sistema a ser monitorizados
(ver secção 4.1).
Reativa contra Proactive
• Acompanhamento reactivo é projetado para solicitar ou desencadear uma

acção na sequência de um certo tipo de evento ou falha. Por exemplo,
servidor, atuação degradação pode desencadear um reboot, ou uma falha
do sistema irá gerar uma incidente. Monitoramento reativo não é usado
somente para exceções. Ele também pode ser usado como parte da

operação normal procedimentos, por exemplo, um trabalho em lotes é
concluída com êxito, o que leva o sistema de agendamento para enviar o
trabalho próximo lote.
• Monitoramento proativo é usado para detectar os padrões de eventos,
que indicam que um sistema ou serviço pode estar prestes a falhar.
Proactive monitoramento é geralmente usado em mais madura
ambientes, onde estes padrões têm sido detectados anteriormente,
muitas vezes, por várias vezes. Ferramentas de monitoramento pró-ativo
são, portanto, um meio de automatizar a experiência da equipe de TI
experiente e muitas vezes são criadas através do Gerenciamento de
Problemas pró-ativa processo (Ver publicação Melhoria de Serviço
Continuada).
Por favor, note que o monitoramento reativo e proativo pode ser ativo ou
passivo, conforme a Tabela 5.1:
Ativo Passiva
Reativo Usado para diagnosticar qual Detecta e correlaciona evento registros

dispositivo está causando o falha e em para determinar o sentido da eventos ea
que condições ("ping" por exemplo, um ação apropriada (por exemplo, um usuário
dispositivo, ou executar e acompanhar faz em três vezes com a senha incorreta, o
uma amostra transação através de que gera representa um segurança
uma série de dispositivos) exceção e é escalado por Gestão de
Segurança da Informação procedimentos)
Requer conhecimento da infra-
estrutura e topografia do mapeamento Requer conhecimento detalhado do normal
dos serviços a instituições de crédito operação da infra-estrutura e serviços
Proactive Utilizado para determinar o tempo real Os registros de eventos são

estado de um dispositivo, sistema ou correlacionados ao longo do tempo para
serviço - geralmente por crítica construir tendências para Gerenciamento
componentes ou após a recuperação de Problemas pró-ativa.
de um dispositivo falhou para garantir
que ele está totalmente recuperado Padrões de eventos são definidos e
(isto é, não vai causar novos programados em ferramentas de
incidentes) correlação para futuro reconhecimento
Reativa Tabela 5.1 Ativo e Passivo e monitoramento proativo
Medição contínua versus exceção baseada em Medição
• Medição Contínua é focado em monitoramento um sistema em tempo

real para assegurar que ele está em conformidade com a atuação norma
(por exemplo, um aplicação servidor está disponível para 99,9% do
acordado horas de serviço). A diferença entre a medição e monitorização
contínua e ativa é que o monitoramento ativo não tem que ser contínuo.
No entanto, como com a monitorização activa, isto é recurso intensivo e é
geralmente reservado para componentes críticos ou serviços. Na maioria
dos casos, o custar da largura de banda e poder de processamento

superior ao benefício de medição contínua. Nestes casos, um controlo
será normalmente por amostragem e análise estatística (por exemplo, o
desempenho do sistema é relatada a cada 30 segundos e extrapolados
para representar o desempenho global). Nestes casos, o método de
medição deverá ser documentado e acordado nos OLAs para garantir que
ela é adequada para suportar os requisitos de informação de serviço (ver
Melhoria de Serviço Continuada publicação).
• Exceção Baseado Medição não mede o desempenho em tempo real de
um serviço ou sistema, mas detecta e relatórios com exceções. Por
exemplo, um evento é gerado se a transação não for concluída, ou se um
desempenho limiar é atingido. Este é mais rentável e mais fácil de medir,
mas pode resultar em mais serviço interrupções. Medição exceção
Baseado é usado para sistemas menos críticos ou em sistemas onde
custar é uma questão importante. Também é utilizado em instrumentos de
TI não são capazes de determinar o estado ou qualidade de um serviço
(Por exemplo, se a qualidade de impressão faz parte da serviço
especificação, A única maneira de medir esta é a inspecção física -
muitas vezes realizada pelo usuário em vez de a equipe de TI). Onde
Medição Excepção-Based é usado, é importante que tanto o OLA ea SLA
para esse serviço refletir isso, como interrupções de serviço são mais
prováveis de ocorrer, e os usuários são muitas vezes obrigados a
comunicar a exceção.
Desempenho versus saída
Há uma distinção importante entre o relatório usado para rastrear a atuação de

componentes ou equipes ou departamento usado para fornecer um serviço e os
relatórios usados para demonstrar a realização do serviço qualidade objetivos.
Os gerentes de TI muitas vezes confundem estes relatando ao negócio sobre o

desempenho de suas equipes ou departamentos (por exemplo, número de
chamadas atendidas por Service Desk Analista), como se isso fosse a mesma
coisa que qualidade de serviço (por exemplo, incidentes resolvidos no prazo
acordado).
Monitoramento de Desempenho e métricos deve ser usado internamente pelo

Serviço de Gestão de para determinar se as pessoas, processo e tecnologia
estão funcionando corretamente e com o padrão.
Usuários e clientes preferiria ver relatórios relacionados com a qualidade e

desempenho do serviço.
Embora Operação de Serviço está preocupado com os dois tipos de

comunicação, a principal preocupação desta publicação é de monitoramento de
desempenho, enquanto monitoramento de Qualidade de Serviço (ou com base

em resultados de Monitoramento) será discutido em detalhe no Melhoria de
Serviço Continuada publicação.
5.1.2.7 Monitoramento em ambientes de teste
Tal como acontece com qualquer Infraestrutura de TI, Um Ambiente de Teste

terá de definir como vai utilizar a monitorização e controlar. Estes controlos são
mais completamente discutidos na Transição de Serviço publicação.
• Monitorar o ambiente de teste em si: Um ambiente de teste consiste de

infra-estrutura, aplicaçãos e processos que têm de ser geridos e
controlados como qualquer outro ambiente. É tentador pensar que o
ambiente de teste não precisa de rigoroso monitoramento e controle,
porque não é um viver ambiente. No entanto, este argumento não é
válido. Se um ambiente de teste não está devidamente monitorizado e
controlado, existe o perigo de executar os testes no equipamento que se
desvia da padrãos definidos no Design de Serviços.
• Itens de monitoramento que está sendo testado: Os resultados dos
testes têm de ser rigorosamente controladas e verificadas. Também é
importante que as ferramentas de monitoramento que foram construídas
em serviços novos ou modificados têm de ser testados também.
5.1.2.8 Relatórios e ação
"Um relatório sozinho cria a consciência, um relatório com um plano de ação

alcança resultados.
Relatórios e disfunçãofunção
A experiência prática tem mostrado que há mais informação nas organizações

disfuncionais do que em organizações eficazes. Isto é porque os relatórios não
estão sendo usados para iniciar pré-definida de ação planos, mas sim:
• transferir a culpa para um incidente

• para tentar descobrir quem é o responsável por tomar uma decisão
• como entrada para a criação de planos de ação para futuras ocorrências.
Nas organizações disfuncionais uma série de relatórios que são produzidos

ninguém tem tempo para olhar ou consulta.
Monitoramento sem controlar é irrelevante e ineficaz. O monitoramento deve ser

sempre, para evitar que serviço e operacional objetivos estão sendo atendidas.
Isso significa que, a menos que haja um objetivo claro para monitoramento um
sistema ou serviços, que não devem ser monitorizados.

Isso também significa que quando a vigilância é definida, também deve
quaisquer ações necessárias. Por exemplo, ser capaz de detectar que uma
grande aplicação falhou não é suficiente. A equipe de gestão competente
aplicativo também deve ter definido as etapas exatas que vai levar quando o
aplicativo falha.
Além disso, deve também ser reconhecido que essa acção pode ter de ser
tomada por pessoas diferentes, por exemplo, um único evento (tal como uma
aplicação falha) Pode desencadear a acção da Aplicação de Gestão de equipa
(para restaurar serviço), os usuários (para iniciar o processamento manual) e de
gestão (para determinar como esta evento pode ser evitado no futuro).
As implicações disto princípio são descritos em mais pormenor em relação às

Gestão de Eventos (Ver secção 4.1).
5.1.2.9 auditorias Operação de Serviço
Regular auditars devem ser realizados com o Operação de Serviço processos e

atividades para garantir:
• Estão a ser realizados como pretendido

• Não há evasão
• Eles ainda são apto para o efeito, Ou para identificar eventuais alterações
ou melhorias.
Gerentes de operação de serviço pode optar por realizar auditorias si, mas o
ideal é alguma forma de elemento independente das auditorias é preferível.
O organização'S interno de TI equipe de auditoria ou departamento pode ser

solicitado a se envolver ou algumas organizações podem optar por participar de
terceiros consultoria / auditoria /avaliação empresas de modo que um perito vista
totalmente independente é obtido.
Auditorias operação de serviço fazem parte da avaliação contínua que ocorre

como parte de Melhoria de Serviço Continuada e são discutidos em mais
detalhes na publicação.
5.1.2.10 Medição, métricas e KPIs
Esta seção tem como foco principal o monitoramento e controle como base para
a operação de serviço. Outras seções da publicação ter coberto alguns básicos
métricos que podem ser usados para medir a eficácia e eficiência de um
processo.
Embora esta publicação não é principalmente sobre medição e métricas, é

importante que as organizações que utilizam estes diretrizs têm técnicas de

medição robustos e métricas que suportam o objetivos dos seus organização.
Esta seção é um resumo desses conceitos.
Medição
Refere-se a medição de qualquer técnica que é utilizada para avaliar a extensão

ou dimensão capacidade de um artigo, em relação a um padrão ou a unidade.
• Refere-se a medida do grau de observância ou conclusão (por exemplo,

são todas as alterações formalmente autorizados pela autoridade
competente)
• Dimensão refere-se ao tamanho de um artigo, por exemplo, o número de
incidentes resolvidos pela Service Desk
• Refere-se a capacidade total capacidade de um artigo, por exemplo,
número máximo de padrão transaçãos que podem ser processados por
um servidor por minuto.
Medição só se torna significativa quando é possível medir a saída real ou

dimensões de um sistema,função ou processo contra um nível padrão ou
desejado, por exemplo, o servidor deve ser capaz de processar um mínimo de
100 operações padrão por minuto. Isso precisa ser definido em Design de
Serviço, e aperfeiçoado ao longo do tempo através Melhoria de Serviço
Continuada, Mas a medida em si acontece durante Operação de Serviço.
Métrica
Métricos referem-se ao quantitativo, periódica avaliação de um processo,

Sistema ou função, juntamente com a procedimentos e ferramentas que serão
usadas para fazer essas avaliações e os procedimentos para interpretá-los.
Esta definição é importante, porque não só especifica o que deve ser medido,
mas também a forma de medi-la, o que a faixa aceitável de desempenho será e
quais as medidas terão de ser tomadas como resultado do normal atuação ou
um. exceção A partir disto, é evidente que qualquer métrica dada na secção
precedente desta publicação é muito básica e terá de ser aplicado e expandido
dentro do contexto de cada organização antes que possa ser eficaz.
Indicadores Chave de Desempenho
Um KPI refere-se a um nível específico, acordado atuação que irão ser utilizados
para medir o eficácia de um organização ou processo.
KPIs são únicos para cada organização e têm de estar relacionadas a

determinadas entradas, saídas e atividades. Elas não são de natureza genérica
ou universal e, portanto, não foram incluídos nesta publicação.

Uma outra razão para não incluir a eles é o fato de que semelhante métricos
pode ser usada para atingir KPIs muito diferentes. Por exemplo, uma
organização utilizada a percentagem 'métrica de Incidentes resolvidos pela
Service Desk"Para avaliar o desempenho do Service Desk. Isso funcionou
efetivamente por cerca de dois anos, após o qual o gerente de TI começaram a
perceber que este KPI estava sendo usado para prevenir eficaz Gerenciamento
de Problemas, Ou seja, se, depois de dois anos, 80% de todos os incidentes são
fáceis o suficiente para ser resolvido em 10 minutos no primeiro chamar, Por que
não podemos chegar a uma solução para eles? Com efeito, o KPI agora tornou-
se uma medida de como ineficazes as equipes de Gerenciamento de Problemas
foram.
5.1.2.11 Interfaces para práticas de outros serviços do Ciclo de Vida
Monitoramento Operacional e Melhoria de Serviço Continuada
Esta secção tem incidido sobre Operacional Vigilância e informação, mas

monitoramento também constitui o ponto de partida para o Melhoria de Serviço
Continuada. Isso é abordado na publicação Melhoria de Serviço Continuada,
mas as principais diferenças são descritos aqui.
Qualidade é a chave objetivo de monitoramento para a Melhoria de Serviço

Continuada (MSC). O acompanhamento será, portanto, incidir sobre a eficácia
de um serviço, Processo, ferramenta de organização, ou CI. A ênfase não está
na garantia de desempenho em tempo real de serviços, mas sim que está em
identificar onde as melhorias podem ser feitas para o actual nível de serviço, ou
o desempenho de TI.
Monitoramento de CSI, portanto, tendem a se concentrar na detecção de

exceções e resoluçãos. Por exemplo, a CSI não é tão interessado em saber se
um incidente foi resolvido, mas se ele foi resolvido dentro do prazo acordado e
se incidentes futuros podem ser evitados.
CSI não é apenas interessado em exceções. Se um SLA é consistentemente

conheceu ao longo do tempo, CSI também estará interessado em determinar se
o nível de desempenho pode ser sustentado a um menor custar ou se ele
precisa ser atualizado para um nível ainda maior de desempenho. CSI pode,
portanto, também precisam ter acesso a relatórios de desempenho regulares.
No entanto, como CSI é improvável que precisa, ou ser capaz de lidar com as
enormes quantidades de dados que são produzidos por todo o
acompanhamento atividade, Eles vão se concentrar mais provável em um
subconjunto específico de monitoramento a qualquer momento. Isto pode ser
determinado através de uma entrada a partir da empresa ou melhorias à
tecnologia.

Isso tem duas implicações principais:
• Monitoramento de CSI vai mudar ao longo do tempo. Eles podem estar

interessados no acompanhamento do serviço de correio electrónico
quarto e depois passar a olhar para RH sistemas no próximo trimestre.
• Isto significa que, Operação de Serviço e CSI precisa construir um
processo que irá ajudá-los a chegar a acordo sobre que áreas precisam
ser monitoradas e para que finalidade.

5,2 Operações de TI
5.2.1 Management Console / Ponte de Operações
Estes fornecem um ponto de coordenação central para gerenciar várias classes

de eventos, a detecção de incidentes de rotina, gestão operacional atividades e
elaboração de relatórios sobre o estado ou atuação de tecnologia componentes.
Observação e monitoramento do Infraestrutura de TI pode ocorrer a partir de um

console centralizado - para o qual todos sistema eventos são roteados.
Historicamente, isto envolveu o acompanhamento do mestre operaçãos consola
de um ou mais computadores centrais -, mas hoje em dia é mais provável que
envolve um controlo de um servidor farm (s), dispositivos de armazenamento,
componentes de rede aplicaçãos, bases de dados ou qualquer outro CIs,
incluindo qualquer estrutura principal restante (s), a partir de um único local,
conhecido como o Operações Ponte.
Existem duas teorias sobre como o Operações Ponte foi assim chamado. Uma
delas é que ele se assemelha a ponte de um navio grande, automatizada (como
naves espaciais comumente visto em filmes de ficção científica). Outra teoria é
que a Operações Ponte representa uma ligação entre o Operações de TI
equipes e as tradicionais Help Desk. Em alguns organismos, isto significa que o
funçãos de Controle Operacional e do Help Desk foram incorporadas pela
Service Desk, Que realizou os dois conjuntos de funções em um único local
físico.
Independentemente da forma como foi nomeado, um Operações Ponte reunirá

todos os pontos de observação críticos na infra-estrutura de TI, para que
possam ser monitorados e gerenciados a partir de um local centralizado, com o
mínimo de esforço. Os dispositivos a ser monitorizado são susceptíveis de ser
fisicamente dispersos e podem estar localizados em instalações centralizadas
do computador ou dispersos no interior da usuário comunidade, ou ambos.
O Operações Ponte vai combinar muitas atividades, que podem incluir

Management Console, manipulação de eventos, de primeira linha de
gerenciamento de rede, Job Scheduling e suporte out-of-hora (cobertura para o
Service Desk e / ou segunda linha de apoio grupos se eles não trabalham 24/7).
Em algumas organizações, o Service Desk é parte do Operações Ponte.
A localização física e layout de Ponte da operação deve ser cuidadosamente

projetado para oferecer a acessibilidade correta e visibilidade de todas as telas e
dispositivos pertinentes ao pessoal autorizado. No entanto, isso vai se tornar
uma área muito sensível, onde o acesso controlado e apertado segurança será
essencial.

Organizações menores não pode ter um físico Operações Ponte, Mas haverá
certamente ainda a necessidade de Management Console, geralmente
combinado com outras técnicas papels. Por exemplo, uma única equipe de
técnicos irá gerenciar a rede, servidores e aplicativos. Parte do seu papel será o
de monitorar os consoles para esses sistemas - muitas vezes usando consoles
virtuais, para que possam realizar o atividade a partir de qualquer localização.
No entanto, deve notar-se que estas consolas virtuais são ferramentas
poderosas e, se for usado em locais inseguros ou mais conexões a descoberto,
pode representar uma segurança significativa ameaça.
5.2.2 Job Scheduling
Operações de TI irá executar rotinas, consultas ou relatórios que lhe forem

delegadas, como parte dos serviços de entrega, ou como parte da rotina de
limpeza delegada pelo técnico e Aplicação de Gestão de equipes.
Job Scheduling envolve a definição e início de pacotes de software de

agendamento de tarefas para executar em lote e em tempo real de trabalho. Isto
normalmente envolvem diária, semanal, mensal, anual e horários ad hoc para
atender às necessidades de negócio.
Além da primeira projetoOu redesenho periódica, dos horários, não são

susceptíveis de ser frequentes alterações ou ajustes para fazer, durante o qual
as dependências de trabalho têm de ser identificados e acomodados. Haverá
também um papel a desempenhar na definição alertars e Relatório de Exceçãos
para ser usado para monitoramento/ Verificar horários de trabalho. Gestão da
Mudança desempenha um papel importante na avaliação e validação de
grandes mudanças de horários, bem como a criação de Mudança Padrão
procedimentos para mais mudanças de rotina.
Tempo de execução parâmetros e / ou arquivos têm que ser recebidos (ou

acelerada se atrasado) e de entrada - e todos os logs em tempo de execução
tem que ser verificado e qualquer falhas identificadas.
Se as falhas ocorrem, em seguida, re-runs terá que ser iniciado, sob a

orientação da apropriadas unidade de negócioss, muitas vezes com diferentes
parâmetros ou dados alterados / arquivo versãos. Isso vai exigir comunicações
cuidadosos para garantir parâmetros corretos e arquivos são usados.
Muitas organizações se deparam com crescentes horários lote durante a noite

que pode, se superado o slot lote durante a noite, negativamente impacto sobre
os serviços on-line dia - assim estão buscando maneiras de utilizar máxima
durante a noite capacidade e atuação, Em conjunto com Gerenciamento da
Capacidade. Isto é onde Workload Técnicas de gestão podem ser úteis, tais
como:

• Re-agendamento de trabalho para evitar a disputa em dispositivos
específicos ou em momentos específicos e melhorar global rendimento
• Migração de cargas de trabalho para plataformas alternativas /ambientes
para ganhar um melhor desempenho e / ou produtividade (capacidades
de virtualização de fazer isso muito mais viável, permitindo a migração,
dinâmico automatizado)
• Sincronismo cuidadoso e "intercalação" de postos de trabalho para
ganhar o máximo aproveitamento dos disponíveis recursos.
Anedota
Um grande organização, Que foi confrontado com superação lote / utilização

problemas, identificou que, devido à natureza humana onde as pessoas estavam
procurando ser 'arrumado', todos os trabalhos estavam sendo iniciado na hora
ou menos 15 minutos de intervalo durante a hora (ou seja, n horas, 15 minutos
passado, passado meia, de 15 minutos a, etc.)
Ao re-agendamento de trabalho para que ele começou logo outro trabalho

terminado, e cambaleando os tempos de início de outro trabalho, ele foi capaz
de obter reduções significativas na disputa e conseguir o processamento muito
mais rápido em geral, que se resolveu a sua problemas, sem a necessidade de
atualizações.
Job Scheduling tornou-se um sofisticado atividade, Incluindo qualquer número

de variáveis - tais como tempo-sensibilidade, dependências críticas e não
críticas, balanceamento de carga de trabalho, falha e encaminhar, etc Como
resultado, a maioria operaçãos contar com ferramentas que permitem Job
Scheduling Operações de TI para agendar trabalhos para o melhor uso da
tecnologia para alcançar Nível de Serviço Objetivos.
A mais recente geração de ferramentas de programação permite um único

conjunto de ferramentas para agendar e automatizar as atividades técnicas e
Serviço de Gestão de processo atividades (como o agendamento de mudança).
Embora esta seja uma boa oportunidade para melhorar eficiência, Representa
também um maior ponto único de falha. As organizações que utilizam esse tipo
de ferramenta, portanto, ainda usam soluções pontuais como agentes e também
como um apoio no caso de o conjunto de ferramentas principal falhar.
5.2.3 Backup e Restauração
Faça backup e Restaurar É, essencialmente, um componente do bem De

serviços de TI Planejamento da Continuidade. Como tal, Design de Serviços
deve assegurar que existem sólidas estratégias de backup para cada serviço e
Transição de Serviço deve garantir que estas sejam devidamente testados.

Além disso, o regulador exigências especificar que certos tipos de organização
(Tais como serviços financeiros ou empresas cotadas) deve ter um backup
formal e Restaurar estratégia no lugar e que esta estratégia é executado e
auditados. Os requisitos exatos variam de país para país e por setor da
indústria. Isso deve ser determinado durante Design de Serviços e construído na
funcionalidade do serviço e documentação.
O único ponto de fazer backups é que eles podem precisar de ser restaurado em
algum ponto. Por esta razão, não é tão importante para definir como fazer uma
sistema -se como é para definir quais componentes estão em risco e como
efetivamente mitigar esse risco.
Há um sem número de ferramentas disponíveis para backup e restauração, mas

é importante notar que as características de tecnologias de armazenamento
usados para dados corporativos estão sendo utilizados para backup / restore
(instantâneos, por exemplo). Há, portanto, um aumento do grau de integração
entre as atividades de backup e restauração e as de armazenamento e
arquivamento (ver secção 5.6).
5.2.3.1 backup
Dados da organização tem que ser protegido e isso vai incluir backup (cópia) e
armazenamento de dados em locais remotos, onde pode ser protegidos - e
usado deveria precisam ser restaurados, devido à corrupção, perda ou
implementação de TI Plano de Continuidade do Serviços.
Uma estratégia de backup global deve ser acordado com o negócio,

abrangendo:
• Que dados tem de ser apoiada ea freqüência e periodicidade a ser usado.

• Quantas gerações de dados têm de ser conservados - isto pode variar de
acordo com o tipo de dados que está sendo feito o backup, ou que tipo de
arquivo (por exemplo, arquivo de dados ou aplicação executável).
• O tipo de backup (completo, parcial, progressiva) e pontos de controlo a
serem utilizados.
• Os locais a serem utilizadas para o armazenamento (que podem incluir
desastre recuperação locais) e horários de rotação.
• Métodos de transporte (por exemplo, a transferência de arquivos através
da rede, transporte físico em mídia magnética).
• Testes / verificações a serem realizadas, como teste-lê, teste
restaurações, verificar-somas etc
• Objetivo do ponto de recuperação. Isto descreve o ponto para o qual os
dados serão restaurados após a recuperação de uma De serviços de TI.
Isto pode envolver a perda de dados. Por exemplo, um Objetivo do ponto
de recuperação de um dia pode ser suportado por apoios diários, e até 24
horas de dados podem ser perdidos. Objetivos do ponto de recuperação

para cada serviço de TI deve ser negociado, acordado e documentado
em Olas, SLAs e UCs.
• Objetivo Tempo de recuperação. Isso descreve o tempo máximo
permitido para a recuperação de um serviço de TI após uma interrupção.
O Nível de Serviço a ser fornecida pode ser menor do que o normal Alvo
de Nível de Serviços. Objetivos de tempo de recuperação para cada
serviço de TI deve ser negociado, acordado e documentado em Olas,
SLAs e UCs.
• Como verificar se o apoios vai funcionar se eles precisam ser restaurard.
Mesmo se não houver erro códigos gerados, pode haver vários motivos
para o backup não podem ser restaurados. Um bom backup estratégia e
operaçãosprocedimentos irá minimizar o risco de que isso aconteça. Faça
backup procedimentos devem incluir uma verificação passo para garantir
que os backups estão completos e que vai funcionar se uma restauração
é necessária. Onde qualquer backup falhas são detectados, recuperação
ações devem ser iniciadas.
Há também uma necessidade de adquirir e gerir os meios necessários (discos,

fitas, CDs, etc) que serão utilizadas para backups, de modo que não há
escassez de oferta.
No caso de dispositivos automatizados estão a ser utilizados, de pré-

carregamento dos meios de comunicação necessários irá ser necessária
previamente. Ao carregar e limpar mídia retornados de fora do local de
armazenamento, é importante que haja um procedimento para verificar se estes
são os corretos. Isso impedirá que o backup mais recente é escrito com dados
defeituosos, e depois de não ter dados válidos para restaurar. Depois de
backups bem-sucedidos foram tomadas, a mídia deve ser removido para o
armazenamento.
O início real dos backups podem ser automatizados, ou realizada a partir da

Operações Ponte.
Algumas organizações podem utilizar equipe de operações para realizar o

transporte físico e trasfega de cópias de backup de / para locais remotos, onde,
em outros casos, esta pode ser entregues a outros grupos, como interna
segurança funcionários ou prestadores de serviços externos.
Se os backups estão sendo automatizados ou executadas remotamente, em

seguida, recursos de monitoramento de eventos devem ser considerados para
que eventuais falhas podem ser detectadas precocemente e corrigidos antes
que eles causem problemas. Em tais casos Operações de TI tem um papel a
desempenhar na definição alertars e escalada caminhos.
Em todos os casos, a equipe de TI Operações devem ser treinados em backup

(e restauração) procedimentos - que deve ser bem documentado na

organização'S operações de TI Manual de Procedimentos. Qualquer específica
exigências ou metas deve ser referenciado em UCs OLAs ou se for o caso,
enquanto qualquer usuário ou cliente exigências ou atividade deve ser
especificado no apropriado SLA.
5.2.3.2 Restaurar
A restauração pode ser iniciada a partir de um número de fontes, que vão desde
um evento que indica a corrupção de dados, através de um Solicitação de
Serviço de um usuário ou cliente logado no Service Desk. A restauração poderá
ser necessária no caso de:
• Dados corrompidos
• Dados perdidos
• A recuperação de desastres /De serviços de TI Situação de continuidade
• Dados históricos requerido para a investigação forense.
As medidas a serem tomadas irão incluir:
• Localização dos dados apropriados / mídia

• Transporte ou transferência de volta para o físico recuperação localização
• Acordo no ponto de recuperação checkpoint e no local específico para os
dados recuperados (disco, diretório, etc pasta)
• Restauração real do arquivo / dados (cópia de segurança e qualquer roll-
back/roll-forward necessário para chegar ao posto de controle concordou
• Verificação para garantir a conclusão do restaurar - Com mais
recuperação ação se necessário até que o sucesso foi alcançado.
• Usuário /cliente sign-off.
5.2.4 impressão e de saída
Muitos serviços consistem em gerar e fornecer as informações em forma

impressa ou eletrônica. Garantir a informação certa chegue às pessoas certas,
com total integridade, Requer formais controlar e gestão.
Impressão (física) e de saída (eletrônica) instalações e serviços precisam ser

formalmente conseguiu porque:
• Eles muitas vezes representam a saída tangível de uma serviço. A

capacidade de medir que esta saída atingiu o destino adequado, é muito
importante (por exemplo, se a verificação de arquivos com financeira
transação dados realmente chegaram a um banco através de um serviço
FTP)
• Produção física e eletrônica, muitas vezes contém informações sensíveis
ou confidenciais. É vital que os níveis adequados de segurança são
aplicados tanto a geração como o fornecimento deste produto.

Muitas organizações terão impressão em massa centralizada exigências que
Operações de TI deve lidar.
Além da carga física e re-carregamento de papel ea operação e cuidados das

impressoras, outras actividades podem ser necessários, tais como:
• Acordo e definição de pré-notificação de impressão grande roda e alertars

para evitar a impressão excessiva de trabalhos de impressão desonestos
• Controle físico de alto valor papelaria, como cheques de empresas ou
certificados, etc
• Gestão do armazenamento físico e electrónico necessário para gerar a
saída. Em muitos casos, vai ser obrigado a fornecer arquivos para os
materiais impressos e eletrônicos
• Controle de todo o material impresso, de modo a aderir a legislação de
protecção de dados e, por exemplo regulação HIPAA (Health Insurance
Portability e Accountability Act) no EUA, Ou FSA (Financial Services
Authority) na Reino Unido.
Quando os serviços de impressão e de saída são entregues diretamente para o

usuários, é importante que a responsabilidade pela manutenção das
impressoras ou dispositivos de armazenamento é claramente definida. Por
exemplo, a maioria dos usuários assumem que a limpeza e manutenção de
impressoras deve ser realizada por TI. Se este não é o caso, isso deve ser
claramente indicado no SLA.

5.3 Gestão Mainframe
Mainframes ainda são amplamente utilizados e ter bem estabelecido e maduro
práticas. Mainframes formar o centro componente de muitos serviços e seus
atuação , portanto, definir um linha de base para as expectativas de
desempenho do serviço e do usuário ou cliente, embora nunca pode saber que
eles estão usando o mainframe.
As formas em que as equipes de gestão de mainframe são organizadas são

bastante diversificadas. Em alguns Gestão Mainframe organizações é uma
equipe única, altamente especializada, que gerencia todos os aspectos das
operações diárias através de sistema engenharia. Em outras organizações, as
atividades são realizadas por várias equipes ou departamentos, com engenharia
e terceiro nível de apoio a ser prestado por uma equipe e por dia operaçãos a
ser combinado com o resto da Operações de TI (E muito provavelmente gerida
através do Operações Ponte).
Normalmente, as seguintes atividades deverão ser realizadas:
• Operacional de mainframe sistema manutenção e suporte

• Terceiro nível de suporte para todos os incidentes relacionados /
mainframeproblemas
• Escrevendo roteiros de trabalho
• A programação do sistema
• Interface com suporte de hardware (H / W); arranjar manutenção,
concordando slots, identificando H / W falha, Ligação com H / W
engenharia.
• Prestação de informações e assistência aos Gerenciamento da
Capacidade para ajudar a alcançar o melhor rendimento, Utilização e
atuação do mainframe.

5,4 Management Server e suporte
Servidors são usados na maioria das organizações de prestação de serviços
flexíveis e acessíveis de hospedagem aplicaçãos ou bancos de dados,
executando cliente/ Servidor de serviços, armazenamento de impressão e
gerenciamento de arquivos. Gestão bem-sucedida de servidores é, portanto,
essencial para o sucesso Operação de Serviço.
O procedimentos e as atividades que devem ser realizadas pela Equipe Server

(s) ou serviço (s) - equipes separadas podem ser necessárias nos casos em
servidor diferente tipos são usados (UNIX, Wintel etc) - incluem:
• Suporte de sistema operacional: De suporte e de manutenção do

sistema operacional apropriado (s) e, relativamente utilidade software
(software de failover, por exemplo), incluindo gerenciamento de patches e
envolvimento na definição apoio e restaurar políticas.
• Gerenciamento de licença para todos os itens de configuração do
servidor, não especialmente sistemas operacionais, utilitários e software
aplicativo gerenciado pelas equipes de gerenciamento de aplicativos.
• Terceiro nível de suporte: Terceiro nível de suporte para todos os
servidores e / ou servidor do sistema de operação relacionadas com
incidentes, incluindo diagnóstico e recuperação actividades. Isso também
irá incluir a ligação com terceiros contratados para suporte a hardware e /
ou fabricantes como necessário para escalar hardware incidentes
relacionados.
• Conselho aquisições: Aconselhamento e orientação para o negócio da
seleção, dimensionamento, aquisição e uso de servidores e software
utilitário relacionado para atender às necessidades de negócio.
• Sistema segurança: Controle e manutenção dos controles de acesso e
permissões dentro do servidor relevante ambiente(S), bem como sistema
adequado e de medidas de segurança física. Que incluem a identificação
e aplicação de patches de segurança, Gerenciamento de Acesso (Ver
secção 4.5) e intrusão detecção.
• Definição e gestão de servidores virtuais. Isto implica que qualquer
servidor que tenha sido projetada e construída em torno de um comum
padrão pode ser usado para processo carga de trabalhos de uma gama
de aplicações ou usuários. Management Server será necessário para
definir esses padrões e, em seguida, garantir que as cargas de trabalho
são devidamente equilibrado e distribuído. Eles também são responsáveis
por ser capaz de controlar a carga de trabalho que está sendo
processado por que servidor de modo que eles são capazes de lidar com
incidentes de forma eficaz.
• Capacidade e desempenho: Fornecer informações e assistência aos
Gerenciamento da Capacidade para ajudar a alcançar o melhor
rendimento, Utilização e atuação dos servidores disponíveis. Isto é
discutido em mais detalhe na Design de Serviços, Mas inclui o

fornecimento de orientações sobre, e instalação e operação de, o
software de virtualização de modo a alcançar valor para o dinheiro
obtendo os mais altos níveis de desempenho e de utilização de um
número mínimo de servidores.
• Outro atividades de rotina incluem:
o Definição de padrão construirs para os servidores como parte do
provisionamento processo. Isso é abordado com mais detalhes em
Design de Serviços e Transição de Serviço
o Construção e instalação de novos servidores como parte de
manutenção contínua ou para a prestação de novos serviços. Isto
é discutido em mais detalhe na Transição de Serviço
o Clusters de criação e gestão, que visam a construção de
redundância, Melhorando o desempenho do serviço e fazer a infra-
estrutura mais fácil de gerenciar.
• Manutenção contínua. Isso normalmente consiste na substituição de
servidores ou "lâminas" em uma programação de rolamento para garantir
que o equipamento é substituído antes de falhar ou se torna obsoleto.
Isso resulta em servidores que não são apenas totalmente funcional, mas
também capaz de suportar serviços em evolução
• Desmantelamento e eliminação de equipamento servidor antigo. Isso
geralmente é feito em conjunto com o organizaçãoPolíticas ambientais "s
para eliminação.

5,5 Gerenciamento de Rede
Como a maioria De serviços de TIs são dependentes de conectividade,
gerenciamento de rede será essencial para oferecer serviços e também para
permitir Operação de Serviço pessoal para acessar e gerenciar serviço chave
componentes.
Gerenciamento de rede terá a responsabilidade global para toda a organização

próprias redes locais (LANs), Metropolitan Area Networks (MANs) e redes de
área ampla (WAN) - e também será responsável pelos contactos com terceiros
rede fornecedors.
Seu papel irá incluir as seguintes atividades:
• Inicial planejamento e instalação de novas redes / componentes de rede,

manutenção e upgrades para a infra-estrutura de rede física. Isto é feito
através do Design de Serviços e Transição de Serviço.
• Terceiro nível de suporte para todas as atividades relacionadas à rede,
incluindo a investigação de problemas de rede (por exemplo, ping ou
rastreamento de rota e / ou utilização de ferramentas de software de
gerenciamento de rede - embora deva ser notado que o ping de um
servidor não significa necessariamente que o serviço está disponível! ) de
ligação e com terceiros, se necessário. Isto também inclui a instalação e
utilização de "ferramentas" farejadores, que analisam o tráfego de rede,
para ajudar na incidente e problema resolução.
• Manutenção e suporte operacional de rede sistema e middleware
incluindo software de gerenciamento de patches, upgrades, etc
• Monitoramento de tráfego de rede para identificar falhas ou de detectar
potencial atuação ou questões gargalo.
• Reconfigurar ou desvios de tráfego para alcançar melhor rendimento ou
saldo massa - definição de regras para o balanceamento dinâmico /
roteamento.
• Rede segurança (Em articulação com o organização'S Gestão de
Segurança da Informação), incluindo acesso de firewall, gestão direitos,
Proteção de senha etc
• Atribuição e gerenciamento de endereços IP, sistemas de nome de
domínio (DNSs - que convertem o nome de um serviço para seu
endereço IP associado) e Dynamic Host Configuration Protocol (DHCP)
de sistemas, que permitem o acesso e uso dos DNS.
• Gerenciando Provedor de Serviços de Internets (ISPs).
• Execução, monitoramento e manutenção de Sistemas de Detecção de
Intrusão em nome de Gestão de Segurança da Informação. Eles também
serão responsáveis por assegurar que não há negação de serviço para
legitimar usuários da rede.
• Atualizando Gerenciamento da Configuração se necessário,
documentando CIs, estado,relaçãos, etc

Gerenciamento de rede também é muitas vezes responsável, muitas vezes em
conjunto com o suporte de desktop, por questões de conectividade remota, tais
como discagem, dial-back e instalações VPN prestados a casa de trabalho, os
trabalhadores remotos ou fornecedors.
Algumas equipes de gerenciamento de rede ou departamentos também terá a

responsabilidade de voz / telefonia, incluindo o fornecimento e apoio ao
intercâmbio, linhas, ACD, pacotes de software estatísticos etc, e para Voice over
Internet Protocol (VoIP) e de monitoramento remoto (RMON) sistemas.
Ao mesmo tempo, muitas organizações ver VoIP e telefonia como áreas

especializadas e têm equipes dedicadas ao gerenciamento desta tecnologia. As
suas actividades serão semelhantes aos descritos acima.
Nota sobre o gerenciamento de VoIP como serviço
Muitas organizações têm experimentado atuação e disponibilidade problemas

com a sua VoIP soluções, apesar do facto de que não parece ser mais do que a
largura de banda disponível suficiente. Isso resulta em queda de chamadas e
som pobres qualidade. Isso geralmente é devido a variações na utilização da
largura de banda durante o chamar, O que é frequentemente o resultado da
utilização da rede por outros utilizadores, aplicaçãos ou outro web atividade. Isto
levou à diferenciação entre a medição da largura de banda disponível para
iniciar uma chamada (serviço de acesso de banda - ou SAB) e a quantidade de
largura de banda que deve ser continuamente disponível durante a chamada
(serviço de banda Utilization - ou SUB). Cuidados devem ser tomados na
diferenciação entre estes quando projetar, gerenciar e medir os serviços de
VoIP.

5,6 Armazenamento e Arquivo
Muitos serviços exigem o armazenamento de dados por um tempo específico e
também para que os dados estejam disponíveis off-line por um determinado
período após ele não é mais usado. Este é muitas vezes devido a regulamentar
ou legislativo exigências, mas também porque a história e auditar dados são
valiosos para uma variedade de finalidades, incluindo o produto de marketing,
desenvolvimento, Investigações forenses, etc
A equipe separada ou departamento pode ser necessária para gerir a

organizaçãoA tecnologia de armazenamento de dados, tais como:
• Dispositivos de armazenamento, como discos, controladores, fitas, etc

• Network Attached Storage (NAS), que é de armazenamento conectado a
uma rede e acessível por vários clientes
• Armazenamento Area Networks (SAN) destinados a conectar dispositivos
de armazenamento de computador, tais como controladores de matriz de
disco e bibliotecas de fitas. Para além de dispositivos de armazenamento,
uma SAN vai exigir também a gestão de rede diversos componentes,
como hubs, cabos, etc
• Direct Attached Storage (DAS), o qual é um dispositivo de
armazenamento ligado directamente a um servidor
• Armazenamento de conteúdo endereçável (CAS), que é o
armazenamento que é baseado em recuperação de informação com base
no seu teor em vez de localização. O foco neste tipo de sistema é na
compreensão da natureza dos dados e informações armazenados, em
vez do que em proporcionar locais de armazenamento específicos.
Independentemente do tipo de sistemas de armazenamento estão sendo

utilizados, armazenamento e arquivamento vai exigir o gerenciamento dos
componentes da infra-estrutura, bem como as políticas relacionadas ao local
onde os dados são armazenados, por quanto tempo, de que forma e quem pode
acessá-lo. Responsabilidades específicas incluirão:
• Definição de políticas de armazenamento de dados e procedimentos

• Convenções de armazenamento de arquivos de nomenclatura, hierarquia
e as decisões de colocação
• Projeto, dimensionamento, seleção, aquisição, configuração e operação
de toda a infra-estrutura de armazenamento de dados
• Manutenção e suporte para todos utilidade e middleware de
armazenamento de dados de software
• Ligação com Informação Ciclo de Vida Gestão de equipe (s) ou Governo
equipes para garantir observância com a liberdade de informação de
protecção de dados, governança de TI e regulamentações
• Envolvimento com definição e acordo de arquivamento política

• Limpeza de todas as instalações de armazenamento de dados
• Arquivamento de dados de acordo com regras e horários definidos
durante Design de Serviços. As equipes de armazenamento ou
departamentos irá igualmente contribuir para a definição dessas regras e
irá fornecer relatórios sobre a sua eficácia como entrada para futuro
projeto
• Recuperação de dados arquivados que for necessário (por exemplo, para
fins de auditoria, a evidência forense, ou para atender a todos os
requisitos de outras empresas)
• Terceira linha de apoio para armazenamento e arquivamento de
incidentes relacionados.

5,7 Database Administration
Administração de banco de dados deve trabalhar em estreita colaboração com a
chave Aplicação de Gestão de equipes ou departamentos e em algumas
organizações a funçãos podem ser combinados ou ligados em uma única
estrutura de gestão. Opções organizacionais incluem:
• Administração de banco de dados que está sendo realizada por cada

equipe de Gerenciamento de Aplicativos para todos os aplicaçãos sob
seu controle
• Um departamento dedicado, que gerencia todas as bases de dados,
independentemente do tipo ou aplicação
• Vários departamentos, cada um gerenciando um tipo de banco de dados,
independentemente de qual aplicativo eles fazem parte.
Administração de banco de dados trabalha para garantir o melhor

atuação,segurança e funcionalidade de bancos de dados que gerenciam.
Administradores de banco de dados normalmente têm as seguintes
responsabilidades:
• Criação e manutenção de banco de dados padrãoe as políticas

• Banco de dados inicial projeto, Criação de testes,
• Gestão da base de dados disponibilidade e desempenho; resiliência,
Dimensionamento capacidade volumetria etc
• Resiliência pode exigir a replicação de banco de dados, que seria de
responsabilidade da Administração do Banco de Dados
• Administração contínua de objetos de banco de dados: tabelas, índices,
visões, restrições, seqüências de instantâneos e armazenados
procedimentos; bloqueios de página - para alcançar melhor utilização
• A definição de gatilhos que irão gerar eventos, que por sua vez irá alertar
administradores de banco de dados de desempenho ou potencial
integridade problemas com o banco de dados
• Execução de limpeza de banco de dados - as tarefas de rotina que
assegurem que os bancos de dados estão funcionando de forma
otimizada e segura, por exemplo, afinação, Indexação, etc
• Monitoramento de uso; transação volumes, tempo de respostas,
simultaneidade níveis, etc
• Geração de relatórios. Estes poderiam ser os relatórios com base nos
dados no banco de dados ou relatórios relacionados com o desempenho
ea integridade do banco de dados
• Relatórios de identificação e gestão de questões de segurança de banco
de dados; auditar trilhas e forenses
• Assistência na elaboração de banco de dados apoio, Arquivamento e
armazenamento estratégia
• Assistência na alertas dados concepção e gestão de eventos

• Prestação de terceiro nível de suporte de banco de dados para todos os
incidentes relacionados.

5,8 Diretório de Gestão de Serviços
AServiço de Diretório é um software especializado que gerencia informações
sobre o recursoEstá disponível em uma rede e quais os usuários têm acesso. É
a base para fornecer acesso a esses recursos e para garantir que o acesso não
autorizado é detectado e impedido (ver secção 4.5 para informações detalhadas
sobre Gerenciamento de Acesso).
Directory Services vê cada recurso como um objeto do Diretório Servidor e

atribui-lhe um nome. Cada nome está ligado ao endereço do recurso de rede, de
modo que usuários não tem que memorizar endereços confusos e complexos.
Directory Services é baseado em X.500 da OSI padrãos e comumente utiliza

protocolos como o Directory Access Protocol (DAP) ou Lightweight Directory
Access Protocol (LDAP). LDAP é utilizado para apoiar as credenciais do usuário
para aplicação login e muitas vezes inclui usuário interno e externo /cliente
dados que é especialmente bom para extranet chamar registro. Desde LDAP é
um crítico operacional ferramenta, e geralmente mantido até à data, também é
uma boa fonte de dados e verificação para o CMS.
Gestão de Serviços de Diretório refere-se ao processo que é usado para

gerenciar Directory Services. Suas atividades incluem:
• Trabalhando como parte de Design de Serviços e Transição de Serviço

para garantir que os novos serviços são acessíveis e controlados quando
eles são implantados
• Localização de recursos em uma rede (se não já foram definidos durante
Service Design)
• O acompanhamento do estado desses recursos e fornecendo a
capacidade de gerir esses recursos remotamente
• Gerenciando o direitos de específica usuários ou grupos de usuários para
acessar recursos em uma rede
• Definir e manter as convenções de nomenclatura para serem utilizados
para os recursos numa rede
• Assegurar a coerência de nomeação e acesso controlar em diferentes
redes do organização
• Ligando diferente Serviço de Diretórios em toda a organização para
formar um serviço de diretório distribuído, ou seja, os usuários só vai ver
um conjunto lógico de recursos de rede. Isso é chamado de Distribuição
de Serviços de Diretório
• Monitorando eventos sobre os Serviços de Diretório, como tentativas para
acessar um recurso, e tendo a ação apropriada quando necessário
• Manutenção e atualização das ferramentas utilizadas para gerenciar
Directory Services.

5,9 Desktop Support
Como a maioria o acesso de usuários De serviços de TIs usando computadores
desktop ou laptop, é fundamental que estes são suportados para garantir os
níveis acordados de disponibilidade e atuação de serviços.
Suporte de mesa terá a responsabilidade global para toda a área de trabalho da

organização e hardware de computador portátil, software e periféricos.
Responsabilidades específicas incluirão:
• Políticas de desktop e procedimentos, por exemplo, as políticas de

licenciamento, uso de laptops ou desktops para fins pessoais, USB
bloqueio, etc
• Projetando e concordando imagens de desktop padrão
• Área de trabalho de manutenção do serviço, incluindo desenvolvimento
de liberars, upgrades, patches e correções (hot-em conjunto com
Gerenciamento de Liberação (Ver publicação Transição de Serviço para
mais detalhes)
• Concepção e implementação de área de trabalho de arquivamento /
reconstruir política (Incluindo a política relativa aos cookies, favoritos,
modelos, dados pessoais, etc)
• Terceiro nível de suporte do ambiente de trabalho relacionados com
incidentes, incluindo mesa as visitas sempre que necessário
• Suporte para problemas de conectividade (em conjunto com o
gerenciamento de rede) para a casa de trabalho, o pessoal móvel, etc
• Controle de configuração e auditar de todos os equipamentos de área de
trabalho (em conjunto com Gerenciamento da Configuração e Auditoria
de TI).

5,10 Middleware Gestão
Middleware é um software que conecta ou integra software componentes em
todo distribuída ou díspar aplicaçãos e sistemas. Middleware permite a efetiva
transferência de dados entre aplicações, e é, portanto, fundamental para
serviços que dependem de vários aplicativos ou fontes de dados.
Uma variedade de tecnologias são atualmente usados para apoiar o programa

para programa de comunicação, como corretores de solicitação de objetos,
middleware orientado a mensagem, controle remoto procedimento chamadas e
serviços ponto-a-ponto web. Mais recentes tecnologias estão surgindo o tempo
todo, por exemplo Enterprise Service Bus (ESB), que permite que os programas,
sistemas e serviços para se comunicar uns com os outros, independentemente
da arquitetura e origem das aplicações. Isto é especialmente utilizado no
contexto da implantação Service Oriented Architectures (SOA).
Middleware Management pode ser realizada como parte de um Aplicação de

Gestão de função (Em que é dedicado a uma aplicação específica), ou como
parte de um Gestão Técnica função (onde ele é visto como uma extensão para o
sistema operacional de uma plataforma específica).
Funcionalidade fornecida pelo middleware inclui:
• Fornecer mecanismos de transferência de dados de várias aplicações ou

fontes de dados
• O envio de trabalho para outra aplicação ou procedimento para o
processamento
• Transmissão de dados ou informações para outros sistemas, tais como
dados de sourcing para publicação em sites (por exemplo, publicação de
Incidentes estado informação)
• Liberando atualizados módulos de software em todo distribuído ambientes
• Agrupamento e distribuição de mensagens do sistema e instruções, por
exemplo, eventos ou operacional scripts que precisam ser executados em
dispositivos remotos
• Configuração de multicast com redes. Multicast é a entrega de
informações a um grupo de destinos em simultâneo através da rota de
entrega mais eficiente
• Gerenciando tamanhos de fila.
Middleware Management é o conjunto de atividades que são usados para

gerenciar middleware. Estes incluem:
• Trabalhando como parte de Design de Serviços e Transição para garantir

que o apropriado middleware As soluções são escolhidas e que eles
possam desempenhar optimamente quando eles são implantados

• Garantir a correta operação de middleware através de monitoramento e
controlar
• Detecção e resolução de incidentes relacionados com middleware
• Manutenção e atualização de middleware, incluindo o licenciamento e
instalação de novo versãos
• Definir e manter informações sobre como aplicaçãos estão ligados
através de Middleware. Isso deve ser parte da CMS (ver Transição de
Serviço publicação).

5,11 Gestor da Internet / Web
Muitas organizações conduzir muito de seu negócio através da Internet e são,
portanto, fortemente dependente do disponibilidade e atuação de seus sites.
Nesses casos, uma equipe de suporte em separado Internet / Web ou
departamento será desejável e justificado.
As responsabilidades de uma equipe ou departamento de incorporar tanto

Intranet e Internet e é provável que incluem:
• Definindo arquiteturas para serviços de Internet e web

• O especificação de padrãos para desenvolvimento e gestão de aplicações
baseadas na web, conteúdo, sites e páginas da web. Este será
tipicamente feito durante Design de Serviços
• Design, testes, implementação e manutenção de websites. Isso irá incluir
a arquitetura de sites eo mapeamento de conteúdo a ser disponibilizado
• Em muitas organizações, o gerenciamento web irá incluir a edição do
conteúdo a ser postado na web
• Manutenção de todo o desenvolvimento web e gerenciamento de
aplicativos
• Ligação e conselhos para web-conteúdo equipes dentro da empresa. O
conteúdo pode residir em aplicativos ou dispositivos de armazenamento,
o que implica uma estreita ligação com Aplicação de Gestão de e outros
Gestão Técnica equipes
• Ligação e gestão de fornecedores dos ISPs, os anfitriões, o
monitoramento de terceiros ou de organizações de virtualização etc Em
muitas organizações os ISPs são gerenciados como parte de
Gerenciamento de Rede
• Terceiro nível de suporte para incidentes Internet-/web-related
• Suporte para interfaces com back-end e legado sistemas. Isso muitas
vezes significa trabalhar com os membros do Desenvolvimento de
Aplicações e equipas de gestão para garantir acesso seguro e
consistência de funcionalidade
• Monitoramento e gerenciamento de desempenho do site e incluindo:
testes de batimentos cardíacos, usuário simulação experiência, aferição,
On-demand de balanceamento de carga de virtualização,
• Site disponibilidade,resiliência e segurança. Isto fará parte do conjunto
Gestão de Segurança da Informação do organização

5,12 Instalações e Data Management Centre
Gestão de Instalações refere-se à gestão da física ambiente de Operações de
TI, Geralmente localizados nos centros de dados ou salas de informática. Esta é
uma área vasta e complexa e esta publicação irá fornecer uma visão geral de
sua chave papel e atividades. Uma visão mais detalhada está contida no Anexo
E.
Em muitos aspectos, Gestão de Instalações poderia ser visto como um função

em seu próprio direito. No entanto, por causa desta publicação está focada em
que as operações de TI estão alojados, cobrirá Facilities Management
especificamente no que se refere à gestão dos centros de dados e, como um
subconjunto da TI Gestão de Operações função.
O principal componentes de Gestão de Instalações são as seguintes:
• Gestão de Edifícios, Que refere-se à manutenção e conservação dos

prédios que abrigam o Centro de TI pessoal e de dados. As atividades
típicas incluem limpeza, eliminação de resíduos, gestão do
estacionamento e acesso controlar
• Equipamentos de hospedagem, O que garante que todo especial
exigências são fornecidos para a habitação física de equipamentos e as
equipes que os suportam
• Gerenciamento de energia, A qual refere-se a gerir o fornecimento e
utilização de fontes de energia que são utilizados para manter a unidade
funcional. Esta definição de gerenciamento de energia tem uma série de
implicações, que são discutidos no Apêndice E. Nota que as informações
sobre utilização de energia é importante para a planejamento o
capacidade de ambos os novos serviços e novas construções
• Condicionamento ambiental e Alertar Sistemas, Os quais incluem o
especificaçãoE manutenção monitoramento de sistemas como a detecção
de fumaça e combate a incêndios, de água, sistemas de aquecimento e
refrigeração, etc
• Segurança refere-se observância a toda a legislação, padrãos e políticas
em relação à segurança dos empregados
• Controle de Acesso Físico refere-se a assegurar que a instalação só é
acessado por pessoal autorizado e que qualquer acesso não autorizado é
detectado e gerenciado. Isto é discutido em mais detalhe no Apêndice F
• Envio e recebimento refere-se à gestão de todos os equipamentos,
móveis, correio, etc, que sai ou entra no edifício. Ele garante que somente
itens apropriados estão entrando ou saindo do prédio e que eles são
encaminhados para a festa correta
• Envolvimento em Gestão de Contratos dos vários fornecedors e provedor
de serviçoss envolvidas na instalação

• Manutenção refere-se a manutenção, regulares programadas da
instalação, bem como a detecção e resolução de problemas com a
facilidade.
Nota importante sobre os Centros de Dados
Centros de dados são geralmente unidades especializadas e, enquanto eles

usam e se beneficiar de genéricos disciplinas Facilities Management, eles
precisam se adaptar estes. Por exemplo aquecimento layout, e poder
condicionado, planejamento e muitos outros aspectos são geridos
exclusivamente em Centros de Dados.
Isto significa que, apesar de centros de dados pode ser detida por um
instalações organização, Eles são melhor geridas sob a autoridade do
Operações de TI, Embora possa haver uma linha de comunicação funcional
entre a TI eo departamento que gerencia outras facilidades para a organização.
5.12.1 Dados estratégias Centro
Gerenciando um Centro de Dados é muito mais do que hospedar um espaço

aberto onde grupos técnicos instalar e gerenciar equipamentos, utilizando as
suas próprias abordagens e procedimentos. Ela exige um conjunto integrado de
processos e procedimentos envolvendo todos os grupos de TI em todas as fases
do ITSM Ciclo de Vida. Centro de Dados operaçãos são regidas pela estratégico
e projeto decisões para o manejo e controlar e são executadas pelos
operadores. Isso exige uma série de fatores-chave a serem postas em prática:
• Dados Automação Centro. Automação especializado sistemas, que

reduzem a necessidade de operadores manual e que monitorar e
acompanhar o estado da instalação e todos Operações de TI sempre
• PolíticaGestão baseada em onde as regras de automação e recurso
alocação são geridos pela política, ao invés de ter que passar por
complexo mudar procedimentos de processamento a cada momento é
movido de um recurso para outro
• Serviços de tempo real 24 horas por dia, 7 dias por semana
• Normalização do equipamento. Isso proporciona maior facilidade de
gerenciamento, os níveis mais consistentes de atuação e um meio de
fornecimento de serviços múltiplos através de tecnologia semelhante.
Padronização também reduz a variedade de conhecimentos técnicos
necessários para gerir equipamentos no Centro de Dados e para fornecer
serviços
• SOAs, Onde o serviço componentes pode ser reutilizado, trocadas e
substituído muito rapidamente e sem impacto sobre o negócio. Isto
tornará possível para o Centro de Dados para ser altamente responsivo
em atender às demandas empresariais em constante mudança, sem ter
de passar pelo demorado e complicado re-engenharia e rearquitetura

• Virtualização. Isto significa que, De serviços de TIs são entregues
através de um conjunto em constante mudança de equipamentos,
voltados para atender a demanda atual. Por exemplo, um aplicativo pode
ser executado em um dispositivo dedicado juntamente com o seu banco
de dados durante a alta demanda vezes, mas mudou para um dispositivo
compartilhado com seu banco de dados em um dispositivo remoto não
durante horários de pico - tudo automatizado e automático. Isto significa
uma economia ainda maior de custars como qualquer equipamento pode
ser usado a qualquer momento, sem qualquer intervenção humana,
exceto para realizar a manutenção e substituição de equipamentos
falhou. O Infraestrutura de TI é mais resiliente porque qualquer
componente é apoiada por qualquer número de componentes
semelhantes, qualquer um dos quais pode ter mais de um componente
falha carga de trabalho automaticamente.
Remoto monitoramento,controlar e equipamentos de sistemas de gestão

e será essencial para gerenciar uma virtualizado ambiente, Como muitos
serviços não será ligada a qualquer uma peça específica do equipamento.
• Unificado sistema de gestãos tornaram-se mais importante como os

serviços são executados em vários locais e tecnologias. Hoje, é
importante definir que ações devem ser tomadas e que sistemas vai
executar essa ação. Isso significa investir em soluções que permitam aos
gerentes de infra-estrutura simplesmente especificar o que resultado é
necessário, e permitindo que o sistema de gestão para calcular a melhor
combinação de instrumentos por forma a atingir o resultado.

5,13 Gestão de Segurança da Informação e Operação de
Serviço
Gestão de Segurança da Informação como processo é abordado no ITIL Design
de Serviços publicação. Gestão de Segurança da Informação tem a
responsabilidade global para definição de políticas, padrãos e procedimentos
para assegurar a protecção da organização'S ativoss, dados, informações e De
serviços de TIs. Operação de Serviço equipes jogam um papel na execução
dessas políticas, normas e procedimentos e trabalhará em estreita colaboração
com as equipes ou departamentos responsáveis de Gestão de Segurança da
Informação.
Equipes de operação de serviço não pode tomar posse de Gestão de Segurança

da Informação, isso representaria um conflito. É preciso haver segregação de
funções entre os grupos de definir e gerir o processo e os grupos que executam
atividades específicas como parte do curso operação. Isso vai ajudar a proteger
contra violações de segurança medidas, como nenhum indivíduo deve ter
controlar ao longo de dois ou mais fases de um transação ou operação. Gestão
de Segurança da Informação deve atribuir responsabilidades para garantir uma
verificação cruzada de funções.
O papel das equipes de operação de serviço é descrito a seguir.
5.13.1 Policiamento e relatórios
Isso vai envolver a equipe Operação realizar atividades específicas de

policiamento, tais como a verificação de revistas, logs de sistema,
evento/monitoramento alertars etc, intrusão detecção e / ou relatórios de
violações de segurança reais ou potenciais. Isso é feito em conjunto com a
Gestão de Segurança da Informação para fornecer um sistema de verificação e
equilíbrio para garantir a detecção e gestão eficaz dos problemas de segurança.
Pessoal Operação de Serviço são muitas vezes primeiro a detectar eventos de

segurança e estão em melhor posição para ser capaz de desligar e / ou remover
o acesso a sistemas comprometidos.
Particular atenção será necessária no caso de organizações de terceiros que

requerem acesso físico à organização. Pessoal Operação de Serviço pode ser
obrigado a escoltar visitantes em áreas sensíveis e / ou controlar o seu acesso.
Eles também podem ter um papel a desempenhar no controle de acesso de rede

a terceiros, como mantenedores de hardware discando para fins de diagnóstico,
etc

5.13.2 Assistência técnica
Alguns suporte técnico pode precisar de ser fornecida para a equipe de TI de

Segurança para ajudar na investigação de incidentes de segurança e auxiliar na
produção de relatórios ou na coleta de provas forenses para uso em ação
disciplinar ou processos criminais.
Consultoria e assistência técnica também pode ser necessária em relação a

melhorias de segurança em potencial (por exemplo, a criação de firewalls
apropriadas ou acesso / senha controles).
O uso de evento, incidente,problema e gerenciamento de configuração

informação pode ser invocado para fornecer cronologias precisas de segurança
relacionados com as investigações.
5.13.3 controle de segurança operacional
Para operacional razões, o pessoal técnico, muitas vezes, precisa ter acesso
privilegiado às principais áreas técnicas (por exemplo, raiz sistema senhas, o
acesso físico aos dados Centros ou etc comunicações quartos). É, portanto,
essencial que controles adequados e auditar trilhas são mantidos de todas
essas atividades privilegiadas, de modo a prevenir e detectar qualquer
segurança eventos.
Controles físicos precisam estar no local para todas as áreas seguras com o
login-out de todos os funcionários. Onde terceiro funcionários ou visitantes
precisam de acesso, pode ser Operação de Serviço funcionários que são
responsáveis pela escolta e gerir o movimento desse pessoal.
No caso de sistemas de acesso privilegiado, isso precisa ser restrito a apenas

aquelas pessoas cuja necessidade de acessar o sistema foi verificado - e
retirado imediatamente quando essa necessidade não existe mais. Uma trilha de
auditoria deve ser mantida de quem tem acesso e quando teve, e de todas as
atividades realizadas com os níveis de acesso.
5.13.4 Seleção e habilitação
Todo o pessoal Operação de Serviço deverão ser avaliados e controlados a um

nível de segurança adequado ao organização em questão.
Fornecedors e de terceiros contratados também devem ser avaliados e

controlados - ambas as organizações e os específicos de pessoal envolvido.
Muitas organizações começaram a usar a polícia ou do governo de
antecedentes da agência, especialmente onde os contratantes estarão
trabalhando com sistemas de classificados. Sempre que necessário, as
organizações não-revelação e confidencialidade acordos deve ser acordado.

5.13.5 Treinamento e conscientização
Todo o pessoal Operação de Serviço deve ser dada formação regular e contínua
e consciência da organização do política de segurança e procedimentos. Este
deve incluir detalhes de medidas disciplinares no lugar. Além disso, a segurança
de qualquer exigências deve ser especificado no do empregado contrato de
emprego.
5.13.6 políticas e procedimentos documentados
Procedimentos de serviço de operação documentados deve incluir todas as

informações pertinentes relativas a questões de segurança - extraído da política
de segurança da organização geral documentos. Deve-se considerar a utilização
de manuais para auxiliar na obtenção das mensagens de segurança para todo o
pessoal relevante.

5,14 Melhoria das actividades operacionais
Todo o pessoal Operação de Serviço deve ser constantemente à procura de
áreas em que processo melhorias podem ser feitas para dar maior De serviços
de TI qualidade e / ou executados de forma mais rentável. Isto pode incluir
algumas das seguintes atividades.
5.14.1 automação de tarefas manuais
Quaisquer tarefas que têm de ser realizadas manualmente, particularmente

aqueles que têm de ser regularmente repetido, são susceptíveis de ser mais
demorada, dispendiosa e erro propensos do que os que podem ser
sistematizado e automatizado. Todas as tarefas devem ser examinados para
automação potencial para reduzir o esforço e custars e para minimizar os erros
potenciais.
A decisão deve ser feita na custars da automação e os prováveis benefícios que

irão ocorrer.
5.14.2 Rever atividades improvisadas ou procedimentos
Devido à natureza pragmática de Operação de Serviço, Que por vezes pode

surgir de que as atividades improvisadas ou processos são introduzidos para
resolver a curto prazo operacional expedientes. Existe o perigo de que tal
práticas pode ser continuado e tornar-se a "norma" - levando a ineficiências em
curso. Onde quaisquer atividades ou improvisados procedimentos tem de ser
introduzida, é importante que estas sejam revered, logo que a oportunidade
imediata é superar - e, ou suprimida ou substituída por processos eficientes
acordados para o prazo mais longo.
5.14.3 Auditorias Operacionais
Regular auditars deve ser conduzida de todos os processos de operação de

serviço para garantir que eles estão trabalhando de forma satisfatória.
5.14.4 Usando o Gerenciamento de Incidentes e de Problemas
Problema e Gerenciamento de Incidentes proporcionar uma fonte rica de

operacional oportunidades de melhoria. Esses processos são discutidos em
detalhe no capítulo 4 desta publicação.
5.14.5 Comunicação
Deve ir sem dizer que a boa comunicação sobre a mudança exigências, a

tecnologia e os processos resultará em melhoria na operação do serviço. No

entanto, a comunicação é muitas vezes negligenciada. Melhoria Operação
serviço é dependente da comunicação formal e regular entre as equipes
responsáveis pela projeto, Suporte e operação de serviços.
5.14.6 A educação ea formação
Equipes de operação de serviço deve compreender a importância do que fazem

em uma base diária. Educação é necessária para garantir que o pessoal
entender o que o negócio funçãos ou serviços são suportados por suas
atividades. Isso irá incentivar um maior cuidado e atenção aos detalhes e
também vai ajudar as equipes de operação do serviço, para melhor identificar as
prioridades de negócios.
Treinamento programas deve assegurar que todos os funcionários têm as

habilidades necessárias para a tecnologia ou aplicaçãos que eles estão
conseguindo. A formação deve ser sempre fornecida quando uma nova
tecnologia é introduzida, ou quando a tecnologia existente é alterado.

6 Organizador para Operação de Serviço
6.1 Funções
Afunção é um conceito lógico que se refere ao povo e medidas automatizadas
que executam um definido processo, Um atividade ou uma combinação de
processos ou atividades. Em organizações maiores uma função pode ser
dividida e executada por vários departamentos, equipes e grupos, ou pode ser
incorporado dentro de uma única unidade organizacional.
Figura 6.1 Funções de operação de serviço

A Operação de Serviço funçãos dado na Figura 6.1 são necessários para gerir o
"estado estável" operacional TI ambiente. Estas são funções lógicas e não
necessariamente tem que ser feita por uma estrutura equivalente organizacional.
Isto significa que a técnica e Aplicação de Gestão de podem ser organizados em
qualquer combinação e em qualquer número de departamentos. Os
agrupamentos de segundo nível na Figura 6.1 são exemplos de grupos típicos
de atividades realizadas por Gestão Técnica (Ver Capítulo 5) e não são uma
sugestão organização estrutura.
A seguir, um resumo das principais funções de Serviço de Operação na Figura

6.1:
• O Service Desk é o principal ponto de contato para usuários quando há

uma serviço interrupção, por solicitação de serviços ou até mesmo para
algumas categorias de Requisição de Mudança. O Service Desk fornece
um ponto de comunicação com os usuários e um ponto de coordenação
para vários grupos de TI e processos. Para habilitá-los para realizar essas
ações efetivamente o Posto de Serviço é normalmente separado dos
outros Funções de operação de serviço. Em alguns casos, por exemplo,
onde detalhada suporte técnico é oferecida aos usuários no primeiro
chamar, Pode ser necessário para a técnica ou Aplicação de Gestão de
equipe para estar no Service Desk. Isso não significa que o Service Desk
se torna parte de theTechnical função de Gestão. De fato, enquanto eles
estão no Service Desk, eles deixam de ser uma parte da gestão técnica
ou funções de gerenciamento de aplicativos e tornar-se parte do Service
Desk, mesmo que apenas temporariamente.
• Gestão Técnica fornece detalhadas habilidades técnicas e recursos
necessários para suportar o curso operação do Infraestrutura de TI.
Gestão Técnica também desempenha um importante papel no projeto,
Testes, liberar e melhoria das De serviços de TIs. Em pequenas
empresas, é possível gerenciar essa experiência em um único
departamento, mas as grandes organizações são normalmente dividida
em vários departamentos especializados tecnicamente (ver mais adiante
neste capítulo). Em muitas organizações, os departamentos de Gestão
técnicos são também responsáveis pela operação diária de um
subconjunto da infra-estrutura de TI. A Figura 6.1 mostra que, embora
sejam parte de um departamento de gestão técnica, funcionários que
realizam essas atividades são logicamente parte da função de
Gerenciamento de Operações de TI.
• TI Gestão de Operações é a função de responsável pela diária
operacional atividades necessárias para gerenciar a infra-estrutura de TI.
Isso é feito de acordo com o desempenho Padrãos definido durante
Design de Serviços. Em algumas organizações este é um departamento
único e centralizado, enquanto em outros algumas atividades e
funcionários são centralizados e alguns são fornecidos por departamentos
distribuídos ou especializada. Isto é ilustrado na Figura 6.1 pela

sobreposição de funções de gestão técnica e de aplicativos. Gestão de
Operações de TI tem duas funções que são únicas e que são geralmente
formais estruturas organizacionais. Estes são os seguintes:
• Operações de TI Controle, O qual é geralmente composta por
deslocars de operadores e que assegura que as tarefas rotineiras
operacionais são realizadas. Controle de Operações de TI também
irá fornecer centralizado monitoramento e controlar actividades,
geralmente usando uma Operações Ponte ou Centro de
Operações de Rede.
• Gestão de Instalações refere-se à gestão da TI física ambiente,
Geralmente centros de dados ou salas de informática. Em muitas
organizações Técnica e Gerenciamento de Aplicativos são co-
localizado com Operações de TI nos Centros de dados grandes.
Em algumas organizações muitas física componentes da
Infraestrutura de TI foram terceirizados e gestão de instalações
podem incluir a gestão do terceirização contratos.
• Aplicação de Gestão de é responsável pela gestão aplicaçãos ao longo
da sua ciclo de vida. O Gerenciamento de Aplicativos função suporta e
mantém operacional aplicações e também desempenha um importante
papel no projeto, Teste e aperfeiçoamento de aplicações que fazem parte
do De serviços de TIs. Gerenciamento de Aplicativos é geralmente
dividida em departamentos com base no portfólio de aplicativos do
organização (Veja os exemplos na figura 6.1), permitindo assim mais fácil
de especialização e de mais apoio focado. Em muitas organizações
departamentos de gestão de aplicativos têm funcionários que realizam
diariamente operaçãos para esses aplicativos. Tal como acontece com
Gestão Técnica, Esse pessoal logicamente parte do TI Gestão de
Operações função.
Nota especial sobre Gestão de Segurança da Informação
Embora a maioria concorda que a Gestão de Segurança da Informação é um

função, É altamente especializada e abrange diversas fases do ciclo de vida.
Também é responsável pela supervisão de muitas atividades dentro de tudo
Operação de Serviço funções. Para uma descrição mais aprofundada de Gestão
de Segurança da Informação, por favor consulte o Design de Serviços
publicação e de seção 5.13 desta publicação.
6.1.1 Funções e atividades
Capítulo 5 desta publicação introduziu uma série de atividades de operação

comum de serviço. Devido à natureza técnica e especialização dessas
atividades, as equipes, grupos ou departamentos que os executam são muitas
vezes recebem nomes que correspondem às atividades particulares. Por
exemplo, Gerenciamento de Rede pode ser realizado por um 'Departamento de
Gestão de Rede ". Isto, no entanto, é de modo nenhum uma regra. Há um

número de opções disponíveis no mapeamento atividades para uma equipe ou
departamento, por exemplo:
• Um atividade poderia ser realizada por várias equipes ou departamentos,

por exemplo, se uma organização tem cinco departamentos principais
aplicativos de apoio, cada um apoiando um conjunto diferente de
aplicativos, cada um destes departamentos pode executar a
Administração de banco de dados para aplicações de 'suas'
• Um departamento pode realizar várias actividades, como por exemplo do
Departamento de Gestão de Rede pode ser responsável pela gestão da
rede, Serviço de Diretórios Gestão e Servidor Gestão
• Uma actividade pode ser realizada, por exemplo, por grupos
Administração de Segurança pode ser realizada por qualquer pessoa com
a responsabilidade de gerir uma aplicação de servidor, middleware ou
desktop.
Estas decisões organizacionais são influenciadas por uma série de factores, tais
como:
• A dimensão e localização da organização. Menores, as organizações

menos distribuídos tendem a combinar essas funções, enquanto que
empresas grandes e descentralizadas pode ter várias equipes ou
departamentos realizando o mesmo atividade (Por exemplo, por região).
• A complexidade da tecnologia utilizada no organização. Quanto maior o
número de diferentes tecnologias utilizadas, o mais provável, há de ser
várias equipes diferentes, cada um fazendo algo semelhante, mas em um
contexto diferente (por exemplo, UNIX Servidor Gestão e de
gerenciamento do Windows Server).
• O disponibilidade de competências. Onde as habilidades técnicas são
escassos, é comum que as organizações usem generalistas para
executar vários grupos de atividades - embora, em alguns casos,
segurança considerações tornam isso muito difícil. Por exemplo, uma
organização que trabalha em classificados ou segredo projetos pode ter
que contratar caro, especializado recursos, mesmo quando isso significa
que realocá-los ou contratação através de segurança-Limpou
fornecedores.
• O cultura da organização. Algumas organizações preferem trabalhar em
altamente especializada ambientes, enquanto outros tendem a preferir a
flexibilidade da equipe generalista.
• A situação financeira da organização vai determinar quantas pessoas,
com que tipo de habilidade, pode ser empregada e como eles serão
organizados.
Como resultado desses fatores, é impossível para esta publicação para

prescrever uma estrutura organizacional adequada que vai caber a cada
situação, no entanto, as seções a seguir listam as atividades necessárias sob os

grupos funcionais mais propensos a se envolver em seu operação. Por favor,
note que isso não significa que todas as organizações têm de usar essas
divisões. Organizações menores tendem a combinar essas atividades em
departamentos individuais, ou mesmo indivíduos - se eles são mesmo
necessários em tudo.
Nota especial sobre terceirização
Estas considerações organizacionais tendem a ser mais relevante para as

organizações de TI internos. A situação se torna ainda mais complexa quando
parte ou a totalidade de uma determinada atividade ou função são terceirizados.
Excelentes oportunidades para a terceirização tem sido o Service Desk e
Operações de Rede. Isto será explicado em mais pormenor na ITIL Orientação
complementar, mas alguns dos pontos-chave para se lembrar são:
• Independentemente de quem está realizando o atividade, A empresa que

contrata o contratante ainda é responsável por garantir que ele é
realizado para uma padrão que irá apoiar a prestação de serviços aos
seus clientes e usuários.
• Terceirização para resolver de uma organização problemas ou como uma
alternativa ao bom Serviço de Gestão de processos raramente funciona.
Os melhores resultados são obtidos quando estes estão em vigor antes
da terceirização.
• Terceirização funciona melhor quando há o envolvimento ativo de ambas
as organizações. Se a equipe e gerentes da organização do cliente
desengatar, o contratante é improvável que seja bem sucedido,
simplesmente porque ninguém entende a organização melhor do que as
pessoas que trabalham lá.
• O contratante não deve determinar suas saídas ou como eles são
medidos. Estas são determinadas através da compreensão da empresa
exigências de usuários e clientes e garantir que eles possam ser
atendidas pelos recursos de que o contratante do.
• Embora os serviços que o contratante se tornam parte integrante do
organização, Eles ainda são uma organização de terceiros, com um
conjunto diferente de objetivo de negócios, políticas e práticas. Segurança
padrãos deve ser acolhida e ambas as partes devem entender claramente
seus respectivos papels e contribuições.

6,2 Service Desk
AService Desk é uma unidade funcional formada por um número específico de
pessoal responsável pelo tratamento de uma variedade de serviços eventos,
muitas vezes feita através de chamadas telefónicas, interface web, ou eventos
de infra-estrutura automaticamente notificados.
O Service Desk é uma parte vital do Departamento de TI de uma organização e

deve ser o único ponto de contato para TI usuários em uma base dia-a-dia - e irá
lidar com todos os incidentes e solicitação de serviços, geralmente usando
ferramentas de software especializados para registrar e gerenciar todos esses
eventos.
O valor de um Service Desk eficaz não deve ser subestimado - um Service Desk
bom muitas vezes pode compensar deficiências em outras partes da
organização de TI, mas um Service Desk pobres (ou a falta de um Posto de
Serviço) pode dar uma má impressão de uma outra maneira muito organização
de TI eficaz!
Por isso, é muito importante que o calibre correto de pessoal utilizado no Service
Desk e que Gerentes de TI fazer o seu melhor para fazer a mesa de um lugar
atrativo para trabalhar para melhorar a retenção de pessoal.
A natureza exata, tipo, tamanho e localização de um Service Desk pode variar,

dependendo do tipo de negócio, número de usuários, a geografia, a
complexidade das chamadas, escopo de serviços e de muitos outros fatores.
Em alinhamento com cliente e de negócios exigências, os gerentes seniores da

organização de TI, deve decidir a natureza exata de seu Service Desk
necessária (e se deve ser interna ou terceirizada para uma terceiro) Como parte
de sua ITSM geral estratégia (Ver Estratégia de Serviço publicação) - e posterior
planejamento deve ser feito para preparar e implementar o Service Desk
apropriado função (Seja na implementação de uma nova função, ou, mais
provavelmente nos dias de hoje ao fazer alterações necessárias para uma
função existente - veja Design de Serviços e Transição de Serviço publicações).
6.2.1 Justificação e do papel do Service Desk
Muito pouca justificação é necessário hoje para um Service Desk, como muitas
organizações têm se convencido de que esta é de longe a melhor abordagem
para lidar com questões de primeira linha de suporte de TI. Basta fazer a
pergunta "Qual é a alternativa?" Para fazer um caso convincente para o conceito
de Service Desk. Onde justificação adicional é necessária, os seguintes
benefícios devem ser considerados:

• Melhor serviço ao cliente, percepção e satisfação
• Acessibilidade aumentada através de um único ponto de contacto de
comunicação e informação
• Melhorqualidade e de resposta mais rápido de pedidos do cliente ou
usuário
• Melhor trabalho em equipe e comunicação
• Maior concentração e uma abordagem pró-ativa para a prestação de
serviços
• Um negócio reduzida negativo impacto
• Melhor infra-estrutura e de gestão controlar
• Melhor utilização de Suporte de TI recursos e aumento da produtividade
do pessoal de negócios
• Mais significativo gestão da informação de apoio à decisão
• É comum prática que o Service Desk posições fornece "nível de entrada"
para o pessoal de ITSM. Trabalho sobre o Service Desk é uma 'terra'
excelente para quem deseja seguir a carreira de Serviço de Gestão de.
No entanto, isso também pode apresentar desafios com pessoas que não
entendem do negócio ou da tecnologia. Usuáriochamando o Service Desk
deve ser capaz de falar com alguém que é capaz de atender às suas
necessidades, e os analistas do Service Desk não deve ser queimado em
menos de um ano por causa de estresse. Cuidados devem ser tomados
para selecionar adequadamente os indivíduos qualificados com um bom
entendimento do negócio e fornecer treinamento adequado - redução
impedindo assim em níveis de apoio, devido à falta de conhecimento na
primeira linha.
6.2.2 Posto de objectivos de serviço
O objetivo principal do Service Desk é restaurar normal ' serviço'Aos usuários o

mais rápido possível. Neste "contextorestauração do serviço'Significa, no sentido
mais amplo possível. Enquanto isto pode envolver a fixação de um técnico
culpa, Pode igualmente envolver o cumprimento de uma solicitação de serviço
ou respondendo a uma consulta - tudo o que é necessário para permitir que os
usuários de voltar a trabalhar de forma satisfatória.
Responsabilidades específicas incluirão:
• Registrando todas as informações relevantes incidente/ Serviço detalhes

da solicitação, a categorização alocação e códigos de priorização
• Fornecer primeira linha de investigação e diagnóstico
• Resolver os incidentes / requisições de serviços que eles são capazes
• A escalada de incidentes / requisições de serviços que não podem ser
resolvidos dentro de prazos acordados
• Manter os usuários informados sobre o progresso
• Fechar todos os incidentes resolvidos, pedidos e outras chamadas

• Condutor cliente/ Satisfação do usuário call-backs/surveys conforme
acordado
• Comunicação com os usuários - mantendo-os informados de incidente
progresso, interrupções notificando-os de mudanças iminentes ou
acordado, etc
• Atualizando o CMS sob a direção e aprovação de Gerenciamento da
Configuração se assim for acordado.
Nota: essas atividades são explicados e definir em contexto com a mais

completa Gerenciamento de Incidentes e Cumprimento de Requisição processo
nas seções 4.2 e 4.3, respectivamente.
6.2.3 estrutura organizacional Service Desk
Há muitas maneiras de estruturar Mesas de Serviço e localizá-las - ea solução

correta irá variar para diferentes organizações. As principais opções são
detalhadas a seguir, mas, na realidade, uma organização pode precisar
implementar uma estrutura que combina um número dessas opções, a fim de
atender plenamente as necessidades de negócios:
6.2.3.1 Posto de Serviço Local
Este é o lugar onde uma mesa é co-localizados dentro ou fisicamente perto do

usuário comunidade que serve. Essa comunicação muitas vezes ajudas e dá
uma presença bem visível, o que alguns usuários gostam, mas muitas vezes
pode ser ineficiente e caro recurso como pessoal são amarrados à espera de
lidar com incidentes quando a taxa de volume e chegada de chamadas não
pode justificar isso.
Pode, no entanto, haver algumas razões válidas para a manutenção de um

balcão de local, mesmo quando chamar volumes por si só não justificam.
Razões podem incluir:
• Língua e as diferenças culturais ou políticos

• Diferentes fusos horários
• Grupos especializados de usuários
• A existência de serviços personalizados ou especializadas que exigem
conhecimento especializado
• VIP criticidade / estado de usuários.

Figura 6.2 Service Desk local
6.2.3.2 Service Desk centralizado
É possível reduzir o número de Service Desks, fundindo-os em um único local

(ou em um número menor de locais), chamando a equipe em uma ou mais
estruturas centralizadas Posto de Serviço. Isso pode ser mais eficiente e de
baixo custo, permitindo menos pessoal global para lidar com um volume maior
de chamadas, e também pode levar a níveis mais altos através de familiarização
grande através de ocorrência mais freqüente de eventos. Pode ainda ser
necessário manter alguma forma de "presença local" para lidar com suporte
físico exigências, mas esse pessoal pode ser controlada e implantado a partir do
balcão central.

Figura 6.3 Service Desk centralizado
6.2.3.3 Service Desk Virtual
Através da utilização de tecnologia, em particular a Internet, bem como a

utilização de ferramentas de suporte corporativos, é possível dar a impressão de
uma única central de serviços, centralizado, quando, de facto, o pessoal pode
ser espalhada ou localizado em qualquer número ou tipo de geográfica ou locais
estruturais. Isso traz a opção de 'trabalho em casa', secundário grupo de apoio,
Off-shore, ou terceirização - Ou qualquer combinação necessária para atender
usuário demanda. É importante notar, contudo, que as salvaguardas são
necessários em todas estas circunstâncias para assegurar a consistência e
uniformidade de serviço qualidade e termos culturais.

Figura 6.4 Service Desk Virtual
6.2.3.4 Siga o Sol
Algumas organizações globais ou internacionais pode desejar combinar duas ou

mais de sua geograficamente dispersos Service Desks para fornecer 24 horas
de acompanhamento do sol serviço. Por exemplo, um Service Desk na Ásia-
Pacífico pode lidar com chamadas durante seu horário de expediente normal e
no final deste período, pode entregar a responsabilidade por quaisquer
incidentes abertas para uma mesa de base europeia. Essa mesa vai lidar com
essas chamadas, juntamente com os seus próprios incidentes durante o seu dia-
padrão e, em seguida, entregar a uma secretária EUA-baseado - que,
finalmente, as mãos de volta a responsabilidade para a mesa da Ásia-Pacífico
para completar o ciclo.
Isso pode dar cobertura de 24 horas na relativamente baixa custar, Como

nenhuma mesa tem que trabalhar mais do que um único deslocar. No entanto,
as mesmas garantias de processos comuns, ferramentas, banco de dados
compartilhado de informações e cultura devem ser abordadas para esta
abordagem para prosseguir - e bem controlados escalada e processos de
transferência são necessários.

6.2.3.5 grupos Posto de serviço especializado
Para algumas organizações que poderia ser benéfico para criar "grupos de
especialistas" dentro da estrutura geral de Service Desk, para que incidentes
relacionados a um determinado De serviços de TI podem ser encaminhadas
diretamente (normalmente através da seleção de telefonia ou de uma interface
web-based) para o grupo de especialistas. Isso pode permitir que mais
rapidamente resolução desses incidentes, através de uma maior familiaridade e
formação especializada.
A seleção será feita através de um script ao longo das linhas de 'Se o seu
chamar é sobre o serviço X, por favor, pressione 1 agora, caso contrário, por
favor, segure para um analista de Service Desk ".
É necessário cuidado para não complicar mais a seleção, então grupos de

especialistas deve ser considerada apenas para um número muito pequeno de
serviços essenciais, caso existam, e onde chamam taxas sobre isso serviço
justificar um grupo especializado em separado.
6.2.3.6 Ambiente
O ambiente onde o Service Desk deve ser localizado deve ser cuidadosamente
escolhido. Sempre que possível, as seguintes instalações devem ser fornecidos:
• Um local onde toda a função pode ser posicionado com luz natural
suficiente e espaço total - para permitir mesa adequada e espaço de
armazenamento, e espaço para se movimentar, se necessário
Anedota
Uma empresa descobriu que havia um 'nós e eles' cultura existente entre o
Service Desk e as equipes de apoio. As equipes de terceira linha muitas vezes
acredita-se ser melhor do que o Service Desk. Escondendo o Service Desk de
distância em uma sala isolada ajudou a reforçar essa cultura. A empresa
constatou que a criação de um escritório de plano aberto com o Service Desk no
meio de trabalho mais próxima incentivou e ajudou a quebrar essas barreiras
• Um ambiente tranquilo, com acústica adequada controlar de modo que

uma conversação telefónica não é perturbada por uma outra
• Ambiente agradável e mobiliário confortável, de modo a aliviar o clima (o
Service Desk pode ser um lugar muito estressante para trabalhar, então
cada pequena ajuda!)
• Uma área de sala de descanso e refresco separado nas proximidades,
para que a equipe possa fazer pausas curtas como apropriado, quando
necessário, sem estar longe por muito tempo.

6.2.3.7 Nota sobre a construção de um único ponto de contato
Independentemente de a combinação das opções escolhido para cumprir uma

organizaçãoEstrutura do Posto de Serviço geral individual, usuários deve estar
em dúvida sobre quem contactar se eles precisam de ajuda. Um único número
de telefone (ou um número único para cada grupo se mesas separadas são
escolhidas) devem ser fornecidos e bem divulgado -, bem como um endereço de
e-mail único e uma página de contato Internet Service Desk.
Idéias que podem ser usadas com sucesso para ajudar a divulgar o número de
telefone de Serviço de Recepção e e-mail, e disponibilizá-lo à mão quando os
usuários estão propensos a precisar deles, são:
• Incluindo o número de telefone de Service Desk em rótulos de hardware

IC, anexa ao componentes o usuário é susceptível de ser chamadas
sobre
• Impressão de Service Desk detalhes de contato nos telefones
• Para PCs e laptops, usando um fundo personalizado ou área de trabalho
com o Serviço detalhes de contato Posto, juntamente com informações ler
a partir do sistema que será necessário ao chamar (como endereço IP,
sistema operacional construir número, etc), num canto
• Imprimir o número de Service Desk em 'brindes' (canetas, lápis, canecas,
mouse-esteiras, etc)
• Proeminente colocar esses detalhes em Service Desk Internet / intranet
locais
• Incluí-los em quaisquer cartões telefônicos ou cartões de pesquisa de
satisfação com os usuários deixados quando uma visita mesa foi
necessário
• Repetindo os detalhes sobre toda a correspondência enviada aos
usuários (juntamente com chamar números de referência)
• Colocar os detalhes sobre a afixação ou locais físicos que os usuários
tendem a visitar regularmente (entradas, refeitórios, áreas de
arrefecimento, etc.)
6.2.4 pessoal Service Desk
As questões envolvidas na, e os critérios para estabelecer, o pessoal adequado

modelo e os níveis são discutidos nesta seção. Detalhes sobre Service Desk
típico papels e responsabilidades podem ser encontradas no parágrafo 6.6.1
abaixo. Eles incluem o Service Desk Manager, Supervisor, analistas e, em
algumas organizações, esses papéis são complementados por usuários de
negócios ('Super Users '), que fornecem suporte de primeira linha.
6.2.4.1 Os níveis de pessoal

Uma organização deve assegurar que o número correto de funcionários estão
disponíveis a qualquer momento para atender a demanda que está sendo
colocado sobre a mesa pela empresa. Taxas de chamadas podem ser muito
voláteis e muitas vezes no mesmo dia, a taxa de chegada pode ir de muito alta a
muito baixa e de volta. Uma organização planejamento uma nova mesa deve
tentar prever a taxa de chegada de chamadas e perfil - e ao pessoal em
conformidade. A análise estatística dos chamar taxas de chegada em regime de
suporte atuais devem ser realizados e, em seguida, acompanhado de perto e
ajustada, se necessário.
Muitas organizações vai descobrir que as taxas de chamadas de pico durante o

início do dia escritório e depois cair rapidamente, talvez com outra explosão no
início da tarde - isso, obviamente, varia de acordo com o organizaçãoNegócio 's,
mas é um padrão, muitas vezes ocorrendo para muitas organizações. Em tais
circunstâncias, pode ser possível utilizar parte-time, home-trabalhadores,
segunda linha de apoio pessoal ou de terceiros para cobrir os picos.
Os seguintes fatores devem ser considerados ao decidir os níveis de pessoal:
• Cliente expectativas de serviço

• Negócio exigências, tais como orçamento, Chamada tempo de respostas,
etc
• Tamanho, idade relativa projeto e complexidade do Infraestrutura de TI e
Catálogo de Serviços - por exemplo, o número eo tipo de incidentes, a
extensão do padrão personalizado contra software off-the-shelf
implantado, etc
• O número de clientes e usuários para apoiar, e fatores associados, tais
como:
• Número de clientes e usuários falando uma língua diferente
• Nível de habilidade
• Incidente e Solicitação de Serviço tipos (e tipos de RFC, se for o caso):
• Duração do tempo requerido para tipo de chamadas (por exemplo,
consultas simples, especialista aplicação consultas, hardware, etc)
• Experiência local ou externo necessário
• O volume e os tipos de incidentes e solicitações de serviço
• O período de cobertura apoio necessário, com base em:
• Horas coberta
• Fora-de-horas de apoio exigências
• Fusos horários a serem cobertas
• Locais a serem suportados (especialmente se Service Desk
funcionários também realizam mesa do lado de suporte)
• O tempo de viagem entre os locais
• Workload padrão de pedidos (por exemplo, diariamente, fim de
mês, etc)
• O meta de nível de serviços em vigor (níveis de resposta, etc)
• O tipo de resposta exigida:

• Telefone
• E-mail/fax/voice mail / vídeo
• Presença física
• Acesso on-line /controlar
• O nível de formação exigido
• As tecnologias de apoio disponíveis (por exemplo, telefone sistemas,
ferramentas de suporte remoto, etc)
• Os actuais níveis de competência do pessoal
• Os processos e procedimentos em uso.
Todos esses itens devem ser cuidadosamente considerados antes de tomar

qualquer decisão sobre os níveis de pessoal. Isso também deve ser refletido nos
níveis de documentação necessária. Lembre-se que o melhor a serviço, Mais o
negócio vai usá-lo.
Uma série de ferramentas estão disponíveis para ajudar a determinar o número

adequado de funcionários para o Service Desk. Estes carga de trabalho
modelagem ferramentas são dependentes de "conhecimento local" detalhada do
organização tal como chamar volumes e padrões, serviços e perfil do usuários,
etc
6.2.4.2 Os níveis de especialização
Uma organização deve decidir sobre o nível e variedade de habilidades que

exige de sua equipe de Service Desk - e, em seguida, garantir que essas
habilidades estão disponíveis nos momentos apropriados.
Uma gama de opções de habilidade é possível, a partir de um 'call-logging "

serviço apenas - onde a equipe só precisa de muito conhecimentos técnicos
básicos - direito até a um "técnico" Service Desk onde a equipe tecnicamente
mais qualificada da organização são usados. No caso do primeiro, não haverá
um manuseamento elevada, mas baixa resolução taxa, enquanto no último caso,
esta será invertida.
A decisão sobre o nível de competências necessárias, muitas vezes, ser

conduzido por vezes alvo de resolução (concordou com o negócio e capturado
em meta de nível de serviços), a complexidade dos sistemas de apoio e 'o que a
empresa está disposta a pagar ".
Há uma forte correlação entre a resposta e as metas de resolução e custars - de

um modo geral, o menor dos tempos alvo, maior o custo, porque mais recursos
são necessárias.
Embora possa haver casos em negócios dependência criticidade ou fazer uma

mesa altamente qualificados tecnicamente um imperativo, a abordagem ideal e
melhor custo-benefício é geralmente a primeira linha tem uma "chamada-

logging" de apoio através do Service Desk, com rápido e eficaz escaladas para
mais qualificados grupos de resolução de segunda linha e terceira linha, onde
pessoal qualificado pode ser concentrada e mais eficazmente utilizados (ver
Gerenciamento de Incidentes, Secção 4.2, para mais informações e orientações
sobre estruturas de ponta a ponta-de apoio). No entanto, este ponto de partida
básico pode ser melhorada ao longo do tempo, proporcionando ao pessoal de
primeira linha com um eficaz da base de conhecimento, script de diagnósticos e
ferramentas de apoio integrados (incluindo um CMS), bem como a formação
contínua ea consciência, de modo que as taxas de resolução de primeira linha
pode ser gradualmente aumentada.
Isso também pode ser alcançado através da localização de segundo nível

pessoal no Service Desk, efetivamente criando uma estrutura de dois níveis. Isto
tem vantagens de fazer segundo nível pessoal disponível para ajudar a lidar com
períodos de pico de chamadas e para treinar o pessoal mais júnior, e, muitas
vezes, aumentar a taxa de resolução na primeira chamada. No entanto, segundo
pessoal da linha, muitas vezes têm deveres fora do Service Desk - resultando
em listas que têm de ser geridos ou posições de segunda linha pessoal que está
sendo duplicado. Além disso, ter que lidar com chamadas de rotina pode ser
desmotivador para o pessoal mais experiente. Uma outra desvantagem potencial
é que o Service Desk torna-se muito bom em resolver as chamadas, enquanto a
segunda linha pessoal deve ser focada na remoção do causa raiz em vez disso.
Outro fator a considerar quando se decidir sobre as habilidades exigências para

o Serviço de Pessoal da recepção é o nível de personalização e especialização
dos serviços suportados. Serviços padronizados requerem menos conhecimento
específico para fornecer qualidade cliente apoiar. Quanto mais especializado o
serviço, o conhecimento especializado mais provável será exigida na primeira
chamada.
Note-se que em primeira linha resolução as taxas podem ser reduzidos por
eficácia Gerenciamento de Problemas, O que vai reduzir a quantidade dos mais
simples, incidentes repetitivos. Em tais casos, embora os índices de resolução
parecem estar a correr para baixo, o conjunto serviço qualidade terá melhorado
através da remoção completa dos muitos incidentes. Enquanto isso é bom, se a
equipe de Service Desk são pagos incentivos ou bônus de resolução na primeira
chamada, pode ser desastrosa para a moral e processo eficácia, A menos que o
bônus limiar é revered.
Melhorias no tempo de resolução / taxas não deve ser deixado ao acaso, mas
deverão ser parte de uma Melhoria de Serviço em curso Programa (Veja a
Melhoria de Serviço Continuada publicação para maiores detalhes).
Uma vez que o nível de conhecimentos necessários foram identificados, existe

uma tarefa permanente de garantir que o Service Desk é operado de tal forma
que o pessoal necessário obter e manter as habilidades necessárias - e que o

pessoal com o equilíbrio correto de habilidades estão de plantão em momentos
apropriados para que a consistência é mantida.
Isso envolverá uma formação contínua e programa de conscientização que deve

abranger:
• Habilidades interpessoais, tais como habilidades de telefonia, habilidades

de comunicação, escuta ativa e clienteDe cuidados de treinamento.
• Consciência negócio: conhecimento específico do organização'S áreas de
negócio, motoristaA estrutura, prioridades, etc
• A consciência de serviço de toda a chave da organização De serviços de
TIs para a qual o suporte está a ser fornecido
• Consciência técnica (e mais profunda formação técnica para o nível
adequado, dependendo da taxa de resolução procurado)
• Dependendo do nível de suporte fornecido, alguns diagnóstico
habilidades (por exemplo, Kepner e Tregoe)
• Ferramentas de apoio e técnicas
• Treinamento de conscientização e tutoriais em novo sistemas e
tecnologias, antes da sua introdução
• Processos e procedimentos (mais incidente particularmente Alterar e
Gerenciamento da Configuração - Mas uma visão geral de todos os
processos de ITSM e procedimentos)
• Digitando habilidades para garantir a entrada rápida e precisa de
incidente ou solicite mais detalhes do serviço.
Para tal programa seja eficaz habilidade, exigências e os níveis devem ser
avaliados periodicamente e treinamento registros mantidas.
Formulação cuidadosa de rotações de pessoal ou horários deve ser mantido

para que um equilíbrio consistente de experiência pessoal e os níveis de
habilidade apropriadas estão presentes durante toda a crítica operacional
períodos. Não é suficiente ter apenas o número certo de funcionários de plantão
- a mistura correta de habilidades também deve estar disponível.
6.2.4.3 Formação
É fundamental que toda a equipe de Service Desk são adequadamente

treinados antes de serem chamados para o pessoal do Service Desk. Um
programa de indução formal deve ser realizada por todos os novos funcionários,
o conteúdo exato do que irá variar de acordo com os níveis de habilidade e
experiência existentes do novo recruta, mas é provável que incluem muitas das
habilidades necessárias, como descrito acima.
Sempre que possível, a consciência de um negócio programa, Incluindo curtos

períodos de destacamento em áreas chave do negócio, deve ser fornecida para
o pessoal novo que ainda não tem este nível de consciência negócio.

Ao iniciar no Service Desk, Nova equipe deverá inicialmente equipe experiente
'sombra' - sentar com eles e ouvir em chamadas - antes de começar a tomar
chama-se com um mentor ouvindo e capaz de intervir e fornecer suporte quando
necessário. O mentor deverá inicialmente rever cada chamar com o estagiário,
após concluir a aprender quaisquer lições. A frequência dessas análises deverá
ser gradualmente reduzida, experiência e confiança cresce, mas o mentor ainda
deve estar disponível para fornecer suporte contínuo, mesmo quando o
candidato tenha alcançado o estágio de carreira solo.
Mentores podem precisar de ser treinados sobre como mentor. Experiência

Service Desk e habilidades técnicas não são o único exigências para orientação.
Eficazes de transferência de conhecimentos e habilidades a capacidade de
ensinar sem ser condescendente ou ameaçando são igualmente importantes.
Aprograma será necessário para manter o conhecimento pessoal do Serviço de

Recepção de até à data - e torná-los conscientes de novo desenvolvimentos,
serviços e tecnologias. O momento de tal eventos é crítica de forma a não
impacto sobre as funções normais. Mesas Serviço Muitos acham que é melhor
para organizar curta "tutoriais" durante períodos tranquilos quando os
funcionários têm menos probabilidade de ser necessário para atendimento de
chamadas.
Nota: Investimento também deve ser feito no desenvolvimento profissional do

pessoal de Service Desk. Interno de orientação e de sombreamento pessoal de
apoio de segundo e terceiro nível é um bom começo, mas Mesas best-of-breed
Serviço beneficiar de um programa formal de desenvolvimento de pessoal.
Comprometimento organizacional para o desenvolvimento profissional ajuda a
incutir um senso de realização e oportunidade para o pessoal. Isso muitas vezes
leva à inovação em Service Desk operação (Tais como serviços especializados),
que por sua vez, na unidade operacional eficiências em todos os níveis da
camada de apoio. Ela ajuda a construir habilidades que podem ser utilizados na
sua actual papel assim como ele saltar inicia o treinamento para um novo papel.
Embora seja importante para desenvolver suas competências essenciais em sua
função atual, ter um plano de carreira claro e reconhecendo exigência futuro e
as necessidades de desenvolvimento também é importante.
6.2.4.4 retenção de pessoal
É muito importante que todos os gestores de TI reconhecem a importância do

Service Desk e do pessoal que trabalha nele, e dar essa atenção especial.
Qualquer perda significativa de pessoal pode ser perturbador e levar a
inconsistência de serviço - Por isso os esforços devem ser feitos para que o
Service Desk um lugar atraente para o trabalho.
Maneiras em que isto pode ser feito incluem o reconhecimento apropriado do

papel com pacotes de recompensa Reconhecendo isso, equipe de construção

de exercícios, rotação de pessoal para outras atividades (projetos, o suporte de
segunda linha, etc.)
O Service Desk muitas vezes pode ser usado como um trampolim para outras
funções mais técnicas ou de supervisão / gerencial. Se isso for feito, o cuidado é
necessário para garantir que a sucessão adequada planejamento ocorre para
que a mesa não perder todo o seu conhecimento fundamental em qualquer área
de uma vez. Além disso, boa documentação e cross-training pode reduzir esse
risco.
6.2.4.5 Superusuários
Muitas organizações achar que é útil para nomear ou designar um número de

'Super Users "ao longo da usuário comunidade, para atuar como pontos de
ligação com TI em geral e do Service Desk, em particular.
Superusuários pode ser dada alguma formação adicional e de sensibilização e

usado como um canal de comunicações de fluxo em ambas as direcções. Elas
podem ser feitas para filtrar os pedidos e as questões levantadas pela
comunidade de usuários (em alguns casos, até mesmo indo tão longe a ponto
de ter incidentes ou solicitações levantadas pelo Super Usuário) - pode ajudar a
prevenir 'incidente tempestades "quando um serviço chave ou componente
falha, que afeta muitos usuários.
Eles também podem ser utilizados para informação de cascata para o exterior
ao longo do seu Service Desk comunidade local de utilizadores, que podem ser
muito úteis na divulgação detalhes do serviço para todos os utilizadores muito
rapidamente.
É importante notar que, Super Users deve registrar todas as chamadas que
lidam com, e não apenas aqueles que eles passam para TI. Isto significa acesso
e treinamento sobre como usar as ferramentas, registrando incidentes. Isso vai
ajudar a medir a atividade do Super Usuário e também para assegurar que a sua
posição não é abusado. Além disso, ele vai garantir que a história valiosas sobre
incidentes e serviços qualidade não são perdidos.
Também pode ser possível para Superusuários a ser envolvida em:
• Formação de pessoal para usuários na sua área

• Fornecendo suporte para incidentes menores ou simples pedido
cumprimento
• Envolvimento com o novo liberars e lançamentos.
Superusuários não necessariamente fornecer suporte para toda a TI. Em muitos

casos, um Super Usuário só irá fornecer suporte para uma específica
aplicaçãoOu módulo unidade de negócios área. Como um usuário de negócios

do Usuário Super muitas vezes tem um conhecimento profundo de como chave
processo de negócioes executar e como trabalhar em serviços prática. Este é
um conhecimento muito útil para compartilhar com o Service Desk, De modo que
possa proporcionar maior qualidade de serviços no futuro.
Note-se que um compromisso firme é necessário que potenciais usuários Super

e, especificamente, a sua gestão, que terá o tempo e interesse para realizar
esse papel antes da seleção e treinamento começa.
A Super User, enquanto uma interface valiosa para o negócio e Service Desk,
deve ser dada formação adequada, responsabilidade e expectativa.
Superusuários podem ser vulneráveis ao mau uso, se o seu papel, as
responsabilidades e os processo regem estes não são claramente comunicada
aos usuários. É imperativo que um Super Usuário não é visto como um
substituto, ou um meio de contornar, o Service Desk.
6.2.5 Posto de métricas de serviço
Métricos deve ser estabelecida de modo que atuação do Service Desk pode ser
avaliada em intervalos regulares. Isto é importante para avaliar a saúde,
maturidade,eficiência,eficácia e todas as oportunidades para melhorar as
operações do Service Desk.
Métricas de desempenho Service Desk devem ser realistas e cuidadosamente

escolhido. É comum para selecionar essas métricas que são facilmente
disponíveis e que pode parecer ser uma possível indicação de desempenho, no
entanto, isso pode ser enganador. Por exemplo, o número total de chamadas
recebidas pela Central de Serviços não é em si uma indicação de qualquer bom
ou mau desempenho e pode de fato ser causada por eventos completamente
fora do controlar do Service Desk - por exemplo, um período particularmente
movimentado para o organização, Ou o liberar de um novo versão de uma das
grandes empresas sistema.
Um aumento no número de chamadas para a Central de Serviço pode indicar

serviços menos confiáveis durante esse período de tempo - mas também pode
indicar a confiança do usuário em um aumento de Service Desk que está
amadurecendo, resultando em uma maior probabilidade de que os usuários vão
procurar assistência em vez de tentar para lidar sozinho. Para este tipo de
métrica para ser confiável para alcançar ou conclusão de comparação, ainda
mais em períodos anteriores por quaisquer melhorias Service Desk
implementadas desde a última medição linha de baseOu serviço confiança
alterações, problemas, etc, para isolar a verdadeira causa para o aumento é
necessário.
Uma análise adicional e mais métricas detalhadas são, portanto, necessário, e

deve ser examinada durante um período de tempo. Estas incluem as estatísticas

de processamento de chamadas anteriormente mencionados em telefonia, e,
adicionalmente:
• A primeira linha resolução taxa de: a percentagem de chamadas

resolvidas em primeira linha, sem a necessidade de escalada a outra
grupo de apoios. Esta é a figura freqüentemente citado por organizações
como a principal medida do desempenho Mesas serviço - e utilizado para
fins de comparação com o desempenho de outras mesas - mas é preciso
cuidado ao fazer qualquer comparação. Para maior precisão e mais
comparações válidas isto pode ser subdivididos como segue:
• A percentagem de chamadas resolvidas no primeiro contato com o
Service Desk, Isto é, enquanto o usuário ainda está no telefone
para informar o chamar
• A percentagem de chamadas resolvido pela equipe de Service
Desk-se sem ter que procurar mais profundo apoio de outros
grupos. Nota: algumas mesas vai escolher para co-localizar ou
incorporar mais tecnicamente capacitada equipe de segunda linha
com o Service Desk (ver Gerenciamento de Incidentes para mais
detalhes). Em tais casos, é importante ao fazer comparações com
a também separar (i) A percentagem resolvido pela equipe de
Service Desk sozinho, e (ii) A percentagem resolvido pela equipe
de primeira linha Posto de Serviço e segunda linha de apoio equipe
combinados.
• O tempo médio para resolver uma incidente (Quando resolvidas em
primeira linha)
• O tempo médio para escalar um incidente (onde de primeira linha
resolução não é possível)
• Service Desk média custar de lidar com um incidente. Dois métricos
devem ser considerados aqui:
• O custo total do Service Desk dividido pelo número de chamadas.
Isto irá proporcionar um valor médio que é útil como um índice e
para planejamento propósitos, mas não representar com precisão
os custos relativos dos diferentes tipos de chamadas
• Ao calcular a percentagem de tempo de duração da chamada na
mesa geral e elaborar um custo por minuto (custos totais para o
período, dividido pelo total de minutos de duração de chamada ")
isto pode ser usado para calcular o custo das chamadas individuais
e dar um valor mais exacto .
Ao avaliar os tipos de incidentes com duração de chamada, uma imagem

mais refinada de custo por chamada por tipos surge e dá indicação de
quais tipos de incidentes tendem a custar mais para resolver e possíveis
alvos para melhorias.
• Percentual de cliente ou actualizações do utilizador conduzido dentro de

tempos-alvo, como definido na SLA alvos

• Tempo médio para rever e fechar uma chamada resolvido
• O número de chamadas discriminadas por hora do dia e dia da semana,
combinada com a média de tempo de chamada métrica, é fundamental
para determinar o número de pessoal necessário.
Outros detalhes gerais sobre métricas e como eles devem ser usados para
impulsionar serviço qualidade está incluído no Melhoria de Serviço Continuada
publicação.
6.2.5.1 cliente / usuário pesquisas de satisfação
Bem como acompanhamento das medidas "duras" do Service Desk da atuação

(Através dos indicadores descritos acima), também é importante avaliar 'soft'
medidas - tais como o quão bem os clientes e usuários sentem que suas
chamadas foram atendidas, se eles se sentem o operador Service Desk foi
cortês e profissional, se reforçou a confiança no utilizador.
Este tipo de medida é o melhor obtido a partir dos próprios usuários. Isso pode
ser feito como parte de um amplo cliente/usuário pesquisa de satisfação que
cobre tudo ou pode ser especificamente orientadas para as questões Service
Desk sozinho.
Uma maneira eficaz de alcançar o último é através de um inquérito telefónico de

call-back, onde uma organização independente Service Desk Operador ou
Supervisor anéis de volta uma pequena porcentagem de usuários logo após seu
incidente foi resolvido, para fazer as perguntas específicas necessárias.
Cuidados devem ser tomados para manter o número de perguntas a um mínimo

(5-6 no máximo) para que os usuários terão tempo para cooperar. Também
perguntas da pesquisa deve ser projetado de forma que o usuário ou o cliente
sabe o que perguntas de área ou tema são cerca e que incidente ou serviço eles
estão se referindo. O Service Desk deve atuar em baixos níveis de satisfação e
qualquer feedback recebido.
Para permitir comparações adequadas, o mesmo percentual de chamadas

devem ser selecionados em cada período e devem ser rigorosamente realizadas
apesar das pressões do tempo outros.
As pesquisas são uma área complexa e especializada, exigindo um bom

entendimento de estatísticas e técnicas de pesquisa. Esta publicação não pode

tentar fornecer uma visão geral de todas elas, mas um resumo de algumas das
técnicas mais amplamente utilizadas e ferramentas está listada na Tabela 6.1.
Técnica / Ferramenta Vantagens Desvantagens
Depois de call-pesquisa • Alta taxa de resposta • As pessoas podem

desde o chamador é já se sentir
Chamadores são no telefone pressionados a tomar
convidados a permanecer • Chamador seja a pesquisa,
no telefone após a chamar examinado resultando em uma
e então solicitados a imediatamente após a experiência de
classificar o serviço foram chamada assim que sua serviço negativa
fornecidos experiência é recente • O inspector é visto
como parte do
Service Desk em
estudo, o que pode
desencorajar
respostas abertas
Pesquisa telefônica de • Maior taxa de resposta • Este método poderia

saída desde o chamador é ser visto como
entrevistado diretamente intrusivo, se
Os clientes e usuários que • Categorias específicas interrompe a
já usaram o Service Desk de usuário ou cliente chamada do
são contactados algum pode ser alvo de utilizador ou cliente
tempo após a sua feedback (por exemplo, do seu trabalho
experiência com o Service pessoas que solicitaram • A pesquisa é
Desk um serviço específico, ou realizada algum
pessoas experimentou tempo depois que o
uma quebra para um usuário ou cliente
serviço particular) usou o Service Desk,
pelo que a sua
percepção pode ter
mudado
Entrevistas pessoais • O entrevistador é capaz • Entrevistas são

de observar sinais não- demorados, tanto
Os clientes e usuários são verbais, bem como ouvir para o entrevistador
entrevistados o que o usuário ou o eo entrevistado
pessoalmente pela pessoa cliente está dizendo • Usuários e clientes
que faz a pesquisa. Isto é • Usuários e clientes pode transformar as
especialmente eficaz para sentem um maior grau de entrevistas em
clientes ou usuários que atenção pessoal e uma sessões de
usam o Service Desk sensação de que suas reclamações ·
extensivamente ou que respostas estão sendo
tiveram uma experiência levados a sério ·
muito negativa
Entrevistas de grupo • Um número maior de • As pessoas não

usuários e clientes podem se expressar
Os clientes e usuários são podem ser entrevistado livremente na frente
entrevistados em pequenos • As perguntas são mais de seus colegas ou

grupos. Isto é bom para a genéricos e, portanto, gerentes
recolha de impressões mais consistente entre • As opiniões das
gerais e para determinar se entrevistas · pessoas pode ser
existe uma necessidade de facilmente alterado
alterar certos aspectos da por outros membros
Service Desk, E.g. horas de do grupo durante a
serviço ou localização entrevista ·
Postais / e-mail • Clientes específicos ou • Pesquisas postais

pesquisas todos ou os usuários são intensivos de
podem ser orientados trabalho para
Questionários são enviados • Pesquisas postais podem processo
para um conjunto alvo de ser anônimas, permitindo • O percentual de
clientes e usuários. Eles que as pessoas se pessoas que
são convidados a retornar expressem mais responderam a
suas respostas por e / mail livremente inquéritos postais
• E-mail pesquisas não são tende a ser pequeno
anônimas, mas podem • Má interpretação de
ser criados usando uma pergunta
formulários poderia afetar o
automatizados que resultado ·
tornam conveniente e
fácil para o usuário a
responder e aumentar a
probabilidade de que
será completada ·
Pesquisas on-line • O público potencial A percentagem de inquiridos

dessas pesquisas é não pode ser prevista
Os questionários são bastante grande
postados em um site e • Os entrevistados podem
usuários e clientes preencher o questionário
incentivada através de e- em seu próprio tempo
mail ou links de um site • Os links em sites
popular para participar da populares são
pesquisa lembranças boas, sem
ser intrusivo
Tabela 6.1 técnicas e ferramentas de pesquisa
6.2.6 A terceirização do Service Desk
A decisão de terceirizar é uma estratégico emitir para gerentes seniores - e é

abordado em detalhes na Estratégia de Serviço e Design de Serviços
publicações. Muitos dos diretrizs nesta seção não são exclusivos do Service
Desk e pode ser aplicado a qualquer função, A área de suporte ou serviço sendo
terceirizado (ou fora-tarefa).
Independentemente das razões, ou a extensão de, a terceirização contrato, É

vital que o organização mantém a responsabilidade para as atividades e

serviços prestados pelo Service Desk. A organização é responsável pela
resultados da decisão e, portanto, deve determinar que tipo de serviço o
contratante fornece, e não o contrário.
Se a rota é escolhida de terceirização, há algumas salvaguardas que são

necessárias para assegurar que o Service Desk terceirizado funciona de forma
eficaz e eficiente, com a organização de TI outras equipes e departamentos e
esse fim-de-final Serviço de Gestão de controlar é mantida (isto é
particularmente importante para as organizações que procuram ISO / IEC 20000
certificado como controle de gestão global tem de ser demonstrada). Algumas
dessas garantias são definidas a seguir.
6.2.6.1 As ferramentas comuns e processos
O Service Desk não tem a responsabilidade de todos os processos e

procedimentos que inicia. Por exemplo, um Solicitação de Serviço é recebido
pelo Service Desk, mas a solicitação é atendida pelo interno de TI Operacional
equipe.
Se o Service Desk é terceirizado, os cuidados devem ser tomados para que as

ferramentas são consistentes com aqueles que ainda estão sendo usados na
organização do cliente. Terceirização é muitas vezes visto como uma
oportunidade para substituir os instrumentos desatualizados ou inadequada,
apenas para descobrir que há integração grave problemas entre a nova
ferramenta e as ferramentas herdadas e processos.
Por esta razão, é importante para assegurar que estas questões são
devidamente estudadas e do cliente exigências são devidamente delimitado e
especificado antes do contrato de terceirização. Ferramentas de Service Desk
deve não só apoiar a Central de serviços terceirizados, mas devem apoiar os
processos da organização do cliente e requisitos de negócio também.
Idealmente, a secretária terceirizada deve usar as mesmas ferramentas e

processos (ou, no mínimo, as ferramentas de interface e processos) para
permitir suave processo fluxo entre o Service Desk e de segunda e terceira linha
grupo de apoios.
Além disso, o Service Desk terceirizado deve ter acesso a:
• Todos registro de incidentes e informações

• Grave problemas e informações
• Erro Conhecido Dados
• Alterar agendamento
• Fontes de conhecimento interno (especialmente técnico ou aplicação
especialistas)
• SKMS

• CMS
• Alertars a partir de monitoramento ferramentas.
Muitas vezes, é um desafio processos integradores e ferramentas em um menos

maduro organização com os de uma organização mais madura. Uma suposição
comum, mas incorreta é que o maturidade de uma organização, de alguma
forma como consequência uma maior maturidade na outra. O envolvimento ativo
para garantir o alinhamento de processos e ferramentas é essencial para uma
transição suave e gerenciamento contínuo de serviços entre organizações
internas e externas. Na verdade, se este não está directamente dirigida, isso
pode resultar na falha do contrato.
É também muitas vezes erradamente do princípio de que a prova de Serviço de

Gestão de qualidade e vencimento em um parceiro terceirizar externo pode ser
garantido por afirmar exigências, na aquisição processo para 'ITIL conformidade
'e / ou'ISO / IEC 20000 certificado'. Estas declarações podem indicar que um
potencial fornecedor usa o modelo ITIL em sua entrega de serviços aos clientes,
ou que eles têm alcançado padrãos certificação para sua interna práticas, mas é
igualmente importante ter a tecnologia que permite no lugar e sendo utilizado um
que demonstra provedor de serviços'S capacidade para gerenciar serviços e
interface com as práticas internas harmoniosamente. Não existe um padrão de
observância que garante esforços de aquisição deste e por isso deve incluir
consultas específicas para satisfazer esta exigência. Mais informações sobre o
fornecedor terceirizar aquisição pode ser encontrada na Design de Serviços
publicação.
6.2.6.2 SLA alvos
As metas de SLA para geral incidente manipulação e resolução vezes precisam

ser acordado com o clientes, e entre todas as equipes e departamentos - e OLA
/ UC metas precisam ser coordenadas e concordou com o indivíduo grupo de
apoios para que apoiar e apoiar o SLA alvos.
Exemplos destes podem ser vistos na secção métricos acima (ver secção 6.2.5).
6.2.6.3 A boa comunicação
As linhas de comunicação entre a Central de Serviço terceirizado e os outros

grupos de apoio precisam trabalhar de forma muito eficaz. Isto pode ser ajudado
por alguns ou todos os seguintes passos:
• Feche a partilha física

• Ligação regular /rever reuniões
• Cross-training tutoriais entre as equipes e departamentos
• 'Parceria"Arranjos quando o pessoal de ambas as organizações são
usados em conjunto com o pessoal da mesa

• Planos de comunicação e atuação alvos são documentados de forma
consistente em Olas e UCs.
Nos casos em que o Service Desk está localizado off-shore, Nem todas essas
medidas será possível. No entanto, a necessidade de formação e comunicação
da equipe de Service Desk ainda é crítica, ainda mais em casos em que existam
diferenças linguísticas e culturais.
Isso será abordado mais detalhadamente em publicações ITIL complementares,

mas, como regra, as empresas de outsourcing que oferecem soluções off-shore
de Service Desk deve levar em conta o seguinte:
• Treinamento programas focada na compreensão cultural do cliente

mercado
• Habilidades de linguagem - especialmente a compreensão da utilização
idiomática da língua no mercado do cliente. Isto não é assim que o
serviço de som A equipe como os nativos do país do cliente (que tipo de
insinceridade é rapidamente detectado por clientes), mas para facilitar a
compreensão do cliente e para melhor apreciar as suas prioridades
• Visitas regulares de representantes do cliente organização para fornecer
treinamento e feedback apropriado diretamente para a gestão de Service
Desk e pessoal
• Treinamento no uso de organizações dos clientes ferramentas e métodos
de trabalho. Isto é especialmente eficaz se os materiais de formação
semelhantes são apresentados pelos instrutores idênticos aos utilizados
pela organização do cliente.
6.2.6.4 Propriedade dos dados
Domínio claro dos dados coletados pelo Service Desk terceirizado deve ser
estabelecida. Posse de todos os dados relativos aos usuários, clientes, CIS
afetada, serviços, incidentes Solicitação de Serviços, mudanças, etc devem
permanecer com a organização que é terceirização o atividade -, Mas ambas as
organizações precisam de acesso a ele.
Dados que estão relacionados especificamente para atuação de funcionários da

empresa de terceirização continuará a ser propriedade daquela empresa, que
muitas vezes é legalmente impedido de compartilhar os dados com a
organização do cliente. Isso também pode ser verdade para outros dados que
são utilizados exclusivamente para a gestão interna do Service Desk, como
contagem de cabeça, otimização de atividades, Service Desk custar
informações, etc
Todos os relatórios exigências e as questões em torno da propriedade dos

dados deve ser especificado no subjacente contrato com a empresa que presta
o serviço de outsourcing.

6.3 Gestão Técnica
Gestão Técnica refere-se aos grupos, departamentos ou equipes que fornecem
conhecimento técnico e de gestão global da Infraestrutura de TI.
6.3.1 papel de Gestão Técnica
Gestão Técnica desempenha um duplo papel:
• Ele é o guardião do conhecimento técnico e experiência relacionada à

gestão da infra-estrutura de TI. Neste papel, Gestão Técnica garante que
o conhecimento necessário para projeto,teste, Gerir e melhorar De
serviços de TIs é identificado, desenvolvido e aperfeiçoado.
• Ele oferece a real recursos para suportar o ITSM Ciclo de Vida. Neste
papel de Gestão Técnica garante que os recursos sejam efetivamente
treinados e distribuídos para projeto,construir, Transição, operar e
melhorar a tecnologia necessária para dar suporte De serviços de TIs.
Ao realizar estes dois papels, Gestão Técnica é capaz de assegurar que o

organização tem acesso ao tipo certo nível e de humano recursos para
administrar de tecnologia e, portanto, para satisfazer negócios objetivos.
Definindo o exigências para estes papéis começa na Estratégia de Serviço e é
expandido em Design de Serviços, Validado em Transição de Serviço e refinado
em Melhoria de Serviço Continuada (Ver outro ITIL publicações nesta série).
Parte deste papel é também para assegurar um equilíbrio entre o nível de

habilidade de utilização, e a custar desses recursos. Por exemplo, a contratação
de um recurso de nível superior no ponto mais alto da escala salarial e só então
usar essa habilidade para 10% do tempo não é eficaz. A melhor de Gestão
Técnica estratégia seria identificar os momentos em que a habilidade é
necessário e, em seguida, contratar um empreiteiro para apenas as tarefas.
Outra estratégia em organizações maiores é a equipe de alavancagem

especialista de "central" de grupos para que especialistas possam ser bem
utilizados e proporcionar uma economia de escala para a organização e
minimizar a necessidade de contratar em empreiteiros. Habilidades
especializadas devem ser identificados entre os recursos na organização de TI,
então aproveitados para necessidades específicas que possam surgir, análogas
a uma unidade especial tático, cujos membros também desempenhar funções
regulares, mas que são designados para tarefas que necessitam de suas
habilidades especiais. Este tipo de utilização de recursos é particularmente útil
tanto para projeto equipes e problema resolução.
Um papel adicional, mas muito importante desempenhado pela Gestão Técnica

é fornecer orientações para Operações de TI sobre a melhor forma de levar a
cabo o curso operacional gerenciamento da tecnologia. Este papel é

parcialmente realizado durante o Design de Serviços processo, Mas é também
uma parte da comunicação diária com TI Gestão de Operações , que procuram
alcançar a estabilidade e ótima atuação.
Os objetivos, atividades e estruturas que permitem Gestão Técnica para

executar essas funções de forma eficaz são discutidas abaixo.
6.3.2 Técnicas objectivos de gestão
Os objetivos da Gestão Técnica são para ajudar a planejar, implementar e

manter uma infra-estrutura estável técnica para apoiar a organização do
processo de negócioes por meio de:
• Bem desenhado e altamente resistente, topologia de custo-benefício

técnico
• O uso de habilidades técnicas adequadas para manter a infra-estrutura
técnica em óptimo estado
• Swift uso de habilidades técnicas para diagnosticar e resolver
rapidamente qualquer técnica falhas que ocorrem.
6.3.3 genéricos técnicos actividades de gestão
Gestão Técnica está envolvido em dois tipos de atividade:
• Atividades que são genéricas para a Gestão Técnica função como um

todo são discutidos nesta seção como eles permitem Gestão Técnica
como uma função para executar o seu papel.
• Um conjunto de atividades distintas e processos que são executadas por
todas as três funções de Aplicação, Técnico de TI e Gestão de
Operações são abordados no Capítulo 5.
As actividades de gestão genéricos técnicos se destacam as seguintes:
• Identificar o conhecimento ea experiência necessários para gerenciar e

operar o Infraestrutura de TI e para fornecer De serviços de TIs. Este
processo começa durante a Estratégia de Serviço fase, é expandido em
detalhe em Design de Serviços e é realizado em Operação de Serviço.
Contínuo avaliação e atualização dessas habilidades é feito durante
Melhoria de Serviço Continuada.
• Documentação das habilidades que existem no organização, Bem como
as capacidades que precisam de ser desenvolvido. Isso incluirá a
desenvolvimento Habilidades de Inventários e as atuação Análise das
Necessidades de Formação.
• Iniciando treinamento programas para desenvolver e refinar as
habilidades da técnica adequada recursos e treinamento manter registros
para todos os recursos técnicos.

• Concepção e execução de treinamento para usuários, o Service Desk e
outros grupos. Embora o treinamento exigências deve ser definido em
Design de Serviços, são executadas de Operação de Serviço. Onde
Gestão Técnica não entrega de formação, é responsável por identificar as
organizações que podem fornecer isso.
• Recrutamento ou contratação de recursos com as competências que não
podem ser desenvolvidas internamente, ou onde há pessoas suficientes
para realizar as atividades exigidas gestão técnica.
• Aquisição de habilidades para atividades específicas, onde as habilidades
necessárias não estão disponíveis internamente ou no mercado aberto,
ou onde ela é mais custo-eficiente para fazer isso.
• Definição de padrãos utilizados no projeto de novo arquiteturas e
participação na definição de arquiteturas de tecnologia durante a
Estratégia de Serviço e as fases do projeto.
• Pesquisa e desenvolvimento de soluções que podem ajudar a expandir a
Carteira de serviço, ou que podem ser usados para simplificar ou
automatizar Operações de TI, Reduzir custars ou aumentar os níveis de
serviço de TI.
• Participação na concepção e construção de novos serviços. Gestão
Técnica irá contribuir para a concepção das normas técnicas Arquitetura e
desempenho para serviços de TI. Além disso, será também responsável
por especificar o operacional atividades necessárias para gerenciar a
Infraestrutura de TI em uma base contínua.
• Envolvimento em projetos, não apenas durante o Design de Serviços e
Transição de Serviço, mas também para Melhoria de Serviço Continuada
ou projectos operacionais, tais como atualizações do sistema operacional,
servidor projetos de consolidação ou movimentos físicos.
• Disponibilidade e Gerenciamento da Capacidade são dependentes de
Gestão Técnica de Engenharia de serviços de TI para atender os níveis
de serviço exigidas pela empresa. Isto significa que, modelagem e carga
de trabalho previsão são muitas vezes feito com recursos gestão técnica.
• Assistência na avaliação risco, Identificando o serviço e críticas sistema
dependências e definição e implementação de contramedidas.
• Concepção e realização de testes para a funcionalidade, desempenho e
capacidade de gerenciamento de serviços de TI.
• Gestão de fornecedores. Muitos departamentos de Gestão Técnica ou
grupos são os únicos que sabem exatamente o que é exigido de um
fornecedor e como medir e gerenciá-los. Por esta razão, muitas
organizações dependem de Gestão Técnica departamentos para gerir
contratos com fornecedores de itens de configuração específica. Se este
for o caso, é importante para assegurar que estes relaçãos são
gerenciados como parte do SLM processo.
• Definição e gestão dos Gestão de Eventos padrãos e ferramentas.
Gestão Técnica também vai monitorar e responder a muitas categorias de
eventos.

• Departamentos de gestão técnica ou grupos são essenciais para o
atuação de Gerenciamento de Incidentes. Eles recebem através de
incidentes Escalada funcional e fornecer suporte de segundo e de nível
superior. Eles também estão envolvidos na manutenção de categorias e
que define o escalada procedimentos que são executados em
Gerenciamento de Incidentes.
• Gestão Técnica em função fornece o recursos que executam o
Gerenciamento de Problemas processo. É a sua competência técnica e
conhecimento que é usado para diagnosticar e resolver problemas. É
também sua relação com os vendedores que são usados para escalar e
acompanhamento com as equipes de suporte do fornecedor.
• Gestão de recursos técnicos estarão envolvidos na definição de
codificação sistemas que são usados em Gestão de Incidentes e
Problemas (Categorias por exemplo incidente).
• Gestão de recursos técnicos são utilizados para apoiar a Gestão de
Problemas na validação e manutenção da BDEC.
• Gestão da Mudança depende do conhecimento técnico e experiência
para avaliar as mudanças, e muitas mudanças será construído pela
Direção Técnica.
• Soltes são freqüentemente implementados com recursos gestão técnica.
• Gestão Técnica irá fornecer informações para, e operacionalmente
manter, o Sistema de gerenciamento de configuração e os seus dados.
Isto será feito em cooperação com Aplicação de Gestão de para garantir
que o CI correto atributos e os relacionamentos são criados a partir da
desenvolvimento de serviços e da manutenção contínua ao longo da vida
de CIs.
• Gestão Técnica está envolvido na Melhoria de Serviço Continuada
processos, especialmente na identificação de oportunidades de melhoria
e, em seguida, para ajudar a avaliar as soluções alternativas.
• Como um guardião do conhecimento técnico e experiência, Gestão
Técnica garante que todo o sistema operacional e documentação está
atualizada e devidamente utilizado. Isto inclui assegurar que toda a
gestão, administração e usuário manuais estão em dia e concluir e que a
equipe técnica está familiarizado com seu conteúdo.
• Atualização e manutenção de dados utilizados para elaboração de
relatórios sobre as capacidades técnicas e de serviço, por exemplo,
Capacidade e Gestão de Desempenho, Gerenciamento de
Disponibilidade, Gerenciamento de Problemas, etc
• Auxiliar de TI Gestão Financeira para identificar o custar de TI e recursos
humanos utilizados para gerenciar De serviços de TIs.
• Envolvimento na definição do operacional atividades realizadas como
parte de TI Gestão de Operações. Muitos departamentos de gestão
técnica, grupos ou equipes também executam as atividades operacionais,
como parte de um organização'S TI Gestão de Operações função.

6.3.4 organização Gestão Técnica
Gestão Técnica normalmente não é fornecido por um único departamento ou

grupo. Um ou mais Suporte técnico equipes ou departamentos serão
necessários para fornecer gerenciamento e apoio técnico para a Infraestrutura
de TI. Ao todo, mas as menores organizações, onde uma equipe única,
combinada ou departamento pode ser suficiente, as equipes ou departamentos
separados serão necessários para cada tipo de infra-estrutura utilizada.
TI Gestão de Operações consiste de um certo número de áreas tecnológicas.

Cada uma delas requer um conjunto específico de habilidades para gerenciar e
operar lo. Alguns conjuntos de competências são relacionado e pode ser
realizada por generalistas, enquanto outros são específicos de um
componente,sistema ou plataforma.
O principal critério de estrutura organizacional de Gestão Técnica é a de

especialização ou divisão do trabalho. O princípio é que as pessoas são
agrupadas de acordo com suas habilidades técnicas, e que estes conjuntos de
habilidades são determinadas pela tecnologia que precisa ser gerenciado.
Seções 6.6 e 6.7 abrangem os aspectos organizativos de Gestão Técnica em

detalhes, mas esta lista apresenta alguns exemplos típicos de equipas de gestão
técnicos ou departamentos:
• Mainframe equipe ou departamento - se um ou mais tipos de mainframe

ainda estão sendo usados pelo organização
• Servidor equipe ou departamento - muitas vezes dividir novamente por
tipos de tecnologia (por exemplo, Unix servidor, Wintel servidor)
• Equipe de armazenamento ou departamento, responsável pela gestão de
todos os dispositivos de armazenamento de dados e mídia
• Equipe de suporte de rede ou departamento, cuidando de WANs internos
da organização / LANs e gestão de qualquer rede externa fornecedors
• Área de trabalho da equipe ou departamento, responsável por todos os
equipamentos desktop instalado
• Equipe de banco de dados ou departamento, responsável pela criação,
manutenção e suporte de bases de dados da organização
• Middleware equipe ou departamento, responsável pela integração, teste e
manutenção de todas as middleware em uso na organização
• Serviço de DiretórioA equipe ou departamento, responsável por manter o
acesso e direitos de elementos de serviço na infra-estrutura
• Internet ou Web equipe ou departamento, responsável pela gestão do
disponibilidade e segurança de acesso aos servidores e conteúdo por
cliente externos, usuários e parceiros
• Mensagens equipe ou departamento, responsável por serviços de correio
electrónico
• Baseada em IP Telephony equipe ou departamento (por exemplo, VoIP).

6.3.5 Manutenção Design e Técnico de Apoio Técnico e
Gestão Técnica consiste de arquitetos especializados técnicos e designers (que

estão principalmente envolvidos durante Design de Serviços) E pessoal
especializado de manutenção e suporte (que são principalmente envolvidos
durante Operação de Serviço).
Nesta publicação, eles são vistos como sendo parte da mesma função, Mas
muitas organizações vê-los como duas equipes distintas ou mesmo
departamentos. O problema com esta abordagem é que boa projeto precisa de
entrada das pessoas que são necessários para gerenciar a solução - e bom
operação requer o envolvimento das pessoas que projetaram a solução.
O problemas que precisam ser superados são semelhantes aos enfrentados na

gestão da Aplicação Ciclo de Vida (Ver secção 6.5 para uma discussão mais
detalhada). A solução irá incluir os seguintes elementos:
• Pessoal de apoio devem ser envolvidos durante o projeto ou arquitetura

de uma solução. Equipe de projeto deve ser envolvido na criação de
manutenção objetivos e resolver problemas de suporte.
• A mudança na forma como o projeto ea equipe de suporte são medidos.
Designers deve ser realizada, em parte, responsáveis por falhas de
projeto que criam operacional interrupções. Equipe de apoio deverá ser
realizada, em parte, responsável pela contribuição para a arquitetura
técnica.
6.3.6 Técnicas de Gestão de métricas
Métricas para Gestão Técnica dependerá em grande parte da tecnologia que

está a ser gerido, mas alguns genéricos métricos incluem:
• Medição de resultados acordados. Estas podem incluir:

• Contribuição para a realização dos serviços para o negócio.
Apesar de muitas das equipas de gestão técnicos não estarão em
contato direto com a empresa, a tecnologia que gerem impacto no
negócio. Métricas devem refletir tanto (incidentes traçadas para a
sua equipe) negativos e positivos (sistema atuação e
disponibilidadeContribuições)
• Transação taxas e disponibilidade para operações críticas de
negócios
• Service Desk treinamento
• Gravação problema resoluçãos para o BDEC
• Usuário medidas do qualidade de saídas, tal como definidos no
SLA
• Instalação e configuração de componentes sob seu controlar.

• Métricas de processo. As equipas de gestão técnica executar
Gerenciamento de Serviços de muitos processo actividades. A sua
capacidade de fazê-lo será medido como parte das métricas de processo
se for o caso (ver secção sobre cada processo para mais detalhes). Os
exemplos incluem:
• O tempo de resposta para eventos e as taxas de conclusão do
evento
• Incidente resolução vezes por segundo e terceira linha de apoio
• Resolução de problemas estatísticas
• Número de escaladas e razão para as escalações
• Número de mudanças implementadas e saiu
• Número de alterações não autorizadas detectado
• Número de liberars implantado, com sucesso total e
• Questões de segurança detectados e resolvidos
• Real sistema utilização contra Plano de capacidade previsões
(onde a equipe tem contribuído para a desenvolvimento do plano)
• Rastreamento contra PIS
• Despesas contra orçamento.
• Tecnologia atuação. Estes métricos são baseados Design de Serviços
especificaçãos e desempenho técnico padrãos definir por vendedores, e
serão normalmente contido em OLAs ou Procedimentos Operacionais
Padrão. Métricas reais variam de acordo com a tecnologia, mas é
provável que incluem:
• Taxas de utilização (por exemplo, memória ou processador para
servidor, Largura de banda para redes, etc)
• Disponibilidade (De sistemas, de rede, dispositivos, etc), que é útil
para a medição da equipa ou o desempenho do sistema, mas não
deve ser confundida com a disponibilidade de serviço - o que
requer a capacidade para medir a disponibilidade geral do serviço
e pode usar os números de disponibilidade para um certo número
de sistemas individuais ou componentes
• Performance (e.g. tempo de respostas, filas taxas, etc.)
• Tempo médio entre falhas dos equipamentos especificados. Esta
métrica é utilizado para assegurar que as decisões de compra boas e
estão a ser feitos, quando comparado com os programas de manutenção,
se o equipamento está a ser correctamente mantido
• A medição da atividade de manutenção, Incluindo:
• Manutenção realizada por horário
• Número de janelas de manutenção ultrapassado
• Manutenção objetivos alcançado (número e porcentagem).
• Formação e competências desenvolvimento. Essas métricas garantir
que a equipe tem as habilidades e treinamento para gerenciar a
tecnologia que está sob a sua controlar, E também identificar as áreas em
que a formação ainda é necessária.

6.3.7 documentação Gestão Técnica
Gestão Técnica está envolvido na elaboração e manutenção de várias

documentos como parte de outros processos (por exemplo, Planejamento de
Capacidade,Gestão da Mudança,Gerenciamento de Problemas, Etc.) Estes
documentos são discutidos com algum detalhe no relevante processo
descrições.
No entanto, existem alguns documentos que são específicos para os grupos

técnicos de gestão ou as equipes que irão documentar gestão e controle de
documentos relativos à tecnologia sob seu controle. Documentação Gestão
Técnica inclui o seguinte.
6.3.7.1 A documentação técnica
O fornecimento e manutenção de documentação técnica para todos os itens de

configuração é de responsabilidade do gerenciamento técnico. Estes incluem:
• Manuais Técnicos
• Manuais de gestão e administração
• Usuário manuais para CEI. Estes serão geralmente excluem aplicação
manuais do usuário, que são mantidos por Aplicação de Gestão de.
6.3.7.2 programações de manutenção
Estes esquemas são elaborados e acordados durante a Design de Serviços fase

relacionada com a disponibilidade e Gerenciamento da Capacidade, Mas são
essencialmente as propriedades dos vários Gestão Técnica departamentos,
grupos ou equipes. Isso é porque eles tem o conhecimento técnico para
tecnologias específicas e são mais susceptíveis de saber o que é necessário
para mantê-los em funcionamento.
Para mais detalhes sobre a definição de programas de manutenção e Objetivo

de manutenção do serviços, referem-se a ITIL Design de Serviços publicação.
6.3.7.3 Inventário de Habilidades
Um Inventário de Habilidades é um sistema ou ferramenta que identifica as

competências necessárias para dar suporte De serviços de TIs e também os
indivíduos que possuem essas habilidades. Estoques habilidades são mais
eficazes se elas estão alinhadas com os processos, arquiteturas e atuação
padrãos.
Além disso, estoques habilidades devem identificar o treinamento disponível

para cultivar cada habilidade deve deixar o pessoal existente organização.

Estoques habilidades também podem ser usados como parte do Portfólio de
Serviços para avaliar se um novo serviço pode ser entregue com o pessoal
existente e conjuntos de habilidades, ou se um investimento tem de ser feito em
equipe nova ou treinamento. Estoques habilidades pode, portanto, contribuir
significativamente para a Planejamento de Capacidade.
A definição e manutenção de estoques Habilidades requer uma boa interface

com processos de Recursos Humanos e ferramentas na organização.

6,4 TI Gestão de Operações
Nos negócios, o termo 'Gestão de Operações"É usada para significar o
departamento, grupo ou equipe de pessoas responsáveis por executar a
organização do dia-a-dia operacional - actividades como correr da linha de
produção de uma fabricação ambiente ou a gestão dos centros de distribuição e
os movimentos da frota dentro de uma organização logística.
Gestão de Operações geralmente tem as seguintes características:
• Há trabalho para assegurar que um dispositivo, sistema ou processo é, na

verdade, correr ou de trabalho (em oposição a estratégia ou
planejamento)
• Isto é onde planos são transformados em ações
• O foco é sobre as actividades diárias ou a curto prazo, mas deve notar-se
que estas actividades serão geralmente realizada e repetida ao longo de
um período relativamente longo (em oposição a one-off projeto atividades
do tipo)
• Essas atividades são executadas por pessoal técnico especializado, que
muitas vezes têm de receber formação técnica para aprender a executar
cada atividade
• Há um foco na construção de ações consistentes repetíveis, que - se
repetido com freqüência suficiente no nível certo de qualidade - Se
assegurar o sucesso do operação
• Isto é, onde o valor real da organização é entregue e medido
• Existe uma dependência sobre o investimento em equipamentos ou
recursos humanos ou de ambos
• O valor gerado, deve exceder o custar do investimento e todos os outros
organizacional despesas geraiss (tais como gestão e custos de
marketing) se o negócio é de sucesso.
De um modo semelhante, TI Gestão de Operações pode ser definida como a

função de responsável pela gestão e manutenção constantes de uma
organização de Infraestrutura de TI para garantir a entrega do nível acordado de
De serviços de TIs para o negócio.
Operações de TI pode ser definido como o conjunto de actividades envolvidas

no funcionamento do dia-a-dia da Infraestrutura de TI com o objetivo de entregar
serviços de TI em níveis acordados para atender negócios declarado objetivos.
6.4.1 Funções de Gerenciamento de Operações de TI
O papel de Gestão de Operações é executar as actividades em curso e

procedimentos necessárias para gerenciar e manter a infra-estrutura de TI, de
modo a entregar e suportar serviços de TI nos níveis acordados. Estes já foram
descritos na seção 5, mas são resumidas aqui para ser completo:

• Operações de controle, Que supervisiona a execução e monitoramento
do operacional actividades e eventos na Infra-estrutura de TI. Isto pode
ser feito com o auxílio de um Operações Ponte ou Centro de Operações
de Rede. Além de executar as tarefas de rotina de todas as áreas
técnicas, Controle de Operações também executa as seguintes tarefas
específicas:
• Console de Gerenciamento de, Que se refere à definição de
observação central e monitoramento capacidade e em seguida,
usando os consoles para exercer o acompanhamento e controlar
atividades
• Job Scheduling, Ou a gestão de trabalhos em lote de rotina ou
scripts
• Faça backup e Restaurar em nome de todos os técnicos e equipes
de gerenciamento de aplicativos e serviços e, muitas vezes, em
nome da usuários
• De impressão e de saída de gestão para a recolha e distribuição
de toda a impressão centralizada ou saída eletrônica
• Desempenho das atividades de manutenção em nome técnico ou
Aplicação de Gestão de equipes ou departamentos.
• Gestão de Instalações, Que se refere à gestão da TI física ambiente,
Normalmente um Centro de Dados ou salas de informática e recuperação
locais, juntamente com toda a potência e equipamentos de refrigeração.
Facilities Management também inclui a coordenação de grande escala de
consolidação projetos, por exemplo, Consolidação de dados ou Centro
servidor projetos de consolidação. Em alguns casos, a gestão de um data
center é terceirizado, no qual Facilities Management caso refere-se à
gestão do terceirização contrato.
Tal como acontece com muitos IT Service Management processos e funções, TI

Gestão de Operações desempenha um duplo papel.
• Gerenciamento de Operações é responsável pela execução das

atividades e atuação padrãos definido durante Design de Serviços e
testado durante a Transição de Serviço. Neste sentido, o papel de
operações de TI "é, principalmente, manter o status quo. A estabilidade
do Infraestrutura de TI e consistência de De serviços de TIs é uma
preocupação primordial de Operações de TI. Mesmo operacional
melhorias visam encontrar formas mais simples e melhor de se fazer a
mesma coisa.
• Ao mesmo tempo, as operações de TI é parte do processo de agregação
de valor para os diferentes linhas de negócios e apoiar a rede de valor
(Veja o ITIL Estratégia de Serviço publicação). A capacidade da empresa
para cumprir o seu objetivos e para manter a competitividade depende da
saída e confiança do dia-a-dia operação de TI. Como tal, TI Gestão de
Operações deve ser capaz de se adaptar continuamente a actividade
exigências e procura. O negócio não se importa que operações de TI

cumprido um padrão procedimento ou que um servidor realizada de forma
otimizada. Como a demanda de negócios e mudança de requisitos,
Gerenciamento de Operações deve ser capaz de manter o ritmo com
eles, muitas vezes desafiando o status quo.
Operações de TI deve alcançar um equilíbrio entre essas funções, o que exigirá

o seguinte:
• A compreensão de como a tecnologia é usada para fornecer serviços de

TI
• A compreensão da importância relativa e impacto desses serviços sobre o
negócio
• Procedimentos e manuais que delineiam o papel das operações de TI,
tanto na gestão da tecnologia e da entrega de De serviços de TIs
• Um conjunto claramente diferenciada de métricos de informar a empresa
sobre a realização dos objectivos de serviço, e de informar os gestores de
TI na eficiência e eficácia de Operações de TI
• Todos a equipe de TI Operações entender exatamente como o atuação
da tecnologia afeta serviços da entrega de TI
• Acustar estratégia destinado a equilibrar as exigências de diferentes
unidade de negócioss com a redução de custos através da otimização
disponíveis da tecnologia existente ou o investimento em novas
tecnologias
• Um valor, em vez de custo, retorno com base na estratégia de
investimento.
6.4.2 Operações de TI objectivos de gestão
Os objetivos do Gerenciamento de Operações incluem:
• Manutenção do status quo para alcançar a estabilidade do

organizaçãoDia-a-dia 's processos e atividades
• Escrutínio regular e melhorias para alcançar um melhor serviço a custos
reduzidos, mantendo a estabilidade
• Rápido aplicação de habilidades operacionais para diagnosticar e resolver
quaisquer operações de TI falhas que ocorrem.
6.4.3 Operações de TI Gestão de organização
Figura 6.1 na introdução do Capítulo 6 ilustra que a TI Gestão de Operações é

visto como um função em seu próprio direito, mas que, em muitos casos equipe,
do técnico e Aplicação de Gestão de grupos formam parte desta função.
Isso significa que alguns departamentos de Gestão Técnica e Aplicação ou

grupos vão gerenciar e executar os seus próprios operacional actividades.

Outros vão delegar essas atividades a um dedicado Operações de TI
departamento.
Não existe um método único para a atribuição de actividade, uma vez que
depende da maturidade e estabilidade da infra-estrutura que está sendo
gerenciado. Por exemplo, Técnico e áreas de aplicação de gerenciamento que
são relativamente novo e instável tendem a gerenciar suas próprias operações.
Grupos onde a tecnologia ou aplicação é estável, maduro e bem compreendido
tendem a ter suas operações mais padronizadas e, portanto, se sentem mais
confortáveis delegar essas atividades.
Algumas opções de como estruturar operações de TI são discutidos em detalhes

na seção 6.7 desta publicação.
6.4.4 Operações de TI métricas de gestão
TI Gestão de Operações é medida em termos da sua execução eficaz das

atividades especificadas e procedimentos, bem como a sua execução processo
actividades. Exemplos destes são os seguintes:
• A conclusão bem sucedida de trabalhos agendados

• Número de exceções para as atividades programadas e empregos
• Número de dados ou sistema restaurars exigido
• Equipamentos estatísticas de instalação, incluindo o número de itens
instalados por tipo, instalações bem-sucedidas, etc
• Processo métricos. Gestão de Operações de TI Service Management
executa muitos processo actividades. A sua capacidade de fazê-lo será
medido como parte das métricas de processo se for o caso (ver secção
sobre cada processo para mais detalhes). Os exemplos incluem:
• O tempo de resposta para eventos
• Incidente resolução vezes por incidentes
• Número de segurançaIncidentes relacionados
• Número de liberars implantado, com sucesso total e
• Se as atividades de manutenção ter sido delegada, então métricas
relacionadas a essas atividades também será apropriado:
• Métricas relacionadas a Gestão de Instalações são extensas, mas
geralmente incluem:

• Custos versus orçamento relacionados com a construção,
manutenção, segurança, Transporte, etc
• Incidentes relacionados com a construção, por exemplo, reparos
necessários para a instalação de
• Relatórios sobre acesso à facilidade
• Número de segurança eventos e incidentes e suas resolução
• Estatísticas de utilização de energia, além de aspectos
relacionados a mudanças no layout e estratégias de
condicionamento ambiental
• Eventos ou incidentes relacionados com o transporte e distribuição.
6.4.5 Operações de TI Gestão de documentação
Um certo número de documentos são produzidos e utilizados durante TI Gestão

de Operações. Esta lista é um resumo de alguns dos mais importantes e não
inclui relatórios que são produzidos pela TI Gestão de Operações em nome de
outros processos ou funçãos.
6.4.5.1 Procedimentos Operacionais Padrão
Os POPs são um conjunto de documentos que contêm instruções detalhadas e

atividade horários para cada equipe de Gerenciamento de Operações de TI,
departamento ou grupo.
Esses documentos representam a rotina de trabalho que precisa ser feito para
cada dispositivo, sistema ou procedimento. Eles também descrevem os
procedimentos a serem seguidos se uma exceção é detectada ou se um mudar
é necessária.
Documentos SOP também pode ser utilizado para definir níveis padrão de
atuação para dispositivos ou procedimentos. Em alguns organismos os
documentos SOP são referidos no OLA. Em vez de listar medidas de
desempenho detalhadas no OLA, uma cláusula é inserida para se referir ao
desempenho padrãos no POP e como estes serão medidos e relatados.
6.4.5.2 Operações Logs
Qualquer atividade que é realizada como parte de Operações de TI devem ser

registados para uma série de razões, incluindo:
• Elas podem ser usadas para confirmar a conclusão bem sucedida de

trabalhos ou actividades específicas
• Elas podem ser usadas para confirmar que um De serviços de TI foi
entregue conforme acordado
• Eles podem ser utilizados por Gerenciamento de Problemas para
pesquisar o causa raiz de incidentes

• Eles são a base para relatórios sobre o desempenho das equipes de TI
de Gestão de Operações e departamentos.
O formato destes registros é tão variada quanto o número de sistemas e Gestão

de Operações equipes ou departamentos. Exemplos de Logs operações incluem
o seguinte:
• Sistema operacional registra armazenados em cada dispositivo

• Aplicação registros de atividades armazenados em um arquivo no
aplicação servidor
• Evento Troncos armazenados no monitoramento servidor ferramenta
• Logs de utilização de dispositivos-chave
• Gravação de logs de acesso físico que acessou edifícios mais seguros e
quando
• Registros manuscritos das ações realizadas pelos operadores. Este deve
ser em um diário de bordo formal ou fichário, numeradas e armazenadas
de forma segura ambiente. Os cheques devem assegurar que as páginas
não são removidos.
Apolítica precisa ser estabelecido como parte dos POPs, para afirmar como os
logs de longas precisam ser mantidos, como são arquivados e quando eles
podem ser excluídos. Essas políticas levarão em conta estatutária e observância
exigências. Políticas também devem especificar os parâmetros para o
armazenamento adequado e apoio estratégias para armazenar e recuperar
arquivos de log.
6.4.5.3 Shift Schedules e Relatórios
Horários de turnos são documentos que delineiam as atividades exatas que

precisam ser realizadas durante o deslocar. Eles também irá listar todas as
dependências e atividade seqüências. Haverá provavelmente mais do que um
programa de mudanças, onde cada equipe terá um versão por sua própria
sistemas. É importante que todos os horários são coordenados, antes do início
da passagem. Isso geralmente é feito por uma pessoa que é especializada em
turno programação, com a ajuda de ferramentas de programação.
A Programação deslocamento pode consistir de um número de itens de rotina

que estão incluídos no POP. Neste caso, os artigos podem simplesmente ser
listados sucintamente com uma referência para a secção ou da página na SOP.
Horários mais turnos assumir a forma de uma lista onde os operadores podem
marcar o item como ela for concluída, juntamente com o tempo de conclusão.
Isto torna mais fácil para ver o andamento das atividades e também ajuda a
identificar possíveis problemas onde os trabalhos estão demorando muito.

Relatórios de turnos são uma forma de registrar as operações, mas têm o
adicional funçãos como se segue:
• Para gravar grande eventos e ações que ocorreram durante o turno

• Para fazer parte da transferência de soberania entre os líderes de
mudança
• Para denunciar qualquer exceção à Objetivo de manutenção do serviços
• Para identificar qualquer incompleto atividade que podem resultar em
degradação atuação em qualquer serviço durante a próxima horas de
serviço.
6.4.5.4 Horário de Operações
As listas de Operações são semelhantes a mudar programações mas cobrem

todos os aspectos da Operações de TI a um nível elevado. Essa programação
vai incluir uma visão geral de todas as alterações planejadas, manutenção,
trabalhos de rotina e trabalho adicional, juntamente com informações sobre o
negócio ou eventos de fornecedores. O Cronograma de Operações é usado
como base para a Reunião de operações diárias e é a referência principal para
todos os gerentes de operações de TI para acompanhar o progresso e detectar
exceções.
6,5 Gerenciamento de Aplicativos

Aplicação de Gestão de é responsável pela gestão aplicaçãos ao longo da sua
ciclo de vida. A função de gerenciamento de aplicativos é realizada por qualquer
departamento, grupo ou equipe envolvida na gestão e suporte operacional
aplicações. Gerenciamento de Aplicativos também desempenha um importante
papel no projeto, Teste e aperfeiçoamento de aplicações que fazem parte do De
serviços de TIs. Como tal, ele pode estar envolvido em desenvolvimento
projetos, mas normalmente não é o mesmo que as equipas de desenvolvimento
de aplicações.
6.5.1 papel Gerenciamento de Aplicativos
Gerenciamento de Aplicativos é a aplicações que Gestão Técnica é o

Infraestrutura de TI. Aplicação de Gestão desempenha um papel em todas as
aplicações, se comprados ou desenvolvidos in-house. Uma das principais
decisões que contribuam para a decisão de se comprar um aplicativo ou
construir -o (isto é discutido em detalhe no Design de Serviços publicação). Uma
vez que a decisão é tomada, Gerenciamento de Aplicativos irá desempenhar um
duplo papel:
• Ele é o guardião do conhecimento técnico e experiência relacionada com

aplicações de gestão. Neste Aplicação de Gestão de papel, trabalhando
em conjunto com a Gestão Técnica, garante que o conhecimento

necessário para projetar, teste, Gerir e melhorar os serviços de TI é
identificado, desenvolvido e aperfeiçoado.
• Ele oferece a real recursos para suportar o ITSM Ciclo de Vida. Neste
papel, Gerenciamento de Aplicativos garante que os recursos sejam
efetivamente treinados e distribuídos para projetar, construir, Transição,
operar e melhorar a tecnologia necessária para entregar e suportar os
serviços de TI.
Ao realizar essas duas funções, gerenciamento de aplicativos é capaz de

garantir que o organização tem acesso ao tipo certo e nível de recursos
humanos para gerenciar aplicações e, portanto, para atender empresas
objetivos. Esta começa em Estratégia de Serviço e é expandido em Design de
Serviço, testado em Transição de Serviço e refinado em Melhoria de Serviço
Continuada (Ver outro ITIL publicações nesta série).
Parte desse papel é garantir um equilíbrio entre o nível de habilidade e do custar

desses recursos.
Para além destes dois papéis de alto nível, Application Management também
executa as seguintes funções específicas:
• Fornecer orientação para Operações de TI sobre a melhor forma de

proceder à gestão em curso operacional de aplicações. Este papel é
parcialmente realizado durante o Design de Serviços processo, Mas é
também uma parte da comunicação diária com TI Gestão de Operações ,
que procuram alcançar a estabilidade e ótima atuação.
• A integração do Ciclo de Vida do Gerenciamento de Aplicativos para o
Ciclo de Vida de ITSM. Isto é discutido abaixo.
Os objetivos, atividades e estruturas que permitem Gerenciamento de

Aplicativos para jogar esses papéis efetivamente são discutidas abaixo.
6.5.2 Aplicação objectivos de gestão
Os objetivos do gerenciamento de aplicativos são apoiar a organização do

processo de negócioes, ajudando a identificar funcional e capacidade de
gerenciamento exigências para o software de aplicação e, em seguida, para
auxiliar na concepção e desenvolvimento dessas aplicações e suporte contínuo
e melhoria dessas aplicações.
Estes objectivos são alcançados através de:
• Os aplicativos que são bem desenhados, resistente e de baixo custo

• Garantir que a funcionalidade está disponível para realizar o negócio
exigido resultado

• O organização de competências técnicas adequadas para manter
operacional aplicaçãos em condição ideal
• Swift uso de habilidades técnicas para diagnosticar e resolver
rapidamente qualquer técnica falhas que ocorrem.
6.5.3 Gestão de princípios de aplicação
6.5.3.1 Construir ou comprar?
Uma das principais decisões em Aplicação de Gestão de é se comprar uma

aplicação que suporta a funcionalidade necessária, ou se a construir a aplicação
específica para a organização do exigências. Estas decisões são muitas vezes
feitas por um Diretor Técnico (CTO) ou Comitê Gestor, mas são dependentes da
informação a partir de um número de fontes. Estes são discutidos em detalhe na
Design de Serviços, Mas estão aqui resumidas a partir de uma Aplicação de
Gestão função perspectiva.
Gerenciamento de Aplicativos irá ajudar nesta decisão durante Design de

Serviços como se segue:
• Aplicação dimensionamento e carga de trabalho previsões (ver secção

4.6.4)
• Especificação de gerenciamento exigências
• Identificação de curso custo operacionals
• Dados os requisitos de acesso para o relatório ou a integração de outras
aplicações
• Investigar até que ponto a funcionalidade necessária pode ser atendida
pelas ferramentas existentes - e quanto personalização será necessário
para alcançar este
• Estimar o custo de personalização
• Identificar quais habilidades serão necessárias para apoiar a solução (por
exemplo, se um aplicativo é comprado, vai exigir um novo conjunto de
empregados, ou empregados existentes podem ser treinados para apoiá-
lo?)
• Requisitos de administração
• Requisitos de segurança.
Se a decisão é construir a aplicação, uma decisão ainda precisa ser feita se o

desenvolvimento será terceirizada ou construído usando funcionários. Isto é
detalhado no Estratégia de Serviço e Serviço de publicações de design, mas há
algumas considerações importantes que afetam a operação de serviço, por
exemplo:
• Como os requisitos de gerenciamento ser especificadas e acordadas (por

exemplo, aplicação de concepção e transação monitoramento)? Estas

são algumas vezes esquecida quando operacional equipes ou
departamentos não estão representados no projeto
• Quais são os Aceitação Critérios para operacional atuação, Como e onde
vai ser a solução testada e que irá realizar os testes?
• Quem será o proprietário e gerir a Biblioteca definitivo para essa
aplicação?
• Quem vai projeto e manter o operacional gestão e administração scripts
para estas aplicações?
• Quem é responsável pelo ambiente de set-up e possuir e manter a infra-
estrutura diferente componentes?
• Como vai ser a solução instrumentada de forma que ele é capaz de gerar
o requerido eventos?
6.5.3.2 Modelos Operacionais
Um Operacional Modelo é o especificação do operacional ambiente em que o

aplicação acabará por correr quando ele vai viver. Isto irá ser utilizado durante a
fase de ensaio e de transição para simular e avaliar o viver ambiente. Esta é
uma forma de garantir que o aplicativo pode ser dimensionados corretamente e
as condições ambientais necessárias podem ser documentados e
compreendidos por todos. A Operacional Modelo devem ser definidas e
utilizadas em testes, durante o Design de Serviços e Transição de Serviço fases,
respectivamente (ver Design de Serviços e publicações Transição de Serviço).
6.5.4 Aplicação de Gestão do Ciclo de Vida
O ciclo de vida seguido para desenvolver e gerenciar aplicações tem sido

referido por muitos nomes, incluindo o software Ciclo de Vida (SLC) e Software
Development Lifecycle (SDLC). Estes são geralmente utilizados pelas equipes
de desenvolvimento de aplicações e sua Projeto Gestores para definir o seu
envolvimento na concepção, construção, testes, implantação e suporte de
aplicações. Exemplos dessas abordagens são Análise de Sistemas Estruturado
e Metodologia Design (SSADM), Dynamic Método de Desenvolvimento de
Sistemas (DSDM), Rapid Application Development (RAD), etc
ITIL está interessado principalmente na gestão global de aplicativos como parte

de De serviços de TIs, sejam eles desenvolvidos internamente ou comprado de
um terceiro. Por esta razão, o termo Aplicação de Gestão de Ciclo de vida tem
sido utilizada, uma vez que implica uma visão mais holística.
Isso não deve substituir o SDLC, que ainda é uma abordagem válida usado por
desenvolvedores, especialmente por empresas de software de terceiros. No
entanto, isso não significa que deve haver um maior alinhamento entre o
desenvolvimento ver de aplicaçãos e da gestão "ao vivo" dessas aplicações.

Isso é mais difícil em grandes aplicativos adquiridos, tais como e-mail, já que os
desenvolvedores não costumam interagir individualmente com seu aplicativo
usuários. No entanto, o ciclo de vida básico ainda é válido na medida em que a
aplicação precisa exigências, projeto, Customização, operação e
desenvolvimento. A otimização é obtida através de uma melhor gestão,
melhorias para a personalização e upgrades.
O Ciclo de Vida do Gerenciamento de Aplicativos é ilustrado da seguinte forma:
Figura 6.5 Aplicação de Gestão do Ciclo de Vida
Processos de ITSM e processos de desenvolvimento de aplicações têm de ser

alinhadas como parte do total estratégia de entrega de serviços de TI em apoio
ao negócio.
Aplicações Desenvolvimento e Operações fazem parte do ciclo de vida do

mesmo conjunto e ambas devem ser envolvidas em todas as fases, embora o
seu nível de envolvimento pode variar, dependendo da fase do ciclo de vida.

Relação entre o gerenciamento de aplicativos e Serviço de Gestão de Ciclo
de Vidas
O Aplicação de Gestão de Ciclo de Vida não deve ser visto como uma
alternativa para o Lifecycle Management Service. As aplicações são parte dos
serviços e têm de ser gerenciados como tal. No entanto, aplicaçãos são uma
mistura única de tecnologia e funcionalidade e isso requer um foco especializado
em cada fase do ciclo de vida de Gerenciamento de Serviços.
Cada etapa do ciclo de vida de gerenciamento de aplicativos tem seu próprio

conjunto específico de objetivos, atividades entregas e equipes dedicadas. Cada
estágio tem também uma responsabilidade clara para garantir que suas saídas
igualar-se aos objetivos específicos do Lifecycle Management Service.
Diferentes aspectos do gerenciamento de aplicativos são abordados em
detalhes em cada uma das publicações da ITIL, como segue:
• Estratégia de Serviço: Define o total arquitetura de aplicações e infra-

estrutura. Isso irá incluir a definição dos critérios para o desenvolvimento
in-house, terceirização desenvolvimento, Ou a compra e personalização
de aplicativos. Estratégia de Serviço também vai ajudar a definir o
Portfólio de Serviços (Incluindo as aplicações), que também inclui
informações sobre o retorno do investimento de aplicações e os serviços
que eles suportam. Assim, de alto nível exigências são definidos durante
esta fase.
• Design de Serviços: Ajuda a estabelecer requisitos para a funcionalidade
e capacidade de gerenciamento de aplicações e trabalha com equipes de
desenvolvimento para que possam cumprir com esses objetivos. Design
de Serviços cobre a maior parte da fase de Requisitos e está envolvido
durante a Construir fase do Ciclo de Vida do Gerenciamento de
Aplicativos.
• Transição de Serviço: Equipes de desenvolvimento de aplicativos e
Gestão estão envolvidos em testar e validar o que foi construído e
implantá-lo operacionalmente.
• Operação de Serviço:Este abrange a fase Operate do Lifecycle
Management Application. Esses processos e estruturas são discutidas em
pormenor nesta publicação.
• Melhoria de Serviço Continuada: Cobre o Otimizar fase do Ciclo de Vida
do Gerenciamento de Aplicativos. Melhoria de Serviço Continuada mede
a qualidade e relevância de aplicações em operação e fornece
recomendações sobre como melhorar as aplicações se há um retorno
claro sobre o investimento para o fazer.
6.5.4.1 Requisitos
Esta é a fase durante a qual o exigências para uma nova aplicação estão
reunidos, com base nas necessidades comerciais do organização. Esta fase é

ativa principalmente durante a fase de Design de Serviços do Ciclo de Vida de
ITSM.
Existem seis tipos de requisitos para qualquer aplicação, seja sendo

desenvolvido in-house, terceirizado ou adquirido:
• Os requisitos funcionais são aqueles especificamente necessária para

suportar um negócio particular função
• Gerenciabilidade exigências, olhou de um Serviço de Gestão de
perspectiva, abordar a necessidade de um serviço ágil, seguro e
disponível, e lidar com questões como a desenvolvimento, Operações
sistema de gestão e segurança
• Usabilidade requisitos são aqueles que abordar as necessidades da
extremidade usuário, E em consequência as características do sistema
que facilitam a sua facilidade de uso
• Requisitos arquitetônicos, especialmente se este exige uma mudar a
existente arquitetura padrãos
• Requisitos de interface, onde existem dependências entre existentes
aplicaçãos ou ferramentas e da nova aplicação
• Exigência de Nível de Serviços, que especificam como o serviço deve
realizar, a qualidade de sua produção e outros aspectos qualitativos
medidos pelo usuário ou cliente.
6.5.4.2 Desenho
Esta é a fase durante a qual são traduzidos em requisitos especificaçãos.

Projeto inclui a projeto da aplicação em si, eo design do ambiente, ou
operacional modelo que a aplicação tem que correr. Considerações de
arquitectura é o aspecto mais importante desta fase, uma vez que eles podem
impacto sobre a estrutura eo conteúdo de ambos aplicação e modelo
operacional. Considerações de arquitetura para a aplicação (projeto da
arquitetura do aplicativo) e considerações arquitetônicas para o operação
modelo (projeto da arquitetura do sistema) estão fortemente relacionados e
precisam ser alinhados.
No caso de aquisição de software, a maioria das organizações não será

permitida a entrada direta para o design do software (o qual já tenha sido
construído). No entanto, é importante que o Gerenciamento de aplicativo é
capaz de fornecer feedback para o fornecedor de software sobre a
funcionalidade de gerenciamento e atuação do software. Isto irá, por sua vez,
ser assumida pelo fornecedor do software, como parte de um aperfeiçoamento
do software.
Parte da avaliação processo para o software adquirido deve incluir uma

avaliação de se o vendedor é sensível a tais comentários. Ao mesmo tempo,
devem assegurar que existe um equilíbrio entre ser sensível e mudando o seu

software de tal forma que é perturbador ou que muda algumas funcionalidades
básicas.
Design para software adquirido também irá incluir o projeto de qualquer

personalização que é necessário. De especial importância aqui é avaliar se o
futuro versão do software irá apoiar a personalização.
6.5.4.3 Construção
No Construir fase, tanto a aplicação e do modelo operacional estão prontas para

implantação. Aplicação componentes são codificados ou adquirida, integrado e
testado.
Por favor note que Teste não é uma fase separada no ciclo de vida, Ainda que
seja um discreto atividade, E mesmo que os testes são realizados de forma
independente de ambos os desenvolvimento e atividades operacionais. Sem a
criar e implantar as fases, não haveria nada de testar e, sem testes, não haveria
controle sobre o que é desenvolvido e implantado.
O teste é um componente integral de ambos os criar e implantar as fases, como

um validação do atividade e saída das referidas fases - mesmo que utiliza
diferentes ambientes e pessoal. Teste em fase de desenvolvimento concentra-se
em saber se o pedido preenche sua funcionalidade e especificações de
gerenciamento. Muitas vezes, a distinção entre uma e desenvolvimento
ambiente de teste. O ambiente de teste permite testar a combinação da
aplicação e do modelo operacional. O teste é coberto na publicação Transição
de Serviço ITIL.
Para o software comprado, isso vai envolver a compra real da aplicação,

qualquer exigido middleware eo relacionado ao hardware e equipamentos de
rede. Qualquer personalização que é necessária terá de ser feita aqui, como se
verá a criação de tabelas, categorias, etc, que irá ser utilizado. Isto é feito muitas
vezes como um piloto implementação pelo relevante Aplicação de Gestão de
equipe ou departamento.
6.5.4.4 Implantar
Nesta fase, tanto a operacional modelo e a aplicação são implantados. O

modelo operativo é incorporado no ambiente de TI existente e a aplicação é
instalada na parte superior do modelo de operação, utilizando o Gerenciamento
de Liberação e Implantação processo descrito na ITIL Transição de Serviço
publicação.
Teste também acontece durante esta fase, embora aqui a ênfase está em
garantir que o processo de implantação e os mecanismos de trabalhar de forma
eficaz, por exemplo, testar se o aplicativo ainda funçãos para especificação

depois de ter sido baixado e instalado. Isto é conhecido como Life Support cedo
e cobre um período de garantia pré-definido que a validação, testes e
monitoramento de uma nova aplicação ou serviço durante esse período, ocorre.
Suporte início da vida é abordada em detalhes na publicação Transição de
Serviço.
6.5.4.5 Operar
Na fase de operar, o De serviços de TIsorganização opera o aplicativo como

parte da prestação de um serviço exigido pela empresa. O atuação de aplicação
em relação ao serviço total é medido continuamente contra o Nível de Serviços e
de negócios-chave motoristas. É importante distinguir que os aplicativos em si
não equivale a um serviço. É comum em muitas organizações, para se referir a
aplicações como 'serviços', no entanto, as aplicações são apenas um
componente muitos dos necessários para fornecer uma serviço de negócio.
A fase Operate não é exclusiva de aplicações e é discutido ao longo desta

publicação, com uma lista mais detalhada das atividades mencionadas na seção
6.5.5 abaixo.
6.5.4.6 Otimizar
No Otimizar fase, os resultados do nível de serviço atuação medições são

medidos, analisados e tratados. Possíveis melhorias são discutidas e
desenvolvimentos iniciado, se necessário. As duas estratégias principais nesta
fase são para manter e / ou melhorar a Nível de Serviços e para baixar custar.
Isso poderia levar a iteração no ciclo de vida ou à aposentadoria justificada de
um aplicativo.
Uma coisa importante a lembrar sobre o Aplicação de Gestão de Ciclo de Vida é

que, uma vez que é circular, a mesma aplicação pode residir em diferentes fases
do ciclo de vida, ao mesmo tempo. Por exemplo, quando o próximo versão de
um aplicativo está sendo projetado, ea versão atual está sendo implantado, a
versão anterior ainda pode ser em operação em partes de uma organização.
Isto, obviamente, requer a versão forte, configuração e liberar controlar.
Determinadas fases pode demorar mais ou parecem mais significativos do que

outros, mas todos eles são cruciais. Cada aplicação tem de passar por todos
eles, pelo menos, uma vez e, por causa da natureza circular do ciclo de vida, vai
passar por um pouco mais do que uma vez.
Esta abordagem também suporta iterativo abordagens de desenvolvimento,

onde o software está sendo continuamente desenvolvidas em passos
incrementais. Cada passo segue o ciclo de vida e que o aplicativo é construído
em incrementos, com as prioridades de negócios como motorista.

Uma boa comunicação é a chave como um aplicativo funciona seu caminho
através das fases do ciclo de vida. É crítico que a altaqualidade informação é
repassada por aqueles lidar com a aplicação em uma fase da sua existência
para aqueles que manipulam-lo na próxima fase. Também é importante que a
organização monitora a qualidade do Lifecycle Management Application.
Alterações no ciclo de vida, por exemplo, na forma de uma organização
transfere as informações entre as diferentes fases, irá afectar a sua qualidade.
Compreender as características de cada fase do ciclo de vida de gerenciamento
de aplicativos é crucial para a melhoria da qualidade da totalidade. Métodos e
ferramentas utilizadas em uma fase pode ter um impacto em outros, enquanto a
optimização de uma fase pode sub-otimizar o todo.
6.5.5 Aplicação de Gestão de actividades de carácter genérico
Enquanto a maioria Aplicação de Gestão de equipes ou departamentos são

dedicados a específica aplicaçãos ou conjuntos de aplicativos, há uma série de
actividades que têm em comum. Estes incluem:
• Identificar o conhecimento ea experiência necessários para gerenciar e

operar aplicações na entrega de De serviços de TIs. Este processo
começa durante a Estratégia de Serviço fase, é expandido em detalhe em
Design de Serviços e é realizado em Operação de Serviço. Contínuo
avaliação e atualização destas competências são feitas durante Melhoria
de Serviço Continuada.
• Iniciando treinamento programas para desenvolver e refinar as
habilidades no gerenciamento de aplicativos apropriado recursos e
treinamento manter registros para estes recursos.
• O recrutamento ou contratação recursos com habilidades que não podem
ser desenvolvidas internamente, ou onde há pessoas suficientes para
realizar as atividades de gestão necessárias Aplicação.
• Concepção e execução de fim-usuário treinamento. O treinamento pode
ser desenvolvido e entregue tanto pelo desenvolvimento de aplicativos ou
grupos de gerenciamento de aplicativos, ou por um terceiro, Mas
Aplicação de Gestão de é responsável por assegurar que o treinamento é
realizado conforme o caso.
• Insourcing para atividades específicas, onde as habilidades necessárias
não estão disponíveis internamente ou no mercado aberto, ou onde ela é
mais custo-eficiente para fazer isso.
• Definição de padrãos utilizados no projeto de novas arquiteturas e
participação na definição de aplicação arquiteturas durante os processos
de estratégia de serviço.
• Pesquisa e Desenvolvimento de soluções que podem ajudar a expandir o
portfólio de serviços, ou que pode ser usado para simplificar ou
automatizar Operações de TI, Reduzir custars ou aumentar os níveis de
serviço de TI.

• Participação na concepção e construção de novos serviços. Todas as
equipes ou departamentos Application Management irá contribuir para a
concepção das normas técnicas Arquitetura e desempenho para serviços
de TI. Além disso, eles também será responsável por especificar a
operacional atividades necessárias para gerenciar as aplicações em uma
base contínua.
• Envolvimento em projetos, não só durante o projeto do Serviço de
processo, Mas também para Melhoria de Serviço Continuada ou projetos
operacionais, tais como atualizações do sistema operacional, servidor
projetos de consolidação ou movimentos físicos.
• Concepção e realização de testes para a funcionalidade, atuação e
gerenciamento de serviços de TI (tendo em conta que o teste deve ser
controlada e realizada por um laboratório independente - veja Transição
de Serviço publicação).
• Disponibilidade e Gerenciamento da Capacidade são dependentes de
Gerenciamento de Aplicativos para contribuir para a concepção de
aplicações para atender os níveis de serviço exigidas pela empresa. Isto
significa que, modelagem e carga de trabalho previsão são muitas vezes
feito em conjunto com técnicas e de gestão de aplicativos.
• Assistência na avaliação risco, Identificando o serviço e críticas sistema
dependências e definição e implementação de contramedidas.
• Gestão de fornecedores. Muitos Aplicação de Gestão de departamentos
ou grupos são os únicos que sabem exatamente o que é exigido de um
fornecedor e como medir e gerenciá-los. Por esta razão, muitas
organizações dependem de Gerenciamento de Aplicativos para gerenciar
contratos com fornecedores de específico aplicaçãos. Se este for o caso,
é importante para assegurar que estes relaçãos são gerenciados como
parte do SLM processo.
• Envolvimento na definição de Gestão de Eventos padrãos e,
especialmente, na instrumentação de aplicações para a geração de
significativa eventos.
• Gerenciamento de Aplicativos como um função fornece o recursos que
executam o Gerenciamento de Problemas processo. É a sua competência
técnica e conhecimento que é usado para diagnosticar e resolver
problemas. É também a sua relação com os vendedores que são usados
para escalar e acompanhamento com as equipes de apoio de
fornecedores ou departamentos.
• Recursos de gerenciamento de aplicativos estarão envolvidos na
definição de sistemas de codificação que são usados em Gestão de
Incidentes e Problemas (Categorias por exemplo incidente).
• Recursos de gerenciamento de aplicativos são utilizados para apoiar
Gerenciamento de Problemas na validação e manutenção da BDEC
conjunto com as equipes de desenvolvimento de aplicativos.
• Gestão da Mudança depende do conhecimento técnico e experiência
para avaliar as mudanças e muitas mudanças serão construídos por
equipes de gerenciamento de aplicativos.

• Bem sucedido Gerenciamento de Liberação depende de envolvimento da
equipe de gerenciamento de aplicativos. Na verdade, eles são
freqüentemente a motoristas da Gerenciamento de Liberação processo
para suas aplicações.
• Aplicação de Gestão vai definir, gerir e manter atributos e os
relacionamentos de IC aplicação no CMS.
• Aplicação de Gestão está envolvido na Melhoria de Serviço Continuada
processos, especialmente na identificação de oportunidades de melhoria
e, em seguida, para ajudar a avaliar as soluções alternativas.
• Aplicação de Gestão assegura que todo o sistema operacional e
documentação está atualizada e devidamente utilizado. Isto inclui
assegurar que todos os projeto, Gestão e usuário manuais estão em dia e
concluir e que a equipe de gerenciamento de aplicativos e usuários estão
familiarizados com seu conteúdo.
• Colaboração com Gestão Técnica sobre a realização de Análise de
necessidades de formação e manutenção de estoques de Habilidades.
• Auxiliar de TI Gestão Financeira para identificar o custar do
gerenciamento contínuo de aplicações.
• Envolvimento na definição do operacional atividades realizadas como
parte de TI Gestão de Operações. Muitos departamentos de aplicativos
de gestão, grupos ou equipes também executam as atividades
operacionais, como parte de um organização'S TI Gestão de Operações
função.
• Introduzidos e manutenção de, software configuração políticas.
• Juntamente com as equipes de desenvolvimento de software, a definição
e manutenção de documentação relacionada com as aplicações. Estes
incluirão usuário manuais de administração e gestão de manuais, bem
como quaisquer POPs necessários para gerenciar operacional aspectos
da aplicação.
Aplicação de Gestão de equipes ou departamentos serão necessários para

todas as aplicações-chave. A natureza exata do papel irá variar, dependendo
das aplicações sendo suportados, mas as responsabilidades genéricas são
susceptíveis de incluir:
• Terceiro nível de suporte de incidentes relacionados com a aplicação (s)

coberto por essa equipe ou departamento
• Envolvimento em operação teste planos e desenvolvimento questões
• Rastreamento de bugs e aplicação de gerenciamento de patches
(correções para codificação em casa código, transportes / patches para
código de terceiros)
• Envolvimento na operacionalidade aplicação e problemas de suporte, tais
como erro projeto do código, erro de mensagens, gestão de eventos
ganchos

• Aplicação dimensionamento e atuação, Volume métricos e etc testes de
carga Este é em apoio de Capacidade e Gerenciamento de
Disponibilidade processos
• Envolvimento no desenvolvimento Solte Políticas
• Identificação de melhorias para o software existente, tanto a partir de uma
perspectiva de funcionalidade e capacidade de gerenciamento.
6.5.6 Aplicação de Gestão de organização
Apesar de todos os departamentos Application Management, grupos ou equipes

de atividades similares, cada aplicação ou conjunto de aplicações tem um
conjunto diferente de gestão e operacionais exigências. Os exemplos de tais
diferenças incluem:
• A finalidade da aplicação. Cada aplicativo foi desenvolvido para atender

um conjunto específico de objetivos, normalmente objetivo de negócios.
Para apoio efetivo e melhoria, o grupo que gerencia esse aplicativo
precisa ter uma compreensão abrangente do contexto dos negócios e
como o aplicativo é utilizado para atender seus objetivos. Isso é muitas
vezes conseguida por analistas de negócios que estão perto de o negócio
e responsável por garantir que o negócio exigências se traduzirem em
aplicação especificaçãos. Analistas de Negócios deveriam reconhecer
que o negócio exigências deve ser traduzida em funcional e capacidade
de gerenciamento especificaçãos.
• A funcionalidade da aplicação. Cada aplicativo foi projetado para
trabalhar de uma forma diferente e para executar diferentes funçãos em
momentos diferentes.
• A plataforma em que o aplicativo é executado. Apesar de a plataforma
ser geralmente administrado por uma Gestão Técnica equipe ou
departamento, cada um deles afeta a maneira em que um aplicativo
precisa ser administrada e explorada.
• O tipo ou marca de tecnologia utilizada. Mesmo aplicações que têm
funcionalidade semelhante operar de forma diferente em diferentes
bancos de dados ou plataformas. Estas diferenças têm que ser
entendidas no sentido de gerir a aplicação eficaz.
Mesmo que as atividades para gerenciar esses aplicativos são genéricas, o

cronograma específico de atividades ea forma como eles são realizados será
diferente. Por esta razão, as equipes de Application Management e
departamentos tendem a ser organizado de acordo com as categorias de
aplicaçãos que suportam. Exemplos típicos de organizações de gestão de
aplicações incluem:
• Aplicações financeiras. Em organizações maiores onde um número de

aplicações diferentes são usados para diferentes aspectos da Gestão
Financeira, Pode haver vários departamentos, grupos ou equipas de

gestão dessas aplicações, por exemplo, Devedores e Credores e análise
da idade, General Ledger, etc
• Aplicativos de mensagens e colaboração
• Aplicações de RH
• Fabricação aplicações de suporte
• Automação da força de vendas
• Vendas de processamento de aplicações de ordem
• Call center e aplicações de marketing
• Empresas aplicativos específicos (por exemplo, cuidados de saúde,
seguros, banca, etc)
• Aplicações de TI, tais como Service Desk, Enterprise Sistema de Gestão
de, Etc
• Portais web
• Compras on-line.

6.5.6.1 papéis organizacionais
Tradicionalmente, as equipes de desenvolvimento de aplicativos e Gestão e

departamentos foram unidades autônomas. Cada um gere a sua própria
ambiente à sua maneira e cada um tem uma interface separada para o negócio.
Isto está ilustrado na Tabela 6.2.
Desenvolvimento de Aplicações Aplicação de Gestão de
Foco Funcionalidade de construção para a sua Concentre-se no que a funcionalidade

principal cliente. O que o aplicativo faz é mais é bem como a forma de entregá-lo.
importante para eles do que como ele é
operado Aspectos de gerenciamento da
aplicação, ou seja, como garantir a
estabilidade e atuação da aplicação
Modo de A maioria desenvolvimento o trabalho é Maioria do trabalho é feito como parte

gestão feito em projetos, onde o foco está em de repetíveis e processos em
fornecer unidades específicas de trabalho andamento. Um número relativamente
para especificação, No prazo e dentro pequeno de pessoas trabalham em
orçamento. projetos.
Isto significa que muitas vezes é difícil para Isto significa que é muito difícil para
os desenvolvedores a entender e construir operacional pessoal para se envolver
para as operações em curso, em projetos de desenvolvimento,
especialmente porque eles não estão como que os leva longe de seus
disponíveis para apoio do pedido, uma vez "empregos reais"
que se mudaram para o próximo projeto
Medição Funcionários são recompensados para a Funcionários são recompensados de

criatividade e para concluir um projeto para coerência e de prevenção inesperado
que eles possam passar para a próxima eventos e funcionalidade não
projeto autorizada ("sinos e assobios", por
exemplo adicionado por
desenvolvedores)
Custar Projetos de desenvolvimento são Gerenciamento contínuo custars são

relativamente fáceis de quantificar uma vez muitas vezes misturados com os
que o recursos são conhecidos e é fácil de custos de outros serviços de TI desde
vincular suas despesas para um recursos são muitas vezes
determinado aplicação ou De serviços de compartilhados entre vários serviços
TI de TI e aplicações
Ciclo de Foco de desenvolvimento pessoal em Pessoal envolvido na gestão em curso

Vidas ciclos de vida de desenvolvimento de normalmente só controlar uma ou
software, que destacam as dependências duas fases destes ciclo de vidas -
para sucesso operação, Mas não atribuir a Operação e Melhoria
responsabilidade por estes
Tabela 6.2 papéis organizacionais
Ao longo dos últimos anos, estes dois mundos estão sendo reunidos por
movimentos recentes para Object Oriented abordagens e SOA, juntamente com
a pressão crescente do negócio a ser mais ágil e fácil de trabalhar.

Isto significa que o desenvolvimento de aplicativos terá uma maior
responsabilidade para o bom funcionamento de aplicativos que projeto,
Enquanto Aplicação de Gestão de terá um maior envolvimento na
desenvolvimento de aplicações.
Isto não muda a fundamental papel de cada grupo, mas requer uma abordagem
mais integrada do SLC. Isso também significa que a saída de Desenvolvimento
de Aplicativos será mais comoditizado e que Gerenciamento de Aplicativos será
mais envolvidos em projetos de desenvolvimento.
Isso exigirá as seguintes alterações:
• Uma única interface para o negócio para todas as fases do ciclo de vida e
uma comum exigências e especificação-Definição processo.
• A mudança na forma como ambos Desenvolvimento e Gestão de pessoal
são medidos. As equipes de desenvolvimento deve ser realizada, em
parte, responsáveis por falhas de projeto que criam operacional
interrupções. Equipe de gestão deve ser realizada, em parte, responsável
pela contribuição para o técnico arquitetura eo projeto de gerenciamento
de aplicações.
• Uma única Gestão da Mudança processo para ambos os grupos, com
controle de mudanças em cada grupo sendo subordinado à autoridade
geral de Gestão de Mudança (veja Transição de Serviço publicação).
• Um mapeamento claro de Desenvolvimento e Gestão de atividades do
ciclo de vida, que é ilustrado em um alto nível na Figura 6.5. As atividades
exatas e como eles interagem deve ser definido em cada organização,
Embora alguns genérico diretrizs são dadas em cada um dos ITIL
publicações.
• Maior foco na integração de funcionalidade e capacidade de
gerenciamento exigências no início do projeto.

Figura 6.6 Papel das equipes na aplicação de gestão do ciclo de vida
A Figura 6.6 mostra uma comum Aplicação de Gestão de Ciclo de Vida com a
participação de ambos os grupos. Neste diagrama, é evidente que Aplicação
Desenvolvimento estará dirigindo algumas fases com a entrada de
Gerenciamento de Aplicativos. Em outros casos, Gerenciamento de Aplicativos
será a condução da fase com a entrada e apoio de desenvolvimento de
aplicativos. Ambos os grupos são subordinados ao TI Estratégia de Serviço do
organização e seus esforços são coordenados através Transição de Serviço
mecanismos e processos.
6.5.7 Aplicação funções de gerenciamento e responsabilidades
6.5.7.1 Aplicações Gerentes / ou chefes de equipa
Um Applications Manager ou líder de equipe (dependendo do tamanho e / ou

importância da equipe ou departamento e da aplicação que suportam, e

estrutura da organização e cultura) Serão necessários para cada uma das
equipas aplicações ou departamentos. O papel irá:
• Assumir a responsabilidade total para a liderança, controlar e tomada de

decisão para a equipe de aplicações ou departamento
• Fornecer conhecimento técnico e liderança nas atividades específicas de
aplicações de apoio abrangidos pela equipe ou departamento
• Garantir níveis técnicos necessários sensibilização, formação e
experiência são mantidos dentro da equipe ou departamento relevante
para os aplicativos que estão sendo apoiados e processos que estão
sendo usados
• Envolvem a comunicação permanente com usuários e clientes em relação
à aplicação atuação e em evolução exigências do negócio
• Relatar à alta administração sobre todas as questões relevantes para os
aplicativos que estão sendo apoiados
• Executar linha de gestão para toda a equipe ou membros do
departamento.
6.5.7.2 Aplicações Analista / Arquiteto
Analistas aplicativos e arquitetos são responsáveis por correspondência

requisitos para aplicação especificaçãos. Atividades específicas incluem:
• Trabalhando com usuários, patrocinadores e todos os outros das partes

interessadass para determinar suas necessidades em evolução
• Trabalhando com Gestão Técnica para determinar o nível máximo de
sistema requisitos necessários para cumprir os requisitos de negócios
dentro orçamento e limitações tecnológicas
• Execução de análises custo-benefício para determinar os meios mais
adequados para atender a exigência declarada
• Em desenvolvimento Operacional Modelos que vai garantir uma utilização
óptima dos recursos e o nível apropriado de desempenho
• Garantindo que os aplicativos são projetados para ser gerido de forma
eficaz dada a tecnologia da organização arquitetura, Habilidades e
ferramentas disponíveis
• Desenvolvimento e manutenção de padrãos para aplicação
dimensionamento,atuação modelagem, Etc
• Gerando um conjunto de aceitação teste exigências, em conjunto com os
designers, engenheiros de teste e os usuário, Que determinam que todos
os requisitos de alto nível foram cumpridos relativamente à funcional e
capacidade de gerenciamento
• Entrada para o projeto de configuração dados necessários para gerenciar
e rastrear o aplicação eficazmente.

Um número apropriado de analistas de aplicação serão necessários para cada
uma das equipes Application Management ou departamento para realizar as
atividades genéricas descritas no parágrafo 6.5.5.
As formas em que Aplicação de Gestão de grupos podem ser organizados, e as

opções disponíveis, são discutidos em detalhe na seção 6.7 abaixo.
6.5.8 Gestão de métricas de aplicação
Métricos para Gerenciamento de Aplicativos dependerá em grande parte os

aplicativos que estão sendo gerenciados, mas algumas métricas genéricas
incluem:
• Medição de resultados acordados. Estas podem incluir:

• Capacidade dos usuários de acessar o aplicativo e sua
funcionalidade
• Relatórios e arquivos são transmitidos para os usuários
• Transação taxas e disponibilidade para operações críticas de
negócios
• Service Desk treinamento
• Gravação problema resoluçãos para o BDEC
• Medidas de usuário do qualidade de saídas, tal como definidos no
SLA.
• Métricas de processo. Gestão Técnica equipes de executar Serviço de
Gerenciamento de muitos processo actividades. A sua capacidade de
fazê-lo será medida como parte do processo métricas se for o caso (ver
secção sobre cada processo para mais detalhes). Os exemplos incluem:
• O tempo de resposta para eventos e as taxas de conclusão do
evento
• Incidente resolução vezes por segundo e terceira linha de apoio
• Resolução de problemas estatísticas
• Número de liberars implantado, total e bem sucedida, incluindo a
garantia de adesão às Políticas lançamento do organização
• Questões de segurança detectados e resolvidos
• Real sistema utilização contra Plano de capacidade previsões
(onde a equipe tem contribuído para a desenvolvimento do plano)
• Aplicação atuação. Estes métricos são baseados Design de Serviços
especificaçãos e desempenho técnico padrãos definir por fornecedores e
normalmente será contida OLAs ou SOPs. Métricas reais variam de
acordo com a aplicação, mas é provável que incluem:
• O tempo de respostas

• Aplicação disponibilidade, Que é útil para medir a equipe ou
aplicação desempenho, mas não deve ser confundido com
disponibilidade de serviço - o que requer a capacidade para medir
a disponibilidade geral do serviço, e pode utilizar os dados de
disponibilidade para um número de indivíduos sistemas ou
componentes
• Integridade de dados e relatórios.
• Medição de manutenção atividade, Incluindo:
• Aplicação de Gestão de equipes são propensos a trabalhar em estreita
colaboração com as equipes de desenvolvimento de aplicativos em
projetos, E as métricas apropriadas devem ser usados para medir esta,
incluindo:
• Tempo gasto em projetos
• Cliente e usuário satisfação com a saída do projecto
• Custo de participação no projeto.
• Treinamento e desenvolvimento de competências. Essas métricas
garantir que a equipe tem as habilidades e treinamento para gerenciar a
tecnologia que está sob a sua controlar, E também identificar as áreas em
que a formação ainda é necessária.
6.5.9 documentação Gerenciamento de Aplicativos
Um certo número de documentos são produzidos e utilizados durante

Gerenciamento de Aplicativos. Esta lista é um resumo de alguns dos mais
importantes e não inclui relatórios ou documentos que são produzidos por
Gerenciamento de Aplicativos em nome de outro processo ou funçãos (por
exemplo, RFC, Erro Conhecido documentação, Registro de Lançamentos, etc.)
Note que os documentos devem ser controladas como IC e relacionado com as
aplicações relevantes ou equipes de gerenciamento de aplicativos.
6.5.9.1 Application Portfolio
O Application Portfolio é usado primariamente como parte de Estratégia de

Serviço, Mas é referenciado aqui para ser completo. O portfólio de aplicativos é
uma lista (mais precisamente um sistema ou banco de dados) de todos os
aplicativos em uso dentro do organização, Em conjunto com as seguintes
informações:
Chave atributos da aplicação
• Clientes e os utilizadores
• Finalidade comercial
• Nível de importância do negócio

• Arquitetura (Incluído o Infraestrutura de TI dependências)
• Desenvolvedores, grupo de apoios, fornecedors ou fornecedores
• O investimento feito no aplicação até o momento. A este respeito, a
carteira de aplicações pode ser utilizada como um ativos registo para as
aplicações,
O objetivo do portfólio de aplicativos é analisar a necessidade eo uso de

aplicações no organização. Ele pode ser usado para ligar a funcionalidade e de
investimento para negócios atividade e é, portanto, uma parte importante do
curso de TI planejamento e controlar. Outro benefício da Carteira de aplicação é
que ele pode ser usado para identificar a duplicação e licenciamento excessivo
de aplicações.
A Carteira de Aplicação faz parte do total De serviços de TI Carteira, que é

discutida em detalhe na Estratégia de Serviço publicação.
O portfólio de aplicativos e do Catálogo de Serviços
A Carteira do aplicativo não deve ser confundido com o Catálogo de Serviço e

não deve ser anunciado como uma lista de serviços para clientes ou usuários.
Os aplicativos são um dos componentes usado para fornecer serviços de TI,
geralmente não os serviço si.
O portfólio de aplicativos deve, portanto, ser usado como um documento de

planejamento apenas pelos gerentes e funcionários que estão envolvidos com o
desenvolvimento e gestão da estratégia de TI da organização, bem como a
equipe de TI, que têm a tarefa de gerir as aplicações ou as plataformas em que
os aplicativos são executados.
O Catálogo de Serviços deve se concentrar em listar os serviços que estão

disponíveis, em vez de simplesmente listar aplicações e assumindo que os
usuários e clientes podem fazer a ligação. Dito isto, há momentos em que a
aplicação é sinônimo de serviço, por exemplo de processamento de aplicativos
são normalmente conhecido por seu nome, um pedido de serviço de
hospedagem irá mencionar os nomes dos hospedado aplicação, etc
6.5.9.2 Requisitos da Aplicação
Há dois conjuntos de documentos que contêm exigências para aplicações:
• Requisitos de Negócio delinear o Business Case para a aplicação

desejada, em outras palavras, o que a empresa vai fazer com a
aplicação. Isso irá incluir o retorno sobre o investimento para a aplicação,
bem como todas as melhorias relacionadas ao negócio. Requisitos de
negócios também incluem a Exigência de Nível de Serviços, tal como
definido pelos clientes e utilizadores de serviços.

• Requisitos da Aplicação documentos baseiam-se nos requisitos de
negócio e especificar exatamente como a aplicação irá atender a esses
requisitos. Em resumo, os documentos de requisitos de aplicação reunir
informações que serão utilizadas para nova comissão aplicaçãos ou
alterações nos aplicativos existentes, por exemplo:
• Para projeto o arquitetura da aplicação (especificação dos
diferentes componentes da sistema, Como eles se relacionam
entre si e como eles serão geridos)
• Para especificar uma Request for Proposal (RFP) para um
Comercial Off the Shelf (COTS) aplicação
• Para iniciar o projeto e construção de uma aplicação em casa.
Requisitos documentos são normalmente de propriedade de um projeto líder, ou

de um desenvolvimento equipe do projeto, ou para uma equipe de elaboração
das especificações para uma RFP. Exigênciadocumentos s estão sujeitos a
documento controlar para o projeto, que fazem parte do total escopo do projeto.
Quatro tipos diferentes de Aplicação Exigências precisam ser definidos (para

informações mais detalhadas, por favor consulte o ITIL Design de Serviços e
Transição de Serviço publicações):
• Requisitos Funcionais descrever as coisas de um pedido se destina a

fazer, e pode ser expressa como serviços, tarefas ou funçãos a aplicação
é necessário para executar.
• Requisitos de gerenciamento são usados para definir o que é
necessário para gerenciar a aplicação ou para garantir que ele executa as
funções necessárias de forma consistente e no nível certo. Capacidade
de gerenciamento também identificar constrangimentos de TI sistema.
Estes requisitos de servir como base para o dimensionamento do sistema
inicial e estimativas de custar, E pode apoiar o avaliação da viabilidade do
sistema de TI proposto. Mais importante, eles dirigem projeto do
operacional modelos e atuação padrãos utilizado em TI Gestão de
Operações.
• Usabilidade Requisitos são normalmente especificados pelo usuários do
pedido, e referem-se a sua facilidade de uso. Quaisquer requisitos
especiais para usuários com deficiência também precisam ser
especificados aqui.
• Requisitos de Teste especificar o que é necessário para assegurar que
o teste ambiente é representativa do ambiente operacional, e que o teste
é válido (ou seja, que realmente testa o que é suposto).
6.5.9.3 mudanças de uso e Casos
Use e Caso alteres são gerenciados como parte do projeto do Serviço e

Melhoria de Serviço Continuada processos, mas são mantidas pela Aplicação de

Gestão de. Para o software comprado, é comum para a equipe que desenvolve
as especificações funcionais para manter a Caso de Uso para essa aplicação.
• Casos de Uso documentar o uso pretendido do aplicativo com cenários

da vida real para demonstrar seus limites e as suas funcionalidades.
Casos de uso podem também ser usados como modelagem e
dimensionamento cenários e para facilitar a comunicação entre usuários,
desenvolvedores e pessoal de Gerenciamento de Aplicativos.
• Alterar Casos usar cenários para prever o impacto de possíveis
mudanças na arquitetura, utilização ou funcionalidade e projeto o impacto
do específico mudar cenários. Casos de Mudança são usadas para
esclarecer escopo ea direção com o patrocinador. Arquitetura extra e
trabalho de design será necessária neste momento para garantir a Caso
alteres podem ser atendidas no futuro a razoável custar. O patrocinador
deve estar preparado para pagar o custo extra. Se não, os Casos de
Mudança deve ser reduzida para que o patrocinador está preparado para
pagar. Casos de Mudança também são utilizados para avaliar a
arquitetura. Eles influenciam a desenvolvimento processo permitindo o
projeto da apropriadas características arquitetônicas para minimizar o
impacto de mudanças futuras.
Para mais informações, consulte o ITIL Design de Serviços e Melhoria de

Serviço Continuada publicações.
6.5.9.4 documentação de projeto
Este não é um específico documento, Mas refere-se a qualquer documento

produzido pelo desenvolvimento de aplicativos ou a equipe de gerenciamento
que especifica como uma aplicação será construído. Como esses documentos
geralmente são possuídos e geridos por equipes de desenvolvimento, esta
publicação não cobri-los em detalhe. No entanto, para assegurar o êxito
operação, Gerenciamento de Aplicativos deve assegurar que a documentação
projeto contém:
• Dimensionamento especificaçãos
• Workload perfis e as previsões de utilização
• Técnico de Arquitetura
• Dados modelos
• Codificação padrãos
• Os padrões de desempenho
• Software Gerenciamento da Configuração definições
• Ambiente definições e considerações de construção (se for o caso).
Para aplicações COTS, estes documentos assumir a forma de aplicação

Especificaçãos que são utilizados como entrada para a escrita de RFPs. Nestes

casos, os documentos são de propriedade e gerido pela Aplicação de Gestão
de.
Para mais informações sobre documentação de projeto, consulte a publicação

Projeto ITIL Service.
6.5.9.5 Manuais
Application Management é responsável pela gestão de manuais para todas as

aplicações. Embora estes são normalmente desenvolvidas pelas equipes de
desenvolvimento de aplicativos ou terceiro fornecedors, Gerenciamento de
Aplicativos é responsável por garantir que os manuais são relevantes para a
operacional versãos das aplicações.
Três tipos de manuais são geralmente mantidas pela Administração Aplicação:
• Manuais de design contêm informações sobre a estrutura e arquitetura

do aplicativo. Estes são úteis para a criação de relatórios ou a definição
evento regras de correlação. Eles também podem ajudar no diagnóstico
problemas.
• Manuais de administração ou de direcção descrever as atividades
necessárias para manter e operar a aplicação nos níveis de atuação
especificada na fase de projeto. Estes manuais também irá fornecer
solução de problemas detalhada, Erro Conhecido e descrições de falhas,
e passo-a-passo as instruções para tarefas comuns de manutenção.
• Manuais de usuário descrever a funcionalidade do aplicativo, uma vez
que é usado por um fim-usuário. Estes manuais contêm passo-a-passo
sobre como usar o aplicação, Bem como descrições do que normalmente
deve ser inserido em determinados campos, ou o que fazer se houver
uma erro.
Manuais e Procedimento Operacional Padrãos
Manuais não deve ser vista como um substituto para PHF, mas como entrada
para os PON.
Os POPs devem conter todos os aspectos de aplicações que precisam ser

gerenciados como parte das operações normais. Se eles não são extraídos dos
manuais, existe uma grande probabilidade de que eles serão ignorados ou
realizados de uma forma não-padrão. Aplicação de Gestão de deve garantir que
tais instruções são extraídas dos manuais e inserido documentação SOP
separado para Operações. Também é responsável por garantir que estas
instruções são atualizados a cada mudar ou novos liberar do software.

6,6 Serviço de Operação papéis e responsabilidades
A chave para ITSM eficiente é assegurar que há uma responsabilidade clara e
papéis definidos para efectuar a prática de Operação de Serviço. Um papel é
muitas vezes ligada a um descrição do trabalho ou trabalhar descrição do grupo,
mas não necessariamente precisa ser preenchido por um indivíduo. O tamanho
de um organização, Como ela está estruturada, a existência de parceiros
externos e outros fatores influenciam como os papéis são atribuídos. Se uma
determinada função é preenchida por um único indivíduo ou compartilhadas
entre dois ou mais, o importante é a consistência da prestação de contas e
execução, juntamente com a interação com outras funções na organização.
6.6.1 Posto de Serviço papéis
As funções que se seguem são necessários para o Service Desk.
6.6.1.1 Service Desk Manager
Em organizações maiores onde o atendimento é de dimensão significativa, um

serviço de função Desk Manager pode ser justificada com o Supervisor de
Service Desk (s) reportar a ele ou ela. Em tais casos, esse papel pode assumir a
responsabilidade por algumas das atividades listadas acima, e pode ainda
realizar as seguintes atividades:
• Gerenciar as atividades secretária geral, incluindo os supervisores

• Atuar como mais um escalada ponto para o supervisor (s)
• Assumir uma maior cliente-Serviços de papel
• Relatório para gerentes seniores em qualquer problema que poderia
significativamente impacto o negócio
• Assistir Alterar Conselho Consultivo reuniões
• Assumir total responsabilidade pelas incidente e Solicitação de Serviço
manipulação no Service Desk. Isto também pode ser expandido para
qualquer outra atividade assumida pelo Service Desk - por exemplo
monitoramento certas classes de evento.
Nota: Em todos os casos, claramente definida descrição do trabalhos deve ser

elaborado e acordado para que responsabilidades específicas são conhecidos.
6.6.1.2 Supervisor de Service Desk
Em mesas muito pequenas, é possível que o idoso Service Desk Analista

também vai atuar como Supervisor - mas em mesas maiores, é provável que um
Supervisor de Posto de Serviço dedicado papel será necessário. Onde deslocar
horas ditam, pode haver dois ou mais pós-titulares que cumprem o papel,
geralmente em uma base de sobreposição. O papel do supervisor é provável
que incluem:

• A garantia de que os níveis de pessoal e habilidade são mantidas ao
longo operacional horas de gestão deslocar horários de pessoal, etc
• Realização de atividades de RH como necessário
• Atuando como um escalada apontar onde as chamadas difíceis ou
controversas são recebidos
• Produção de estatísticas e relatórios gerenciais
• Representando o Service Desk em reuniões
• Organizando formação e sessões de sensibilização
• Ligação com a gerência sênior
• Ligação com Gestão da Mudança
• Realizar briefings para equipe de Service Desk em mudanças ou
desenvolvimentos que podem afetar volumes no Service Desk
• Auxiliar analistas no fornecimento suporte de primeira linha quando carga
de trabalhos são elevados, ou em que a experiência adicional é
necessária.
6.6.1.3 Posto de Serviço Analistas
O principal papel do Analista de Serviço de Recepção é o de fornecer suporte de

primeiro nível através da adopção de chamadas e lidar com os incidentes
resultantes ou Solicitação de Serviços usando o Relatório de Incidentes e
Cumprimento de Requisição processos, em conformidade com a objetivos
descritas anteriormente. O número exato de funcionários requerida é discutida
no ponto 6.2.4.1.
6.6.1.4 Superusuários
Super Users são discutidos em detalhes na seção de pessoal Service Desk no

ponto 6.2.4. Em resumo, este papel será, de negócio usuários que atuam como
pontos de ligação com TI em geral e do Service Desk, em particular. O papel do
Superusuário pode ser resumido como se segue:
• Para facilitar a comunicação entre a TI e os negócios a nível operacional

• Para reforçar expectativas dos usuários em relação ao que Nível de
Serviços foram acordados
• Formação de pessoal para os usuários em sua área
• Fornecendo suporte para incidentes menores ou no cumprimento simples
pedido
• Envolvimento com o novo liberars e lançamentos.
6.6.2 Técnicas funções de gerenciamento
A seguir papels são necessários no Gestão Técnica áreas
6.6.2.1 Os gerentes técnicos / ou chefes de equipa

A Gerente Técnico ou líder de equipe (dependendo do tamanho e / ou
importância da equipe e do organizaçãoEstrutura 's e cultura) Pode ser
necessário para cada uma das equipas técnicas ou departamentos. O papel vai:

decisão para a equipe técnica ou do departamento
• Fornecer conhecimento técnico e liderança nas áreas técnicas
específicas abrangidas pela equipe ou departamento
experiência são mantidos dentro da equipe ou departamento
• Relatório para a gerência sênior em todas as questões técnicas
relevantes para a sua área de responsabilidade
departamento.
6.6.2.2 Os analistas técnicos / Arquitetos
Este termo refere-se a qualquer membro da equipe de Gestão Técnica, que

realiza as atividades enumeradas no parágrafo 6.3.3, excluindo o dia
operacional ações, que são realizadas por operadores em qualquer técnica ou TI
Gestão de Operações. Com base na lista de atividades genéricos no ponto
6.3.3, o papel dos Analistas Técnicos e Arquitetos inclui:
• Trabalhando com usuários, patrocinadores, Aplicação de Gestão de e

todos os outros das partes interessadass para determinar suas
necessidades em evolução
• Trabalhando com o Gerenciamento de Aplicativos e outras áreas de
Gestão Técnica para determinar o nível mais alto de sistema exigências
necessárias para cumprir as exigências dentro orçamento e limitações
tecnológicas
• Definir e manter o conhecimento sobre como os sistemas estão
relacionados e garantir que as dependências são compreendidos e
geridos de acordo
adequados para atender aos requisitos estabelecidos
• Desenvolver Operacional Modelos que vai garantir uma utilização óptima
dos recursos e o nível apropriado de atuação
• Garantir que a infra-estrutura está configurado para ser gerido de forma
eficaz dada a tecnologia da organização arquitetura, Habilidades e
ferramentas disponíveis
• Garantir o desempenho consistente e confiável da infra-estrutura para
entregar o nível de serviço necessário para o negócio
• Definir todas as tarefas necessárias para gerenciar a infra-estrutura e
garantir que essas tarefas são realizadas de forma adequada
e controlar a aplicação eficaz.

As formas em que Gestão Técnica podem ser organizados, e as opções
disponíveis, são discutidos em detalhe na seção 6.7.
6.6.2.3 Operador Técnico
Este termo é usado para se referir a qualquer agente que exerce no dia-a-dia
operacional tarefas na gestão técnica. Normalmente, essas tarefas são
delegadas a um dedicado Operações de TI equipe, e isso papel é, portanto,
discutido no parágrafo 6.6.3.4 Operadores de TI.
6.6.3 Operações de TI funções de gerenciamento
As seguintes funções e necessárias no TI Gestão de Operações área:
6.6.3.1 TI Gerente de Operações
Um gerente de operações de TI serão necessários para assumir total

responsabilidade por toda a TI Gestão de Operações atividades, que incluem:
• Operações de controle, Que supervisiona a execução e monitoramento

das atividades operacionais no Infraestrutura de TI. Isto pode ser feito
com o auxílio de um Operações Ponte ou Centro de Operações de Rede.
Além de executar as tarefas de rotina de todas as áreas técnicas,
Controle de Operações também executa as seguintes tarefas específicas:
• Console de Gerenciamento de, Que se refere à definição de
observação central e monitoramento capacidade e em seguida,
usando os consoles para exercer o acompanhamento e controlar
atividades
• Job Scheduling, Ou a gestão de trabalhos em lote de rotina ou
scripts
• Faça backup e Restaurar em nome de todos os técnicos e equipes
de gerenciamento de aplicativos ou departamento e, muitas vezes,
em nome da usuários
• De impressão e gestão de saída para a recolha e distribuição de
toda a impressão centralizada ou saída eletrônica.
• Gestão de Instalações, Que se refere à gestão da TI física ambiente,
Normalmente um Centro de Dados ou salas de informática e recuperação
locais, juntamente com toda a potência e equipamentos de refrigeração.
Facilities Management também inclui a coordenação de grande escala de
consolidação projetos, por exemplo, consolidação de data centers ou
servidor projetos de consolidação. Em alguns casos, a gestão de um
Centro de Dados é terceirizado, no qual Facilities Management caso
refere-se à gestão do terceirização contrato.
O papel do Operações de TI Gerente é:

• Fornecer liderança geral, controle e tomada de decisões e assumir a
responsabilidade pelas equipes de TI e departamento de Gestão de
Operações
• Relatório para a gerência sênior em todas as questões de TI Operações
• Executar linha de gestão para todos Operações de TI equipe ou
departamento gerentes / supervisores.
6.6.3.2 Líderes Turno
Muitas áreas de TI Operações irá trabalhar horas extras - em cada um de dois

ou trêsdeslocar base. Em tais casos, uma deslocar líder será necessário em
cada um dos turnos, para executar as seguintes atividades:

decisões durante o período de mudança
• Garantir que todas as operacional atividades são realizadas de forma
satisfatória dentro de prazos acordados, e de acordo com as políticas da
empresa e procedimentos
• Cooperar com o chefe de turno outro (s) para assegurar entrega,
continuidade e coerência entre os turnos
• Atuar como gerente de linha para todos os Analistas de Operações em
seu / sua mudança
• Assumir a saúde geral e a segurança, e segurança responsabilidade para
a mudança (a menos que especificamente designada para outros
membros da equipe).
6.6.3.3 Operações de TI Analistas
Analistas de TI são Operações de TI sênior equipe de operações que são

capazes de determinar a maneira mais eficaz e eficiente para realizar uma série
de operações, geralmente em alto volume, diversificada ambientes.
Este papel normalmente é realizada como parte de Gestão Técnica, Mas

grandes organizações podem achar que o volume ea diversidade de atividades
operacionais requer um pouco mais de profundidade em planejamento e
execução. Exemplos incluem Job Scheduling e a definição de uma cópia de
segurança estratégia e agendar.
6.6.3.4 Operadores de TI
Operadores de TI são os funcionários que realizam as atividades do dia-a-dia

operacionais que são definidas no Técnico ou Aplicação de Gestão de e, em
alguns casos, operações de TI analistas. Operador papéis típicos incluem:
• Executando apoios

• Operações do console, ou seja, monitoramento o estado de sistemas
específicos, filas de emprego, etc, e dando o primeiro nível de
intervenção, se apropriado
• Gerenciando dispositivos de impressão, o repovoamento com papel,
toner, etc
• Garantir que os trabalhos em lote, arquivo, etc são realizadas
• Executar trabalhos de casa programadas de manutenção, tais como
manutenção de banco de dados, arquivo de limpeza, etc
• Gravar imagens para a distribuição e instalação em novo servidors,
desktops ou laptops
• Instalação física do equipamento padrão no Centro de Dados.
6.6.4 Gestão funções de aplicativo
6.6.4.1 Aplicações Gerentes / ou chefes de equipa
Um Applications Manager ou chefe de equipa deve ser considerado para cada

um dos aplicaçãos equipes ou departamentos. O papel vai:

decisão para a equipe de aplicações ou departamento
• Fornecer conhecimento técnico e liderança nas atividades específicas de
aplicações de apoio abrangidos pela equipe ou departamento
experiência são mantidos dentro da equipe ou departamento relevante
para os aplicativos que estão sendo apoiados e processos que estão
sendo usados
• Envolvem a comunicação permanente com usuários e clientes em relação
à aplicação atuação e em evolução exigências do negócio
• Relatar à alta administração sobre todas as questões relevantes para os
aplicativos que estão sendo apoiados
departamento.
6.6.4.2 Aplicações Analista / Arquiteto
Analistas aplicativos e arquitetos são responsáveis por correspondência

requisitos para aplicação especificaçãos. Atividades específicas incluem:
• Trabalhando com usuários, patrocinadores e todos os outros das partes

interessadass para determinar suas necessidades em evolução
• Trabalhando com Gestão Técnica para determinar o nível mais elevado
de requisitos de sistema necessários para cumprir os requisitos dentro
orçamento e limitações tecnológicas
adequados para atender a exigência declarada

• Desenvolver Operacional Modelos que vai garantir uma utilização óptima
dos recursos e o nível apropriado de desempenho
• Garantir que aplicaçãos destinam-se a ser tratado eficazmente dado o
organização"Tecnologia s arquitetura, Habilidades e ferramentas
disponíveis
• Desenvolvimento e manutenção de padrãos para aplicação
dimensionamento, Desempenho modelagem, Etc
• Gerando um conjunto de aceitação teste requisitos, juntamente com os
designers, engenheiros de teste e para o utilizador, que determinam que
todos os requisitos de alto nível foram cumpridos, tanto funcionais e
capacidade de gerenciamento
e controlar a aplicação eficaz.
Um número apropriado de analistas de aplicação serão necessários para cada

um dos Aplicação de Gestão de equipes ou departamentos para realizar as
atividades descritas no restante desta publicação, principalmente no ponto 6.5.5.
As formas pelas quais os grupos de Gerenciamento de Aplicativos podem ser

organizadas, e as opções disponíveis, são discutidos em detalhes na seção 6.7.
6.6.5 Gestão de papéis de Eventos
É incomum para um organização a nomeação de um "gerente de eventos",

como eventos tendem a ocorrer em vários contextos e por muitas razões
diferentes. No entanto, é importante que Gestão de Eventos procedimentos são
coordenadas para evitar a duplicação de esforços e ferramentas. O papels da
Operação de Serviço funçãos em Gestão de Eventos são os seguintes.
6.6.5.1 O papel do Service Desk
O Service Desk normalmente não é envolvido em Gestão de Eventos, como tal,

a menos que um evento requer alguma resposta que esteja dentro do escopo do
Service Desk é definido atividade, Por exemplo, a notificação de um usuário que
um relatório está pronto. Geralmente, no entanto, este tipo de actividade é
realizada pela Operações Ponte, A menos que o Service Desk e Operações
Ponte foram combinados.
A investigação e resolução de eventos que foram identificados como sendo

Incidentes inicialmente será realizado pela Central de Serviços e, em seguida,
encaminhado para a equipe apropriada Operação de Serviço (s)
O Service Desk também é responsável pela comunicação de informações sobre

este tipo de incidente para o técnico relevante ou Aplicação de Gestão de equipa
e, se for o caso, o utilizador.

6.6.5.2 O papel do Técnico e Gerenciamento de Aplicativos
Técnica e Gerenciamento de Aplicativos desempenha vários papéis importantes,

como segue:
• Durante Design de Serviços, Eles vão participar da instrumentação do

serviço, Classificar eventos, atualizar mecanismos de correlação e
garantir que todas as respostas automáticas são definidas
• Durante Transição de Serviço eles vão testar o serviço, para assegurar
que os eventos são gerados adequadamente e que as respostas
definidas são adequadas
• Durante a Operação Serviço estas equipas normalmente executar o
gerenciamento de eventos para o sistemas sob seu controle. É incomum
para equipes de ter uma pessoa dedicada a gerenciar Gestão de
Eventos, mas cada gerente ou chefe de equipa irá assegurar que os
procedimentos adequados são definidas e executadas de acordo com a
processo e política exigências
• Técnica e Gerenciamento de Aplicativos também serão envolvidos em
lidar com incidentes e problemas relacionados com eventos
• Se as atividades de gestão de eventos são delegadas ao Posto de
Serviço ou de TI Gestão de Operações, Técnica e Gerenciamento de
Aplicativos deve garantir que os funcionários estão devidamente treinados
e que têm acesso às ferramentas necessárias para que possam
desempenhar essas tarefas.
6.6.5.3 O papel da TI Gestão de Operações
Onde Operações de TI é separado de Gestão Técnica ou aplicativo, é comum

para Monitoramento de Eventos e de primeira linha de resposta deve ser
delegada a TI Gestão de Operações. Operadores para cada área terá a tarefa
de monitoramento eventos, responder, conforme necessário, ou garantir que os
incidentes são criados conforme o caso. As instruções de como fazê-lo deve ser
incluído nos POPs para essas equipes.
Monitoramento evento é delegada ao Operações Ponte onde ele existe. O

Operações Ponte pode iniciar e coordenar, ou mesmo realizar, as respostas
exigidas pelo serviço, ou fornecer suporte de primeiro nível para aqueles
eventos, os quais geram incidente.
6.6.6 Gestão de Incidentes papéis
A seguir papels são necessários para o Gerenciamento de Incidentes processo.
6.6.6.1 Gerente de Incidentes
Um Gerente de Incidentes tem a responsabilidade de:

• Conduzir o eficiência e eficácia do Gerenciamento de Incidentes processo
• Produtor gestão da informação
• Gestão do trabalho do pessoal de apoio incidente (de primeira e segunda
linha)
• Acompanhamento da eficácia da Gestão de Incidentes e fazer
recomendações para a melhoria
• Desenvolvimento e manutenção do Gerenciamento de Incidentes
sistemas
• Gerenciando Incidente graves
• Desenvolvimento e manutenção do Gerenciamento de Incidentes
processo e procedimentos.
Em muitas organizações a papel do Gerente de Incidentes é atribuído ao

Supervisor de Service Desk - embora em grandes organizações com grandes
volumes de papel separada pode ser necessária. Em ambos os casos, é
importante que o Gestor de Incidentes é dada autoridade para gerir incidentes
eficazmente através da linha de primeiro, segundo e terceiro.
6.6.6.2 Primeira linha
Isto é coberto em detalhes no Service Desk (Secção 6.1) e não serão repetidas
aqui.
6.6.6.3 de segunda linha
Muitas organizações optam por ter um segunda linha de apoio grupo, composto
de funcionários com maior (embora ainda geral) habilidades técnicas do que o
Service Desk - e com mais tempo para se dedicar a incidente diagnóstico e
resolução sem a interferência de interrupções telefônicas.
Tal grupo pode lidar com muitos dos incidentes menos complicados, deixando
mais especialista (terceira linha) grupo de apoios para se concentrar em lidar
com mais profundas incidentes e / ou novos desenvolvimentos, etc
Quando um grupo de segunda linha é usado, muitas vezes há vantagens de

localizar este grupo próximo ao Posto de Serviço para ajudar com uma boa
comunicação e facilitar circulação de pessoal entre os grupos, que podem ser
úteis para a formação / sensibilização e durante períodos ocupados ou falta de
pessoal. A gerente de suporte de segunda linha (ou supervisor, se apenas um
pequeno grupo) normalmente dirigir este grupo.
É concebível que este grupo pode ser terceirizado - e isso é mais provável e
prático se o Service Desk si tem sido terceirizado.
6.6.6.4 Terceira linha

Terceira linha de apoio será proporcionada por um certo número de grupos
técnicas e / ou de terceiros fornecedors / mantenedores. A lista irá variar de
organização a organização, mas é provável que incluem:
• Suporte de rede
• Suporte de voz (se separar)
• Servidor Apoiar
• Suporte de mesa
• Aplicação de Gestão de - Provável que pode haver grupos separados
para diferentes aplicações ou aplicação tipos - alguns dos quais podem
ser fornecedor externo / mantenedores. Em muitos casos, a mesma
equipe será responsável pela aplicação Desenvolvimentos, bem como
suporte - e, portanto, é importante que recursos são priorizadas para que
o apoio é dado destaque adequada
• Suporte de banco de dados
• Manutenção engenheiros de hardware
• Ambientais Mantenedores Equipamentos / Fornecedores.
Nota: Dependendo de onde uma organização decide fonte seus serviços de

apoio, qualquer um dos grupos acima referidos podem ser grupos internos ou
externos.
6.6.7 A realização de papéis Pedido
Tratamento inicial da Solicitação de Serviços será realizado pelo Service Desk e

Gerenciamento de Incidentes pessoal.
Eventual cumprimento do pedido será feita pela equipe apropriada Operação de

Serviço (s) ou departamentos e / ou por fornecedores externos, conforme o
caso. Muitas vezes, Gestão de Instalações, Procurement e outros negócios
ajuda áreas no cumprimento da solicitação de serviço. Na maioria dos casos,
não haverá necessidade de adicional papels ou posts para ser criado.
Em casos excepcionais, em que um número muito elevado de solicitações de

serviços são tratados, ou onde os pedidos são de fundamental importância para
a organização, pode ser apropriado ter uma ou mais da equipe de
Gerenciamento de Incidentes dedicado ao tratamento e gestão de solicitações
de serviço.
6.6.8 Problema funções de gerenciamento
As funções que se seguem são necessários para o Gerenciamento de

Problemas processo.
6.6.8.1 Gestor Problema

Não deve ser uma pessoa designada (ou, em organizações maiores, uma
equipe), responsável pela Gestão de Problemas. Organizações menores podem
não ser capazes de justificar a tempo inteiro recurso para este papel, e pode ser
combinado com outros papéis em tais casos, mas é essencial que não é apenas
à esquerda para os recursos técnicos para executar. Não precisa ser um ponto
único de coordenação e um proprietário de processo de Gerenciamento de
Problema. Este papel será coordenar todas as atividades de Gerenciamento de
Problemas e terá a responsabilidade, para:
• Ligação com tudo problema resolução grupos para assegurar uma

resolução rápida de problemas dentro SLA alvos
• Propriedade e proteção do BDEC
• Gatekeeper para a inclusão de todos Erro Conhecidos e de gestão dos
algoritmos de busca
• Formal fecho de todos Grave problemas
• Ligação com fornecedors, empreiteiros, etc, para garantir que terceiros
cumpram as suas obrigações contratuais, especialmente no que diz
respeito à resolução de problemas e fornecendo informações de
problemas relacionados e dados
• Arranjar, execução, documentação e todas as atividades de
acompanhamento relativo à grande problema Comentes.
6.6.8.2 resolução de problemas Grupos
A resolução de problemas de real é susceptível de ser realizada por uma ou

mais técnicas grupo de apoios e / ou fornecedores ou empreiteiros de apoio -
sob a coordenação do Gestor de Problemas.
Quando um problema individual é suficientemente grave para justificar, um

dedicado gestão de problemas equipe deve ser formulado para trabalhar juntos
para superar esse problema específico. O Gerente de problema tem uma papel
a desempenhar para garantir que o número eo nível de recursos está disponível
na equipe e para escalada e comunicação na cadeia de gestão de todas as
organizações envolvidas.
6.6.9 Acesso funções de gerenciamento
Desde Gerenciamento de Acesso é uma execução de Segurança e

Gerenciamento de Disponibilidade, Estas duas áreas será responsável por
definir as funções apropriadas. É incomum para um organização a nomeação de
um "Access Manager", embora seja importante que haja um único
Gerenciamento de Acesso processo e um único conjunto de políticas relativas à
gestão direitos e acesso. Este processo e as políticas relacionadas são
susceptíveis de ser definida e mantida por Gestão de Segurança da Informação
e executado pelos diversos Operação de Serviço funçãos. As suas actividades
podem ser resumidos como se segue.

6.6.9.1 O papel do Service Desk
O Service Desk é tipicamente utilizado como um meio para solicitar acesso a um

serviço. Isso normalmente é feito através de um Solicitação de Serviço. O
Service Desk vai validar o pedido de verificação de que o pedido foi aprovado no
nível apropriado de autoridade, que o usuário é um legítimo empregado,
empreiteiro ou cliente e que se qualificam para o acesso.
Uma vez que tenha realizado essas verificações (normalmente acessando os

bancos de dados relevantes e Nível de Serviço Gestão documentos) que vai
passar a solicitação para a equipe apropriada para fornecer acesso. É bastante
comum para o Service Desk para ser delegada a responsabilidade de
proporcionar o acesso para serviços simples durante o chamar.
O Service Desk também será responsável pela comunicação com o usuário para
garantir que eles sabem quando o acesso foi concedido e para garantir que eles
recebam qualquer outro apoio necessário.
O Service Desk também está bem situado para detectar e relatar incidentes
relacionados com o acesso. Por exemplo, os usuários que tentarem acessar
serviços sem autoridade; ou usuários notificação de incidentes que indicam que
uma sistema ou serviço tem sido usado de forma inadequada, ou seja, por um
ex-funcionário que usou um antigo nome de usuário para ter acesso e fazer
alterações não autorizadas.
6.6.9.2 O papel do Técnico e Gerenciamento de Aplicativos
Técnico e Aplicação de Gestão de desempenham vários papéis importantes,

como segue:
• Durante Design de Serviços, Que irá assegurar que os mecanismos são

criados para simplificar e controlar Gerenciamento de Acesso em cada
serviço que é projetado. Eles também especificar maneiras em que o
abuso de direitos pode ser detectado e parado
• Durante Transição de Serviço eles vão testar a serviço para garantir que
o acesso pode ser concedido, controlado e evitado como projetado
• Durante Operação de Serviço essas equipes normalmente executar o
gerenciamento de acesso para os sistemas sob seu controle. É incomum
para equipes de ter uma pessoa dedicada a gerenciar Gerenciamento de
Acesso, mas cada gerente ou líder de equipe irá garantir que o
apropriado procedimentos são definidos e executado de acordo com a
processo e política exigências
• Técnica e Gerenciamento de Aplicativos também serão envolvidos em
lidar com Incidentes e Problemas relacionados ao acesso de
gerenciamento

• Se as atividades de gerenciamento de acesso são delegadas ao Service
Desk ou TI Gestão de Operações, Técnica e Aplicação de Gestão deve
assegurar que os funcionários estão devidamente treinados e que têm
acesso às ferramentas necessárias para que possam desempenhar
essas tarefas.
6.6.9.3 O papel da TI Gestão de Operações
Onde Operações de TI é separado de Gestão Técnica ou aplicativo, é comum

que operacional Acesse tarefas de gestão a ser delegada a TI Gestão de
Operações. Operadores para cada área será encarregado de fornecer ou
revogar o acesso aos sistemas-chave ou recursos. As circunstâncias em que
podem fazê-lo, e as instruções de como fazê-lo, deve ser incluída nos POPs
para essas equipes.
O Operações Ponte, Se existir, pode ser usado para monitorar eventos

relacionadas com o acesso de Gestão e pode até mesmo fornecer suporte de
primeira linha e coordenação na resolução daqueles eventos onde for
apropriado.

6,7 Serviço Organização Estruturas de Operação
Algumas informações gerais já foram apresentadas sobre considerações
organizacionais para cada função (Ver os pontos 6.2.3, 6.3.4 e 6.5.6). Esta
seção considera algumas estruturas organizacionais específicos para todas as
funções. Há uma série de maneiras de organizar a operação de serviço de
funções, e cada organização terá que tomar suas próprias decisões, com base
em sua escala, geografia, cultura e de negócios ambiente. Algumas opções são
discutidas no restante desta secção.
6.7.1 Organização pela especialização técnica
Neste tipo de organização, os departamentos são criados de acordo com a

tecnologia e as habilidades e atividades necessárias para gerenciar essa
tecnologia. Operações de TI seguirá a estrutura da técnica e os departamentos
de Gerenciamento de Aplicativos. A implicação disso é que operações de TI é
voltado para o operacional agendas do técnico e serviços de gerenciamento de
aplicações.
Esta estrutura pode funcionar bem, desde que esses grupos estão
completamente representado no Design de Serviços, Teste e melhoria de
processos, que irá garantir que suas agendas estão alinhados com o exigências
do negócio.
Essa estrutura também pressupõe que todos os departamentos técnico e

gerenciamento de aplicativos claramente a distinção entre a sua gestão
atividade e actividade operações. Ele também exige que eles têm padronizado
estes operacional atividades, para que possam ser efetivamente gerenciado pelo
Gerente de Operações de TI, sem a interferência indevida do Técnico e
Aplicação de Gestão de equipes ou departamentos.
Um exemplo de uma de Operações de TI organização estrutura baseada no

conhecimento técnico é dada na Figura 6.7

Figura 6.7 Operações de TI organizados de acordo com a especialização técnica
(amostra)
As vantagens deste tipo de estrutura organizacional incluem o seguinte.
• É mais fácil definir interna atuação objetivos desde todos os funcionários

em um único departamento tem um conjunto semelhante de tarefas em
uma tecnologia similar

• Individuais dispositivos, sistemas ou plataformas, pode ser gerido de
forma mais eficaz já que as pessoas com as competências adequadas
são dedicados a gerenciar esses e medido de acordo com o seu
desempenho
• Gestão de treinamento programas é mais fácil, pois os conjuntos de
habilidades são claramente definidas e separadas em grupos específicos.
As desvantagens deste tipo de estrutura organizacional incluem.
• Quando as pessoas são divididas em departamentos separados das

prioridades de seu próprio grupo tendem a substituir as prioridades de
outros departamentos. Um exemplo desta situação é quando
departamentos recusar aceitar a propriedade de um incidente, Cada um
culpando o outro, enquanto o negócio continua a ser interrompido.
• Conhecimento sobre a infra-estrutura e relaçãos entre componentes é
difícil coletar e fragmentada. Grupos individuais tendem a coletar e
manter apenas os dados que são necessários para apoiar a sua própria
função, E não dá acesso a ele de forma muito fácil.
• Cada tecnologia gerido por um grupo é visto como uma entidade
separada. Isso se torna um problema em sistemas que consistem de
componentes gerenciados por equipes diferentes, por exemplo, um
aplicação, Gerenciado pela equipe de Gerenciamento de Aplicativos,
executado em um servidor gerido pelo departamento de gerenciamento
de servidor, usando um segmento de rede gerenciada pelo departamento
de Área Local Networking. Se um mudar é feita por uma equipe ou
departamento, sem consultar os outros, isso pode ser desastroso para a
serviço.
• É mais difícil de compreender o impacto do mau desempenho de um
único departamento sobre o De serviços de TI uma vez que existem
muitos grupos diferentes que contribuem para o mesmo serviço, cada um
com seu próprio conjunto de objetivos de desempenho.
• É mais difícil para acompanhar o desempenho de serviço de TI geral já
que cada grupo está sendo medido em uma base individual.
• Alterar coordenando as avaliações e Horários é mais difícil, já que muitos
departamentos diferentes têm de fornecer dados para cada alteração.
• Trabalho que exige conhecimento de várias tecnologias é mais difícil
desde recursos só são treinados para e preocupadas com a gestão de
uma única tecnologia. Projetos, por conseguinte, tem de incluir a
formação transversal, o que é demorado e caro.
6.7.2 Organização pela atividade
Este tipo de organização estrutura centra-se no facto de que as actividades

semelhantes têm de ser realizados em todas as tecnologias na organização. Isto
significa que as pessoas que realizam atividades similares, independentemente

da tecnologia, devem ser agrupadas, embora dentro de cada departamento
pode haver equipes com foco em uma tecnologia específica, aplicação, Etc
Neste tipo de organização, não há diferenciação clara entre o técnico diferente e

áreas de Gerenciamento de Aplicativos. Atividades semelhantes de diversas
áreas podem ser agrupados em um único departamento.
Exemplos de serviços que foram criados para executar um conjunto específico

de atividades em várias tecnologias incluem:
• Manutenção (o que implica que uma equipe irá coordenar e realizar toda
a manutenção em todas as tecnologias)
• Gestão de contrato ou Terceiros Gestão
• Monitoramento e Controle
• Operações Ponte
• Centro de Operações de Rede
• Estratégia e Operações Planejamento (A qual, como parte do Design de
Serviços processos, normalmente define o padrãos para ser usado em
Operações de TI) - Este departamento pode definir estratégia ou padrões
para cada tipo de técnica e área de Gerenciamento de Aplicativos.
A Estratégia de Operações e Planejamento do departamento é usada para

ilustrar este tipo de estrutura na Figura 6.8.
Figura 6.8 Um departamento com base na execução de um conjunto de atividades

• É mais fácil para gerenciar grupos de atividades relacionadas já que

todas as pessoas envolvidas nessas atividades relatar ao mesmo gerente
• Medição de equipes ou departamentos se baseia mais na saída do que
em atividades isoladas. Isso ajuda a construir os níveis mais altos de
segurança que um serviço pode ser entregue.
As desvantagens deste tipo de estrutura organizacional incluem o seguinte.
• Recursos com capacidades semelhantes podem ser duplicados entre

diferentes funçãos, o que resulta em maior custars
• Embora a medição é mais baseada nos resultados, ainda é focada na
atuação de actividades internas em vez de impulsionada pela experiência
da cliente ou extremidade usuário.
6.7.3 Organização para gerenciar processos
Não é uma boa idéia para toda a estrutura organização de acordo com os
processos. Os processos são utilizados para ultrapassar o "efeito silo 'de
departamentos, para não criar silos. No entanto, há uma série de processos que
necessitam de uma estrutura específica para apoiar organização e gestão. Por
exemplo, vai ser muito difícil para os Gestão Financeira para ser bem sucedido
sem um departamento dedicado Finanças - mesmo que o departamento é
composto por um pequeno número de funcionários.
Em processoBaseados em pessoas das organizações são organizados em

grupos ou departamentos que realizam ou gerenciar um processo específico.
Isto é semelhante ao atividadeEstrutura baseada, exceto que os seus serviços
se concentrar no fim-de-final conjuntos de atividades, em vez de um tipo
específico de atividade.
Deve notar-se que este tipo de estrutura, a organização apenas deve ser usado
se TI Gestão de Operações é responsável por mais do que apenas Operações
de TI. Em algumas organizações, por exemplo, operações de TI é responsável
por definir SLAs e negociação de UCs.
Além disso, os processos existentes para ligar especificamente as actividades

de grupos diferentes para atingir um determinado resultado. Usando processos
como base para criar departamentos pode derrotar o propósito de ter processos
em primeiro lugar. Baseadas em processos departamentos são realmente
eficazes apenas quando eles são capazes de coordenar a execução do
processo através de toda a organização.

Isto significa que o processo baseados serviços devem ser consideradas apenas
se TI Gestão de Operações é jogar o papel de Proprietário do Processo para um
determinado processo.
Exemplos de processos baseados em grupos ou departamentos incluem:
• Operações capacidade
• Monitoramento e Controle de disponibilidade
• TI Gestão Financeira
• Administração de Segurança
• Ativos e Gerenciamento da Configuração (Incluindo a instalação de
equipamentos e desenvolvimento).
• Os processos são mais fáceis de definir

• Há menos conflitos papel como descrição do trabalhos e descrições de
papéis de processo são os mesmos. Em outras estruturas uma descrição
do trabalho único normalmente incluem atividades para várias funções
• Métricos da equipe ou do desempenho de departamentos e de
desempenho do processo são os mesmos, efetivamente alinhar métricas
"internas" e "externo".
• Um princípio básico de processos é que eles são um meio de associar as

atividades de vários departamentos e grupos. Usando processos como
base para a organização projeto, Processos adicionais necessitam de ser
definido para assegurar que os departamentos de trabalhar em conjunto.
• Mesmo que um departamento é responsável pela execução de um
processo, Ainda haverá dependências externas. Os grupos não podem
ver as atividades do processo fora do seu próprio processo como sendo
importante, resultando em processos que não podem ser plenamente
executados porque dependências não podem ser cumpridas.
• Embora alguns aspectos de um processo podem ser centralizados,
haverá sempre um certo número de actividades, que terão de ser
realizados por outros grupos. O relação entre a equipe dedicada ou
departamento e as pessoas que executam as atividades descentralizadas
é muitas vezes difícil de definir e gerenciar.
6.7.4 Organização de Operações de TI por geografia
Operações de TI pode ser fisicamente distribuído e, em alguns casos, cada

localização precisa de ser organizada de acordo com o seu próprio contexto
particular.

Esta estrutura é normalmente usado nos seguintes casos:
• Centros de dados são distribuídos geograficamente

• Diferentes regiões ou países têm diferentes tecnologias ou fornecer um
conjunto diferente de serviços
• Há negócio diferente modelos ou estruturas organizacionais, nas
diferentes regiões, ou seja, o negócio é descentralizada pela geografia e
cada Unidade de Negócios é bastante autônomo
• Legislação diferente se aplica a países ou regiões diferentes (por
exemplo, regulamentos de segurança)
• Diferente padrãos aplicar em países ou regiões diferentes
• As diferenças culturais ou idioma existir entre o pessoal gestão de TI.
Um exemplo deste tipo de estrutura é dada na Figura 6.9. Observe que, neste
exemplo, cada departamento geográfico está estruturado internamente usando
Especialização Técnica. Isto poderia ser diferente em cada região. Por exemplo,
uma região pode ser estruturada desta maneira, enquanto que uma outra região
utiliza um processo ou atividadeBaseada em estrutura.

Figura 6.9 Operações de TI organizados de acordo com a geografia
Figura 6.9 também ilustra que um local pode realizar operações centralizadas
para todas as regiões, se eles são bastante semelhantes. Neste exemplo, o
servidor americana Operations Department gere todas servidor operações em
todos os locais, Bruxelas gerencia todas as operações de banco de dados e
Cingapura gerencia todas as operações de armazenamento.
• Estrutura organizacional pode ser personalizado para atender às

condições locais
• Operações de TI pode ser personalizado para atender diferentes níveis
de De serviços de TI de região para região.

• Reportagem linhas e estruturas de autoridade pode ser confuso. Por
exemplo, se informar Operações de Rede no Gerenciador de dados locais
ou para um Centro centralizado Gerente de Operações de Rede?
• Operacional padrãos são difíceis de impor, resultando em atividades
inconsistentes e duplicados e ferramentas, resultando na redução
economias de escala, Que por sua vez aumenta o global custar das
operações.
• Duplicação de papels, atividades, ferramentas e instalações em vários
locais pode ser muito caro.
• Serviços compartilhados, tais como e-mail, são mais difíceis de se
entregar como cada regional organização opera de forma diferente.
• Comunicação com clientes e no interior, será mais difícil, pois eles não
são co-localizado e pode ser difícil para o pessoal em um único local para
entender as prioridades dos clientes ou funcionários em outro local.
6.7.5 híbridos estruturas de organização
É pouco provável que TI Gestão de Operações será estruturada usando apenas

um tipo de estrutura de organização. A maioria das organizações usam uma
especialização técnica, com alguns adicionais atividade- Ou de processos
baseados em departamentos.
O tipo de estrutura utilizada e a exata combinação de especialização técnica,

baseada em actividades e processoBaseadas em serviços irá depender de uma
série de variáveis de organização.
Organizacionais variáveis de estrutura
Os critérios exactos escolhido e da estrutura organizacional resultante

dependerá de um número de variáveis, que podem incluir:
• A natureza do negócio
• Negócio exigências e expectativas
• A técnica e tecnológica arquitetura
• A estabilidade da corrente Infraestrutura de TI e a disponibilidade de
habilidades para gerenciá-lo
• O governo da organização (ou seja, a forma como a autoridade é
atribuído e são tomadas as decisões - bem como qualquer estrutura de
governança formal que é utilizado, tal como COBIT ou SOX)
• O legislativo, político e sócio-econômico ambiente da organização
• O tipo eo nível de habilidades à disposição da organização
• O tamanho, idade e maturidade do organização
• O estilo de gestão da organização
• Dependência de TI para negócios críticos atividades, processos e funçãos
• A maneira em que participa na rede de valor (Ou seja, a forma como ele
interage com o negócio e seus parceiros, fornecedors e clientes)

• O relação entre a TI e seus fornecedores.
Para uma descrição mais completa de como esses fatores influenciam

organizacional projeto, Por favor consulte a seção "Desenvolvimento
Organizacional" do Estratégia de Serviço publicação.
6.7.5.1 Funções combinadas
Um último tipo de organização deve ser discutido. Esta estrutura incorpora

operações de TI, técnicos e Aplicação de Gestão de departamentos dentro de
uma estrutura única. Isso às vezes é o caso em que todos os grupos são co-
localizado em um centro de dados único. Aqui, o Data Centre Manager assume
a responsabilidade por toda a aplicação, Técnico e TI Gestão de Operações.
Este tipo de estrutura, a organização encontra-se ilustrada na Figura 6.10.

Figura 6.10 Centralizado operações de TI, técnicos e estrutura de Gerenciamento
de Aplicativos
Nesta estrutura, TI Gestão de Operações é responsável pela técnica e Aplicação

de Gestão de funçãos, que por sua vez são responsáveis por sua própria
operacional actividades. Cada departamento é capaz de delegar algumas
dessas atividades para o Operações de controle departamento.
As vantagens desta estrutura de organização são:
• Há uma maior consistência e controlar entre o mais tático e operacional

Gestão Técnica atividades
• É mais fácil de aplicar o atuação padrãos e técnicas arquiteturas que são
criadas Design de Serviços, Já que as pessoas que estiveram envolvidas

em projeto estão a gerir as atividades das pessoas que estão executando
as atividades
• Como não há duplicação entre localização ou atividade, Esta estrutura é
muitas vezes mais custo-efetiva.
A desvantagem desta estrutura da organização é:
• O escopo desta estrutura torna muito difícil de gerir de forma eficaz em

grandes organizações ou em organizações com múltiplas Centros de
Dados.
6.7.5.2 Aplicação de Organização e Gestão Técnica
Técnico e Aplicação de Gestão de organizações tendem a ser bastante simples.

Expressa nos pontos 6.3.4 e 6.5.6, Gestão Técnica departamentos são
geralmente baseados na tecnologia que gerem e departamentos de
gerenciamento de aplicativos no aplicaçãos e conjuntos de aplicativos que
gerenciam.
No entanto, existem algumas alternativas organização estruturas e variações,

que são discutidos nesta seção.
6.7.5.3 Geografia
Em organizações com múltiplos locais, é comum para o técnico e Aplicação de

Gestão de departamentos para ser representados em cada local físico. No
entanto, isso não significa que cada local terá todos os mesmos serviços, ou que
todos eles são responsáveis pelas mesmas ações.
Como ferramentas de suporte e gestão amadurecer mais e mais Infraestrutura

de TI e cis aplicação pode ser gerenciado remotamente. Isto significa que cada
departamento terá uma forte equipe de gestão técnica centralizada ou aplicativo,
com os membros locais para fornecer especializados, actividades no hotel ou
suporte.
Por exemplo, em Servidor Gestão, a equipe central vai ajudar a criar padrãos
para servidor configuração, Eles vão monitorar e controlar dispositivos remotos,
executar apoios, realizar atualizações de sistema operacional, etc As equipes
locais irão fornecer básico suporte on-site manutenção de hardware, e reparar e
configuração e instalação de novos servidores.
Em Gerenciamento de Aplicativos, a equipe central poderia participar de curso

projeto e ensaio da aplicação,monitoramento e controlar, executar backups,
dados integridade cheques, etc A equipe local poderia fornecer suporte on-site e
educação para acabar usuários e trabalho com o local Gestão Técnica equipe
para resolver mais complexo problemas envolvendo equipamentos local.

Há um potencial problema que precisa ser resolvido no entanto, e é isso o que a
equipe local reporta. Em algumas organizações relatam que o gerente da equipe
centralizada. Isto tem a vantagem adicional de acordo atuação e gestão de toda
a empresa.
Em outras organizações as equipes locais informar o mais antigo Gerente de TI

no local. Isto tem a vantagem adicional de que Serviços de TIs pode ser
personalizado para atender às condições locais, mas ele cria uma grande
confusão sobre o que as equipes locais devem tomar a direcção de.
• Estrutura organizacional pode ser personalizado para atender às

condições locais
• Técnica e Gerenciamento de Aplicativos podem ser personalizados para
atender diferentes níveis de serviços de TI de região para região.
• Reportagem linhas e estruturas de autoridade pode ser confuso

• Padrões são difíceis de impor, resultando em atividades inconsistentes e
duplicados e ferramentas, resultando na redução economias de escala,
Que por sua vez aumenta o global custar das operações
• Duplicação de papels, atividades, ferramentas e instalações em vários
locais pode ser muito caro.
6.7.5.4 Técnica Combinada e estrutura de Gerenciamento de

Aplicativos
Algumas organizações organizar sua Gestão Técnica e Aplicação funçãos de

acordo com os sistemas. Isto significa que cada departamento será composto de
especialistas em aplicações e Infraestrutura de TI especialistas técnicos, todos
voltados para a gestão dos serviços com base em que o conjunto de sistemas.
Componentes que são compartilhados entre todos estes sistemas, tais como a
rede, será gerido pelo dedicado Gestão Técnica departamentos.
A vantagem desta organização estrutura é a seguinte:
• É mais fácil de produzir produtos de altaqualidade a saída para a

extremidade usuário porque todos os membros de departamentos estão
focados no sucesso do sistema como um todo, em vez de o atuação de
um componente individual ou de tecnologia aplicação.
As desvantagens desta estrutura de organização são:

• Duplicação de competências e recursos através de vários departamentos
irá aumentar a custar da organização. Por exemplo, cada grupo é
provável que tenha uma pessoa ou equipe dedicada à gestão servidors -
cada um dos quais vai fazer tarefas muito semelhantes.
• Comunicação entre os funcionários que estão a gerir tecnologia
semelhante é reduzido. Isso reduz a quantidade de aprendizado por
experiência e aumenta a dependência de colaboração gestão do
conhecimento ferramentas.
• Quando as pessoas com habilidades semelhantes estão no mesmo
departamento, o departamento irá compensar para os membros com
menor habilidade e níveis de competência. Quando há apenas uma
pessoa com habilidades Management Server em um departamento
baseado no sistema, e sua competência é mínima, isso afetará o
desempenho de todo o departamento.

7 considerações de tecnologia
Cada função e processo é definida na secção relevante nos capítulos 4 e 6. Este
capítulo traz toda a tecnologia exigências em conjunto para definir a exigência
geral de um conjunto integrado de tecnologia de Gestão de Serviços para
A mesma tecnologia, com algumas adições possíveis, deve ser usado para as
demais fases do ITSM - Estratégia de Serviço,Design de Serviços,Transição de
Serviço e Melhoria de Serviço Continuada - Para dar consistência e permitir uma
eficaz ITSM Ciclo de Vida a ser devidamente geridos.
Os principais requisitos para operação de serviço, são os estabelecidos neste

capítulo.

7,1 requisitos genéricos
Uma visão integrada de ITSM tecnologia (ou conjunto de ferramentas, como
alguns fornecedors vender sua tecnologia como "módulos" enquanto algumas
organizações podem optar por integrar os produtos de fornecedores alternativos)
é necessário que inclui a funcionalidade do núcleo seguinte.
7.1.1 Auto-Ajuda
Muitas organizações consideram que é benéfico para oferecer capacidades de

"auto-ajuda" para os seus utilizadores. A tecnologia deve apoiar esta capacidade
com alguma forma de web front-end permitindo que páginas web para ser
definido oferecendo uma gama menu-driven de auto-ajuda e Solicitação de
Serviços com uma interface direta para o back-end processo-Manipulação de
software.
7.1.2 Fluxo de Trabalho ou processo motor
Um fluxo de trabalho ou controle de processo motor é necessário para permitir a

definição de pré-e controlo de processos definidos, tais como um ciclo de vida
de incidentes, Cumprimento de Requisição Lifecycle, Ciclo de Vida problema,
altere Modelo, Etc
Isso deve permitir que responsabilidades, atividades, prazos, escalada caminhos

e alertando para ser pré-definidos e, então, automaticamente gerenciado.
7.1.3 Integrado CMS
A ferramenta deve ter um CMS integrado para permitir que o organização'S

Infraestrutura de TI ativoss, componentes, serviços e qualquer CIs auxiliares
(como contratos, locais, licenças, fornecedors etc - qualquer coisa que os
desejos de TI da organização para controlar) A ser realizada, em conjunto com
todas as partes atributos, em uma localização centralizada - e permitir relaçãos
entre cada ser armazenados e mantidos, e ligado a incidentes, problemas, Erro
Conhecido e Alteração do registros conforme apropriado.
7.1.4 Descoberta de Implantação / / licenciamento de tecnologia
A fim de preencher ou verificar os dados do CMS e para auxiliar no

gerenciamento de licença, descoberta ou automatizado auditar são necessárias
ferramentas. Tais ferramentas deve ser capaz de ser executado a partir de
qualquer local na rede e permitir uma interrogação e recuperação de
informações relativas a todos os componentes que compõem, ou está
conectado, a infra-estrutura de TI.

Essa tecnologia deverá permitir "filtragem" de modo que os dados que estão
sendo realizadas para a frente pode ser controlados e apenas os dados
necessários extraído. Também é muito útil se "apenas" mudanças desde a
última auditoria pode ser extraído e reportados.
A mesma tecnologia pode ser usada freqüentemente para implantar um novo

software para locais de destino - este é um elemento essencial exigência para
todos Operação de Serviço equipes ou departamentos, para permitir correções,
transporta etc, para ser distribuído para a correta usuários.
Uma interface com capacidade de 'auto-ajuda' é desejável permitir downloads de

software aprovados a ser solicitado desta forma, mas manipulada pelo
desenvolvimento software.
Ferramentas que permitem a comparação automática de detalhes licenças de

software realizada (no CMS, de preferência) e números de licença reais
implantado - com a notificação de qualquer discrepância - são extremamente
desejável.
7.1.5 O controle remoto
Muitas vezes, é útil para o Service Desk Analistas e outros grupo de apoios para
ser capaz de tomar controlar do usuário desk-top (sob devidamente controlada
segurança condições), de modo a permitir-lhes a realização de investigações ou
as configurações corretas, instalações, etc para que esse nível de controle
remoto será necessário.
7.1.6 utilitários de diagnóstico
Pode ser extremamente útil para o Service Desk e outros grupos de apoio, se a
tecnologia incorporada a capacidade para criar e utilizar script de diagnósticos e
outros utilitários de diagnóstico (tais como, por exemplo, ferramentas de
raciocínio baseado em casos) para auxiliar anteriormente diagnóstico de
incidentes. Idealmente, estes devem ser "sensível ao contexto" apresentação e
dos scripts automatizados, tanto quanto possível.
7.1.7 Relatórios
Não há nenhum uso em armazenamento de dados, a menos que ele pode ser
facilmente recuperado e usado para atender fins da organização. A tecnologia
deve, portanto, incorporar capacidades de comunicação bons, bem como
permitir interfaces padrão que pode ser usado para entrada de dados para
pacotes padrão da indústria, relatórios, painel de instrumentoss, etc Idealmente,
instantânea, na tela, bem como relatórios impressos podem ser fornecidas
através do uso de sensíveis ao contexto 'top 10' relatórios.

7.1.8 Dashboards
Do tipo painel tecnologia é útil para permitir "ver de relance" visibilidade global
De serviços de TI atuação e disponibilidade níveis. Tais monitores podem ser
incluídos no nível de gestão de relatórios para usuários e clientes -, mas também
pode dar informações em tempo real para a inclusão nas páginas web de TI
para dar informação dinâmica, e pode ser usado para o suporte e para fins de
investigação. Capacidades para apoiar visualizações personalizadas de
informações para atender aos níveis específicos de interesse pode ser
particularmente útil.
No entanto, às vezes eles representam uma técnica em vez de serviço vista da

infra-estrutura e, nesses casos, pode ser de menor interesse para os clientes e
usuários.
7.1.9 Integração com o Business Service Management
Há uma tendência na indústria de TI para tentar reunir negócios relacionados a

TI com os processos e disciplinas de IT Service Management - Alguns chamam
isso de Business Service Management. Para facilitar este negócio, aplicaçãos e
ferramentas precisam ser conectado com ferramentas de apoio ITSM para dar a
funcionalidade necessária. Isso pode ser ilustrado pelo seguinte exemplo:
Uma empresa de telecomunicações do Leste Europeu foi capaz de interface seu

telefone celular net- monitoramento e faturamento sistema ao seu Gestão de
Eventos,Gerenciamento de Incidentes e Gerenciamento da Configuração
processos. Desta forma, foi capaz de detectar qualquer incomuns de uso /
faturamento padrões e interpretá-los de tal forma que ele pode identificar, com
um alto grau de certeza, que um telefone tinha sido roubado e estava sendo
usado para fazer chamadas ilícitas.
Ele foi capaz de aumentar eventos para tais padrões e automatizar ações para
suspender o uso dos dispositivos de telefonia móvel e, em paralelo, identificar a
localização exata do usuário ilícito (usando a tecnologia GPRS) e levantar os
incidentes de modo que a polícia tinha a capacidade de encontrar o ladrão e
recuperar suspeita do dispositivo.
Capacidades mais avançadas ferramentas de integração são necessários para

permitir uma maior exploração deste tipo de negócio e integração de TI.

7.2 Gestão de Eventos
As seguintes características são desejáveis para qualquer tecnologia de
gerenciamento de eventos:
• Multi-ambiental, interface aberta para permitir monitoramento e alerta em

todos os serviços heterogêneos e um organização'S inteira Infraestrutura
de TI.
• Fácil de implantar, com o mínimo de configurar custars.
• "Standard" agentes para monitorar mais comum ambientes /componentes
/ sistemas.
• Interfaces abertas a aceitar qualquer SNMP (por exemplo) padrão evento
de entrada e geração de alerta múltipla.
• Roteamento centralizado de todos eventos para um único local,
programável para permitir local diferente (s) em vários momentos.
• Suporte para projeto/teste fases - de modo que o novo aplicaçãos /
serviços podem ser monitoradas durante o projeto / teste fases e
resultados alimentado de volta para o projeto e de transição.
• Programável avaliação e manipulação de alertars dependendo dos
sintomas e impacto.
• A capacidade de permitir que um operador de reconhecer um alerta, e se
nenhuma resposta for inserido dentro de um prazo definido, para escalar
o alerta.
• Funcionalidade de relatórios para permitir bom feed-back em design e
fases de transição, bem como um significativo gestão da informação e de
negócios usuário 'painel de instrumentos'.
Essa tecnologia deve permitir uma interface direta para o organização'S

Gerenciamento de Incidentes processos (via entrada no Registro de Incidentes),
bem como a capacidade de escalar para apoiar a equipe, outros fornecedores,
engenheiros etc via e-mail, mensagens SMS, etc
Instalações especializadas, ou talvez ferramentas especializadas separados,

será exigido para o site monitoramento. Essas instalações devem ser capazes
de simular cliente tráfego para o site e para informar sobre disponibilidade e
atuação em relação à "experiência do cliente".

7,3 Gerenciamento de Incidentes
7.3.1 Integrado ITSM tecnologia
Tecnologia integrada de ITSM é exigido que tem as seguintes funcionalidades:
• Um integrante CMS para permitir automatizado relaçãos a ser feita e

mantida entre incidentes, solicitação de serviços, problemas, Erro
Conhecidos e todas as outras item de configuraçãos.
• O CMS que pode ser usada para ajudar a determinar prioridade e ajuda
na investigação e diagnóstico.
• Aprocesso mecanismo de fluxo de processos para permitir a ser pré-
definido (incluindo pré-definidos incidente modelos, ver o ponto 3.2.1.5) e
controlada automaticamente - com roteamento interno flexível para todos
relevantes grupo de apoios e interfaces externas e-mail/SMS.
• Automatizado de alerta e escalada capacidades para evitar um incidente
que está sendo ignorado ou adiado.
• Abra a interface para Gestão de Eventos ferramentas, de modo que
qualquer falhas pode ser automaticamente criado como incidentes.
• A interface web para permitir que os pedidos de auto-ajuda e serviço para
ser a entrada através da Internet / Intranet telas.
• Um BDEC integrada para que o diagnóstico e / ou resolvidos incidentes /
problemas podem ser gravadas e procurou ajudar no incidente futuro
excesso de velocidade resolução.
• Fácil de usar instalações de relatórios para permitir incidente métricos
para ser produzido e para facilitar a análise de incidentes de
Gerenciamento de Problemas e Gestão fins disponibilidade.
• Ferramentas de diagnóstico (integrada ou interfaces para produtos
separados), como já mencionado no Service Desk.
7.3.2 Fluxo de Trabalho e escalonamento automatizado
Os tempos de alvo devem ser incluídos em ferramentas de apoio, o que deve

ser usada para automatizar o fluxo de trabalho controlar e escalada caminhos.
Se, por exemplo, um segunda linha de apoio grupo não resolveu uma incidente
dentro de uma meta de 60 minutos acordado, o incidente deve ser
automaticamente encaminhado para a adequada (determinada pela
categorização incidente) linha de terceira grupo de apoio - E caso seja
necessário escalada hierárquica deve ser realizada automaticamente (por
exemplo, mensagem SMS para o Service Desk Manager, Gerente de Incidentes
e / ou IT Services Manager e talvez para o usuário, Se for o caso). A segunda
linha grupo de apoio deve ser informado da acção de escalonamento como parte
do automático processo.

7,4 cumprimento Pedido
Integrated ITSM tecnologia é necessária a fim de que Solicitação de Serviços
pode ser ligado a ou incidentes eventos que iniciaram eles (e foi armazenado no
CMS mesmo, que pode ser interrogado para relatar contra SLAs). Algumas
organizações se contentar em usar a Gerenciamento de Incidentes elemento de
tais ferramentas e tratar solicitações de serviços como um subconjunto e
definidas categoria de incidentes. Quando um organização escolhe para levantar
Pedidos de serviço separada, será necessária uma ferramenta que permite que
este capacidade.
Front-end de Auto-Ajuda recursos que serão necessários para permitir que os

usuários enviem solicitações via alguma forma de web-based processo de
seleção, menu-driven.
Em todos os outros aspectos, as instalações necessárias para gerenciar

solicitações de serviço são muito semelhantes aos de gestão de incidentes: pré-
definido de controle de fluxo de trabalho de Solicitação Modelos, prioridade
níveis, de escalonamento automatizado, comunicação eficaz, etc

7,5 Gerenciamento de Problemas
7.5.1 Integrated Service Management Technology
Uma ferramenta integrada de ITSM é necessário que diferencia entre incidentes

e problemas - para que em separado Grave problemas pode ser elevado para
lidar com as causas dos incidentes, mas ligado aos incidentes relacionados. A
funcionalidade de registos problema deve ser semelhante às que são
necessárias para Grave incidentes e também para permitir incidente múltipla
correspondência contra registros de problemas.
7.5.2 Gestão da Mudança
Integração com Gestão da Mudança É muito importante, para que Pedido,

Evento de Incidentes e Grave problemas pode ser relacionado com RFCs que
causaram problemas. Trata-se de avaliar o sucesso da gerência da mudança
processo - Incidente, bem como e Grave erro conhecidos - e para que RFCs
pode ser facilmente aumentado para controlar as atividades necessárias para
superar os problemas que foram identificados através da análise de causa raiz
ou Proactive Análise de Tendências.
7.5.3 Integrado CMS
É também importante ter um CMS integrado que permite registos problema a ser
ligada ao componentes afetados e os serviços afetados - e de qualquer outros
CIs relevante.
Gerenciamento da Configuração faz parte de um SKMS maiores que inclui

ligações a muitos dos repositórios de dados utilizados na Operação de Serviços.
O processo e práticas de Gerenciamento de Configuração e suas tecnologias
subjacentes exigências são incluídos na Transição de Serviço publicação.
7.5.4 Banco de Dados Erro Conhecido
Um BDEC eficaz será como requisito essencial, o que deve permitir fácil
armazenamento e recuperação de Erro Conhecido dados.
Instalações boas reportagens são necessários para facilitar a produção de

relatórios de gestão, permitindo que os dados sejam incorporados
automaticamente, sem a necessidade de re-digitação de dados - e para permitir
capacidades de drill-down para a Incidentes e Análise de Problemas.
Nota: Em alguns casos, os componentes ou sistemas sendo investigado pela

Gerenciamento de Problemas pode ser fornecido por outros fornecedores ou

fabricantes. Para resolver este problema, as ferramentas de vendedores de
suporte e / ou KEDBs também pode precisar de ser utilizado.

7,6 Gerenciamento de Acesso
Gerenciamento de Acesso usa uma variedade de tecnologias, principalmente:
• Tecnologia de Gestão de Recursos Humanos, para validar o identidade

de usuários e para acompanhar a sua estado
• Serviço de Diretórios Technology (ver secção 5.8 para uma descrição de
Serviços de Diretório). Esta tecnologia permite que gerentes de tecnologia
para atribuir nomes a recursos sobre uma rede e, em seguida, fornecer
acesso a esses recursos com base no perfil do utilizador. Ferramentas
Directory Services também permitem Gerenciamento de Acesso para
criar papels e grupos e de vincular estes para ambos os usuários e
recursos
• Acesse os recursos de gestão em Aplicativos, Middleware, Sistemas
Operacionais e Sistemas Operacionais de Rede
• Gestão da Mudança sistemas
• Cumprimento de Requisição tecnologia (ver secção 7.4).

7,7 Service Desk
Ferramentas adequadas e apoio a tecnologia deve ser fornecida para permitir
Service Desk pessoal para desempenhar seus papéis de forma eficiente e eficaz
possível. Isto vai incluir o seguinte.
7.7.1 Telefonia
Porque uma elevada percentagem de incidentes são susceptíveis de ser

levantado através de chamadas telefónicas a partir de usuários, o Service Desk
deve ser fornecido com bons serviços de telefonia modernos. Isto deve incluir:
• Um sistema automatizado chamar distribuição (ACD) sistema para

permitir que um único número de telefone (ou números se um Service
Desk distribuída ou segmentado é a opção preferida) e grupo pick-up
capacidades. Aviso: Se as opções são oferecidos através do DAC, via
teclado ou Interactive Voice Recognition seleção (IVR), não use muitos
níveis de opções ou oferecer opções ambíguas. Também não incluem
qualquer "becos sem saída" ou opções que, uma vez escolhido, não
permitem que o chamador para voltar aos menus anteriores.
• Computer Telephony Interface de software (CTI) para permitir o
reconhecimento de chamadas (ACD via ligada) e população automatizada
do usuárioDetalhes S 'para o registro de incidente da CMS.
• VoIP - uso desta tecnologia pode reduzir significativamente telefonia
custars ao lidar com usuários remotos e internacionais
• Software estatístico permitir que as estatísticas de telefonia devem ser
recolhidas e facilmente interrogado / impressos para análise - este deve
permitir a seguinte informação a ser obtida por qualquer período
selecionado:
• Número de chamadas recebidas, no total e discriminado por
qualquer 'racha' - onde qualquer chamada de roteamento foi
escolhido e está sendo fornecida por um IVR sistemaResposta /
teclado
• Chame perfis de chegada e tempos de resposta
• Chame taxas de abandono
• Gestão de chamadas taxas por pessoa Service Desk chamar
manipuladores
• Média de duração de chamadas
• Auriculares mãos-livres, com capacidades de dual-acesso do
usuário (pelo menos em alguns dos fones de ouvido) para uso
durante o treinamento de novos funcionários, etc
7.7.2 Ferramentas de suporte
Há uma gama de free-standing ferramentas de serviço Posto de apoio

disponíveis no mercado - e algumas organizações podem optar por produzir seu

próprio simples incidente log /sistema de gestãos. Se um organização
seriamente pretende implementar ITSM então um sistema totalmente integrado
conjunto de ferramentas ITSM será necessário que tenha um CMS no centro e
fornece suporte integrado para todo o ITILDefinida processos.
Elementos específicos de uma ferramenta que irá ser particularmente benéfico

para a central de serviços incluem o seguinte.
7.7.2.1 Banco de Dados Erro Conhecido
Um BDEC integrado deve ser usado para armazenar detalhes de incidentes

anteriores /problemas e a sua resoluçãos -, de modo que quaisquer recidivas
podem ser mais rapidamente diagnosticada e fixado.
Para facilitar isso, a funcionalidade é necessário para categorizar e recuperar

rapidamente anterior Erro Conhecidos, usando a correspondência de padrão e
palavra-chave busca contra os sintomas. Gestão do BDEC é de
responsabilidade do Gerenciamento de Problemas, Mas o Service Desk será
usado para ajudar tratamento de incidentes de velocidade.
7.7.2.2 os scripts de diagnóstico
Multi-nível script de diagnósticos devem ser desenvolvidos, armazenados e

gerenciados para permitir que o pessoal Service Desk para identificar a causa
da falhas. Especialista grupo de apoios e fornecedors deve ser solicitado a
fornecer detalhes sobre as falhas prováveis e as questões-chave a serem feitas
para identificar exatamente o que deu errado - e para os detalhes da resolução
ações a serem tomadas.
Esses detalhes devem então ser incluído em scripts sensíveis ao contexto que
devem aparecer na tela, dependentes da categorização multi-nível do incidente,
E deve ser impulsionada pelo usuário'S respostas a perguntas de diagnóstico.
7.7.2.3 interface web de Auto-Ajuda
Muitas vezes, é rentável e conveniente para fornecer algum tipo de

funcionalidade automática 'auto-ajuda', assim os usuários podem procurar e
obter a assistência que lhes permita resolver suas próprias dificuldades.
Idealmente isto deve ser através de uma interface de 24/7 web que é
impulsionado pela seleção de menu e pode incluir, conforme apropriado:
• Perguntas mais frequentes (FAQ) e soluções.

• 'Como fazer' capacidades de busca para orientar os usuários através de
uma lista de contexto de tarefas ou atividades.
• Um boletim do tipo serviço contendo detalhes de questões de serviço
pendentes / problemas junto com tempos de restauração de antecipados.

• Senha capacidades de mudança - usando software de proteção de senha
segura para verificar identidades, senhas de autorização e realizar a
mudança sem a necessidade de Service Desk intervenção.
• Download de software de correção (patches, service packs, etc correções
de bugs, onde é determinado que o usuário tem o errado versão ou uma
correção seja necessário) - ferramentas estão disponíveis para
automatizar a verificação processo, Para comparar a imagem do desktop
real com o acordado 'padrão' construirs e para permitir atualizações para
ser oferecido e aceito, quando necessário.
• Software reparars - onde se detectou que a corrupção pode ter ocorrido,
para permitir correções de software, remoção e / ou re-instalação.
• Pedidos de remoção de software - automaticamente preenchido com
qualquer licença a ser retornado para o pool.
• Downloads de pacotes de software adicionais - ferramentas estão
disponíveis para verificar um software pré-definido política e para permitir
o download de pacotes de software adicionais, se coberto pela apólice.
Isso pode incluir verificações automatizadas de software de licenças e
aprovações financeiras, bem como CMS atualização.
• Aviso prévio de qualquer tempo de inatividade planejado ou interrupções
de serviços ou degradações.
A solução de auto-ajuda deve incluir o capacidade para usuários para registrar

incidentes em si, que podem ser usadas durante períodos em que o Service
Desk está fechado (se não funcionar 24/7) e atendidas pela equipe de Service
Desk no início do próximo deslocar.
Alguns cuidados devem ser tomados para garantir que as atividades de auto-
ajuda selecionados para inclusão não são demasiado avançado para o usuário
médio, e que as salvaguardas são incluídos para evitar um "pouco conhecimento
de ser uma coisa perigosa '! Pode ser possível para oferecer um pouco mais
avançadas de Auto-Ajuda instalações para 'Usuários super' que tiveram
treinamento extra. Também é necessário ter muito cuidado com suposições
feitas ao pessoal um Service Desk com a quantidade de uso que os usuários
irão fazer de Auto-Ajuda instalações.
Observação: Como já foi abordado na lista acima, é possível combinar algumas

simples Cumprimento de Requisição atividades como parte de uma estratégia
global de Auto-Ajuda sistema - Que também pode ser um benefício significativo
na redução de chamadas para a Central de Serviço (ver parágrafo 7.1.1 para
mais detalhes).
7.7.2.4 O controle remoto
Como já foi dito, mas repetiu aqui para ser completo, muitas vezes é útil para os
analistas do Service Desk para ser capaz de tomar controlar da área de trabalho
do usuário, de modo a permitir-lhes a realização de investigações ou

configurações corretas, instalações etc para permitir esse nível de controle
remoto será necessário.
7.7.3 Planejamento da Continuidade dos Serviços de TI para

ferramentas de suporte ITSM
Organizações tendem a tornar-se rapidamente dependentes de suas

ferramentas de ITSM e vai achar que é difícil trabalhar sem eles. Um completo
Análise de Impacto no Negócio e Risco A análise deve ser realizada e planos,
em seguida, desenvolvido para assegurar a adequada De serviços de TI
Continuidade e resiliência níveis.

8 considerações sobre a aplicação
Deve notar-se que Operação de Serviço é uma fase em ciclo de vida e não uma
entidade em seu próprio direito. No momento em que um serviço,
processo,organização estrutura ou a tecnologia está a funcionar, já foi
implementado. No entanto, há um número de processos e funçãos descritos
nesta publicação, e, portanto, é importante abordar as considerações de
implementação que deveriam ter sido abordados no momento em que entrar em
operação.
Alguns destes foram abordados na seção relevante - por exemplo é dada

orientação sobre estruturas de organização e papels no Capítulo 6. Isto não será
repetida aqui. Em vez disso, esta secção irá se concentrar em alguma
orientação implementação genérica para operação de serviço como um todo.

8,1 mudança de gestão, em Operação de Serviço
Operação de Serviço deve se esforçar para alcançar a estabilidade - mas não a
estagnação! Há muitas razões válidas e vantajoso porque 'mudar é uma coisa
boa "-, mas o pessoal Operação de Serviço deve assegurar que quaisquer
mudanças são absorvidas sem efeitos impacto sobre a estabilidade dos serviços
de TI oferecidos.
8.1.1 Mudança desencadeia
Há muitas coisas que podem desencadear uma mudar na Operação de Serviço

ambiente. Estes incluem:
• Hardware novo ou atualizado ou rede componentes

• Novo ou atualizado aplicaçãos software
• Novo ou atualizado sistema software (sistemas operacionais, utilitários,
middleware etc, incluindo patches e correções de bugs
• Mudanças de conformidade, Legislativo ou governança
• Obsolescência - alguns componentes podem se tornar obsoletos e
exigem substituição ou deixar de ser apoiada pelo fornecedor/
Mantenedor
• Imperativo do negócio - você tem que ser flexível para trabalhar em ITSM,
particularmente durante a Operação de Serviço, e haverá muitas ocasiões
em que as necessidades do negócio de TI muda para atender negócios
dinâmico exigências
• Melhorias para processos, procedimentos e / ou subjacente ferramentas
para aprimorar a entrega ou reduzir financeira custars
• Mudanças de gestão ou pessoal (que vão desde perda ou transferência
de indivíduos para a direita através de importantes aquisições de
empresas ou aquisições)
• Mudança de nível de serviços ou em serviço prestação - terceirização, In-
sourcing, parcerias, etc
8.1.2 Avaliação de Mudança
Operação de Serviço equipe deve estar envolvida na avaliação de todas as

mudanças de assegurar que operacional questões sejam plenamente tidas em
conta. Esse envolvimento deve começar o mais cedo possível (ver ponto 4.6.1)
não apenas nas fases posteriores do mudar - Ou seja, a adesão CAB e ECAB -
época em que muitas decisões fundamentais foram feitas e influência é provável
que seja muito limitado. O Gerente de Mudanças deve informar todas as partes
afetadas da mudança que está sendo avaliada para entrada pode ser
preparados e disponíveis antes das reuniões do CAB.
No entanto, é importante que o pessoal de operação de serviço estão envolvidas

nestas últimas fases em que possam estar envolvidos na execução efectiva e

eles desejar assegurar que a programação é realizada cuidado para evitar
contentions potenciais ou períodos particularmente sensíveis.
8.1.3 Medição de mudança bem sucedida
A última medida de sucesso em matéria de alterações feitas Operação de

Serviço é que clientes e usuários não sentir qualquer alteração ou interrupção do
serviço. Na medida do possível, os efeitos das mudanças deve ser invisível,
para além de qualquer funcionalidade melhorada, qualidade ou poupança
financeira resultante da mudança.

8.2 Operação de Serviços e Gerenciamento de Projetos
Porque Operação de Serviço é geralmente visto como 'business as usual' e
muitas vezes focada em executar procedimentos definidos de uma forma
padrão, há uma tendência a não usar Projeto Gestão de processos quando eles
de fato seria apropriado. Por exemplo, as principais atualizações de infra-
estrutura, ou as desenvolvimento de novo ou modificado procedimentos, são
tarefas importantes onde Gerenciamento de Projetos formal pode ser usada
para melhorar controlar e gerir custars /recursos.
Usando o Gerenciamento de Projeto para gerenciar esses tipos de atividade

teria as seguintes vantagens:
• Os benefícios do projeto estão claramente definidas e acordadas

• Há mais visibilidade do que está sendo feito e como está sendo
gerenciado, o que torna mais fácil para os outros grupos de TI e do
negócio para quantificar as contribuições feitas por operacional equipes
• Este, por sua vez, torna mais fácil obter financiamento para projetos que
têm sido tradicionalmente difícil justificar o custo
• Maior consistência e melhor qualidade
• Realização de objetivoS resulta em maior credibilidade para grupos
operacionais

8,3 Avaliação de risco e gestão na Operação de Serviço
Haverá um número de ocasiões em que é imperativo que avaliação de risco a
operação de serviço é realizada rapidamente e posta em prática.
A área mais óbvio é a avaliação da risco de possíveis mudanças ou Erro

Conhecidos (já coberta em outros lugares) mas, além disso Operação de
Serviço equipe podem precisar de ser envolvido na avaliação do risco e impacto
de:
• Falhas ou potenciais falhas - ou relatados por Gestão de Eventos ou

Incidente /Gerenciamento de Problemas, Ou avisos levantadas pelos
fabricantes, fornecedors ou contratados
• Novos projetos que acabará por resultar em entrega ao viver ambiente
• Risco ambiental (abrangendo De serviços de TI Continuidade do tipo de
riscos para o ambiente físico e localidade, bem como políticos, comerciais
ou industriais de relações riscos relacionados)
• Fornecedores, especialmente quando novos fornecedores estão
envolvidos ou onde o serviço chave componentes estão sob a controlar
de terceiros
• Os riscos de segurança - tanto teórico ou real decorrente de segurança
incidentes relacionados ou eventos
• Novo clientes / serviços a serem apoiadas

8,4 pessoal operacional em Design de Serviços e Transição
Todos os grupos de TI estarão envolvidos durante Design de Serviços e
transição de serviço para assegurar que novos componentes ou serviços são
projetados, testados e implementados para fornecer os níveis corretos de
funcionalidade, usabilidade,disponibilidade,capacidade, Etc
Além disso, o pessoal Operação de Serviço devem estar envolvidos, durante os

estágios iniciais de Design de Serviços e Transição de Serviço para garantir que
quando chegar a novos serviços viver ambiente eles são apto para o efeito, A
partir de uma perspectiva de operação de serviço, e são "suportável" no futuro.
Neste contexto, "suportável" significa:
• Capaz de ser suportado a partir de um ponto de vista técnico e

operacional de dentro de adicional existente, ou pré-acordo recursos e os
níveis de qualificação
• Sem impacto adverso sobre trabalho existente outro técnico ou
operacional práticas, processos ou horários
• Sem qualquer inesperado custo operacionals ou despesas de apoio em
curso ou escalada
• Sem quaisquer complicações inesperadas contratuais ou legais
• Nenhum complexos caminhos de apoio entre os departamentos de apoio
múltiplas organizações de terceiros.
Nota: Mudar não é apenas tecnologia. Também requer a conscientização,

treinamento, mudança cultural, as questões motivacionais e muito mais. Mais
detalhes sobre maior gestão da mudança são abordados na publicação
Transição de Serviço

8,5 Planejamento e implementação de tecnologias de
gerenciamento de serviços
Há uma série de fatores que as organizações precisam para planejar em
prontidão para, e durante desenvolvimento e implementação de ferramentas de
apoio, de ITSM. Estes incluem os seguintes.
8.5.1 As licenças
O total custar de ITSM ferramentas, em particular a ferramenta integrada que

formará o centro do conjunto de ferramentas necessárias, é geralmente
determinada pelo número e tipo de usuário licenças que o organização
necessidades.
Tais ferramentas são muitas vezes vendidos em formato modular, de forma a

funcionalidade exata de cada módulo precisa ser bem compreendida e alguns
dimensionamento inicial deve ser realizado para determinar quantos - e que tipo
- de usuários terão acesso a cada módulo.
As licenças estão frequentemente disponíveis nos seguintes tipos (a

terminologia exacta pode variar dependendo do software fornecedor).
8.5.1.1 licenças dedicados
Para uso por aqueles funcionários que requer o uso freqüente e prolongado do
módulo (ex. Service Desk equipe precisaria de uma licença dedicada para usar
um Gerenciamento de Incidentes módulo).
8.5.1.2 licenças partilhadas
Para o pessoal que fazem uso bastante regular do módulo, mas com intervalos
significativos no meio, então normalmente conseguem com uma licença
partilhada (por exemplo, terceira linha de apoio funcionários pode precisar de
acesso regular a um módulo de Gerenciamento de Incidentes - mas apenas nos
momentos em que eles estão ativamente da actualização de um registro de
incidente). A proporção de licenças para usuários precisa ser estimado, de modo
que o número correto de licenças podem ser comprados - isso vai depender do
número de usuários potenciais, a duração dos períodos de utilização e
freqüência esperada entre usos para dar uma estimativa de simultaneidade
nível.
O custo de uma licença compartilhada é geralmente mais caro do que o de

licenças dedicadas - mas o custo total é menor do que os usuários estão
compartilhando e menos licenças, são necessárias no total.
8.5.1.3 licenças Web

Normalmente, permitindo alguma forma de 'interface luz' via acesso à web para
as capacidades da ferramenta, esta é geralmente adequado para o pessoal que
deva acesso remoto, apenas o acesso ocasional, ou o uso de apenas um
pequeno subconjunto da funcionalidade (por exemplo, pessoal de engenharia
que desejam registrar detalhes de ações tomadas em incidentes ou usuários
apenas querendo registrar um incidente diretamente). Licenças web geralmente
custam menos do que muitos outras licenças (pode até ser livre com outras
licenças!) Ea proporção de uso também é muitas vezes menor - os custos de
forma geral são reduzidos ainda mais.
Note-se que alguns funcionários podem exigir o acesso a várias licenças (por
exemplo, pessoal de apoio podem necessitar de uma licença dedicado ou
compartilhado, quando no escritório durante o dia, mas pode necessitar de uma
licença web ao fornecer suporte fora do horário de casa). Tenha em mente que
as licenças podem ser necessários para clientes /usuários / fornecedores
usando a mesma ferramenta para entrada, visualizar ou atualizar registros ou
relatórios.
Nota: Algumas licença acordos (de qualquer um dos tipos mencionados acima)
pode limitar o uso do software de um dispositivo individual ou CPU!
8.5.1.4 Serviço sob demanda
Tem havido uma tendência na indústria de TI para fornecedors para oferecer TI

aplicaçãos "on demand", em que o acesso é dado ao aplicação por um período
de procura e, em seguida, cortado quando ele não é mais necessária - e
carregada na base do tempo gasto com a aplicação. Este tipo de oferta pode ser
oferecido por alguns fornecedores de ferramentas ITSM - o que poderia ser
atraente para organizações menores ou se as ferramentas em questão são
muito especializadas e utilizado com pouca frequência.
Uma alternativa a isto é que a utilização de uma ferramenta, é possível dentro

de uma atribuição de consultadoria específica (por exemplo, um especialista
Gerenciamento da Capacidade consultoria, por exemplo, que pode oferecer uma
regular, mas relativamente pouco frequentes Planejamento de Capacidade
pacote de consultadoria e proporcionar a utilização das ferramentas para a
duração do trabalho). Em tais casos, as taxas de licença são susceptíveis de ser
incluído como parte de, ou, uma adenda ao, a taxa de consultoria.
Outra variação é onde o software está licenciado e cobrado sobre um agente

/atividade base. Um exemplo disto é a interrogação /monitoramento e / ou
software de simulação (por exemplo, software agente que pode simular pré-
definidos cliente caminhos através de um organizaçãoSite 's, para avaliar e
relatar sobre atuação e disponibilidade). Tal software é tipicamente carregada na
base do número de agentes, a sua localização e / ou a quantidade de actividade
gerada.

Em todos os casos, as investigações completas da estrutura de licenciamento
deve ser investigada e bem entendido durante as investigações de contratos e
bem antes das ferramentas são implantados - de modo que a última palavra
custars não vem como qualquer tipo de surpresa.
8.5.2 Implantação
Muitas ferramentas ITSM, particularmente Discovery e ferramentas de

monitoramento de eventos, vai exigir alguma cliente/ Software agente
implantação em todos os locais-alvo, antes de poderem ser utilizados. Para isto
é necessário cuidado planejamento e execução - e deve ser tratada por meio
formal, Gerenciamento de Liberação e Implantação (Ver Transição de Serviço
publicação).
Mesmo nos casos em rede desenvolvimento é possível, esta tem programação

cuidadosa e testes - e registros deve ser mantida durante todo o lançamento de
modo que a equipe de suporte tem conhecimento de que tenha sido atualizado e
quem não tem. Alguma forma de interino Gestão da Mudança pode ser
necessário e que o CMS deve ser atualizado como o lançamento progride.
Muitas vezes, é necessário para uma reinicialização dos dispositivos para o

software cliente a ser reconhecido - e isso precisa ser organizado com
antecedência, caso contrário longos atrasos podem ocorrer se os funcionários
não costumam desligar seus computadores durante a noite.
Não pode ser especial problemas implantando em laptops e outros

equipamentos portáteis e arranjos especiais podem ser necessárias para o
pessoal para entrar e receber o novo software.
8.5.3 verifica a capacidade
Gestão da Capacidade alguns podem ser necessárias antes de assegurar que

todos os locais-alvo têm de armazenamento suficiente e processamento
capacidade para hospedar e executar o novo software - qualquer que não pode
terá atualização ou substituição, e os prazos para essas ações precisam ser
incluídos no planos.
A capacidade de a rede deve também ser verificada para determinar se ele pode
lidar com a transmissão de gestão da informação, A transmissão de arquivos de
log e distribuição de clientes, e também, possivelmente, software e configuração
arquivos.
8.5.4 O tempo de implantação de tecnologia
É necessário cuidado para assegurar que as ferramentas são implantados no

momento apropriado em relação ao organizaçãoNível "s de ITSM sofisticação e

conhecimento. Se as ferramentas são implantadas também em breve, eles
podem ser vistos como uma panacéia imediata e qualquer medida necessária
para mudar processos, trabalhando práticas ou atitudes podem ser dificultada ou
esquecido.
Uma ferramenta sozinha não é geralmente suficiente para fazer as coisas

funcionarem melhor. Há um velho ditado: "Um tolo com uma ferramenta ainda é
um idiota!"
A organização deve primeiramente examinar os processos que a ferramenta

está buscando resolver e também garantir que a equipe está "comprado em 'aos
novos processos e maneira de trabalhar e de ter um adoptou um"cultura de
serviço'.
Contudo, as ferramentas podem e muitas vezes fazem coisas uma realidade

para muitas pessoas - eles são funcionários tangível e técnico pode ver
imediatamente como os novos processos pode trabalhar e como eles podem
melhorar a sua forma de trabalhar.
Alguns processos simplesmente não pode ser feito sem ferramentas adequadas,
para que haja um equilíbrio cuidadoso para ser feito para assegurar
instrumentos são introduzidos quando eles são necessários - mas não antes!
Da mesma forma, é necessário cuidado para assegurar que a formação em

todas as ferramentas é fornecida no ponto correto - não muito cedo ou
conhecimento irá diminuir ou ser perdido, mas cedo o suficiente para que a
equipe pode ser formalmente treinados e totalmente familiarizar-se com a
operação das ferramentas bem antes de viver desenvolvimento. Treinamento
adicional deve ser planejada por um período adicional quando as ferramentas de
ir ao vivo e no futuro, se necessário.
8.5.5 Tipo de introdução
A decisão é necessária em que tipo de introdução é necessário - se a ir para a

introdução de um "Big Bang" ou algum tipo de abordagem faseada. Como a
maioria das organizações não será iniciado a partir de uma situação de «green
field», e terá serviços ao vivo para manter funcionando durante a introdução,
uma abordagem gradual é mais provável que seja necessário.
Em muitos casos, uma nova ferramenta vai substituir uma antiga, provavelmente
menos sofisticada ferramenta, ea transição entre os dois é outro fator a ser
planejado.
Isso muitas vezes envolvem decidir quais dados precisam ser transportado a
partir da ferramenta antiga para a nova - e isso pode exigir reformatação
significativa para alcançar os resultados necessários. Idealmente, esta

transferência deve ser feito eletronicamente -, mas, em alguns casos, uma
pequena quantidade de recodificação de dados em tempo real pode ser
inevitável e deve ser tido em conta o planos.
Atenção: ferramentas mais antigas geralmente contavam com mais entrada

manual e manutenção de dados por isso, se a migração de dados electrónica
está a ser utilizado, uma auditar deve ser realizada para verificar os dados
qualidade.
Quando a transferência de dados é complicado ou demorado de conseguir, uma

alternativa poderia ser a de permitir um período de execução paralelo - com a
antiga ferramenta estar disponível por um período inicial juntamente com o novo,
para que os dados históricos podem ser referenciados, se necessário. Em tais
casos, será prudente para tornar a ferramenta velha "somente leitura", para que
nenhum erro pode ser feita por registro de novos dados na ferramenta de idade.
Detalhes completos sobre o Gerenciamento de Liberação e Implantação

processo pode ser encontrada na publicação de Transição de Serviço

9 Desafios, Fatores Críticos de Sucesso e riscos
9,1 Desafios
Há uma série de desafios enfrentados dentro Operação de Serviço que
necessitam de ser superadas. Estes incluem as nesta seção.
9.1.1 A falta de compromisso com a equipe de desenvolvimento

e projeto
Tradicionalmente, tem havido uma separação entre o pessoal do Serviço de

Operação e os funcionários envolvidos no desenvolvimento de novos aplicaçãos
ou executando projetos que eventualmente proporcionar uma nova
funcionalidade no operacional ambiente.
Esta separação foi originalmente deliberada e orientada pelo desejo de impedir o

conluio e evitar potenciais segurança riscos (em algumas organizações ainda é
um legislativo exigência). No entanto, em vez de usar esta separação de
funções para criar contribuições positivas, em muitas organizações, é uma fonte
de rivalidade e de manobras políticas.
Com demasiada frequência, ITSM é visto como algo que foi iniciado nas áreas
operacionais e não é nada a ver com desenvolvimento ou projetos.
Esta visão é muito prejudicial como o momento adequado para estar pensando
em questões operação de serviço é no início de novos empreendimentos ou
projetos - quando ainda há tempo para incluir esses fatores na planejamento
fases.
O Design de Serviços e Transição de Serviço publicações descrevem os passos

necessários para assegurar que Operações de TI questões são consideradas
desde o início de novos empreendimentos e projetos.
Anedotas
Um organização usa uma operação "Transição-In Política"Para garantir que os

serviços a ser desenvolvidos tiveram o nível adequado de entrada das equipes
operacionais. Esta é basicamente uma política que mostra claramente em que
circunstâncias uma aplicação é 'pronto' para a transição para Operações. Isso
ajudou com a comunicação para o desenvolvimento e as equipes de projeto e
também um conjunto claro de diretrizs sobre como trabalhar com as equipes
operacionais.
Outra organização usa Operações Caso de Usos para obter as equipes de

desenvolvimento para incluir as exigências que devem ser cumpridas pelo

aplicação para ser executado em produção sob a controlar do pessoal de
operações.
9.1.2 financiamento Justificando
Muitas vezes, é difícil de justificar as despesas na área de operação de serviço,

como o dinheiro gasto nesta esfera é muitas vezes considerado como "infra-
estrutura custars '- com nada de novo para mostrar para o investimento.
O Estratégia de Serviço publicação discute a forma de garantir o retorno do

investimento e eliminar a percepção de investimento como uma infra-estrutura
puramente "despesas gerais'. Boa orientação é oferecido em forma de justificar
o investimento.
Na realidade, muitos investimentos em ITSM, particularmente no Operação de

Serviço áreas, pode economizar dinheiro e mostram um retorno positivo do
investimento -, bem como melhoria resultando em serviço qualidade. Alguns
exemplos de áreas potenciais de poupança incluem:
• Licença de software reduzido custars através de uma melhor gestão das

licenças e implantado cópias
• Redução de custos de suporte devido a menos incidentes e problemas e
reduzida resolução vezes
• Reduzido número de funcionários, através da racionalização da força de
trabalho, apoiando papels estruturas e prestação de contas
• Menos 'perda de negócios "devido à má De serviços de TI qualidade
• Melhor utilização de equipamentos de infra-estrutura existente e
diferimento das despesas ainda mais devido à melhor Gerenciamento da
Capacidade
• Melhor alinhado processos, levando a uma menor duplicação de
actividades e uma melhor utilização dos actuais recursos.
9.1.3 Desafios para os Gestores operação de serviço
O seguinte é uma lista de alguns dos desafios que os gerentes de Operação de

Serviço deve esperar a face. Não há solução fácil para estes desafios,
principalmente porque eles são produtos da organização cultura e as decisões
tomadas durante o processo de decidir a estrutura organizacional. O propósito
de incluir a lista é garantir que os gestores operação de serviço são conscientes
deles e pode criar um plano para lidar com eles.
As diferenças entre as atividades do projeto e atividades operacionais continuará

a apresentar desafios. Isto é para uma série de razões, incluindo o seguinte.
• Design de Serviços tendem a se concentrar em um indivíduo serviço de

cada vez, enquanto que Service Operation tende a concentrar-se no

fornecimento de todos os serviços de apoio e, ao mesmo tempo.
Gerentes operacionais devem trabalhar em estreita colaboração com o
Design de Serviços e Transição de Serviço para permitir uma perspectiva
de operação para assegurar que projeto e transição resultados apoiar o
geral operacional necessidades.
• Design de Serviços, muitas vezes, ser realizado em projetos, enquanto
operação de serviço se concentra em andamento, processos de gestão e
atividades repetitivas. O resultado disso é que o pessoal operacional
geralmente não estão disponíveis para participar em actividades de
serviços de concepção do projeto, que por sua vez resulta em serviços de
TI que são difíceis de operar, Ou que não incluem elementos adequados
de gerenciamento. Além disso, a equipe do projeto, uma vez terminar o
desenho de um serviço de TI que poderiam avançar para o próximo
projeto e não estar disponível para apoiar as dificuldades de
funcionamento ambiente. Superar esse desafio requer Operação de
Serviço para planejar o seu pessoal para participar activamente em
projectos de design, para recurso a transição atividades e participar de
Suporte de Vida precoce de serviços introduzidos no ambiente
operacional.
• As duas fases do ciclo de vida ter diferentes métricos, que incentiva
Design de Serviços para concluir o projeto a tempo, para especificação e
em orçamento. Em muitos casos, é difícil prever o que o serviço será
semelhante e quanto vai custar depois de ter sido implantado e operado
por algum tempo. Quando ele não é executado como esperado, TI
Gestão de Operações é responsável. Enquanto este desafio será sempre
uma realidade em Serviço de Gestão de, Isso pode ser abordada por
envolvimento activo na Transição de Serviço fase do ciclo de vida. O
objetivo de Transição de Serviço é garantir que os serviços projetados
vontade operar como esperado eo Operations Manager pode fornecer o
conhecimento necessário para a Transição de Serviço de avaliar e
remédio, problemas antes que se tornem problemas no operacional
ambiente.
• Transição de Serviço que não é utilizada de forma eficaz para gerir a
transição entre fases de projeto e de operação. Por exemplo, algumas
organizações podem usar apenas Gestão da Mudança para agendar a
desenvolvimento de mudanças que já foram feitas - em vez de testar para
ver se o mudar vai fazer com sucesso a transição entre concepção e
funcionamento. É imperativo que o práticas da Transição de Serviço são
seguidas e organização políticas para prevenir práticas de mudança mal
gerenciados estão no lugar. Gerentes de Mudança, operação e transição
deve ter a autoridade para negar quaisquer alterações no ambiente
operacional, sem exceção, que não são testados.
Esses desafios só podem ser tratados se Operação de Serviço funcionários

estão envolvidos em Design de Serviços e de transição, e isto irá exigir que
sejam formalmente encarregado e medidos para fazer isso. Papels identificados

nos processos de design de serviços devem ser incluídos na técnica e de TI
Aplicação de Gestão de pessoal descrição do trabalhos e a sua vez atribuídos
numa projetoA projecto base.
Outro conjunto de desafios refere-se a medição. Cada estrutura alternativa vai

apresentar diferentes combinações de itens que são fáceis ou difíceis de medir.
Por exemplo medindo a atuação de um dispositivo ou equipe pode ser
relativamente fácil, mas determinar se que o desempenho é bom ou ruim para o
geral De serviços de TI é outra questão. Um bom Gerenciamento de Nível de
Serviço processo vai ajudar a resolver isso, mas isso significa que as equipes de
operação de serviço deve ser parte integrante desse processo (ver Melhoria de
Serviço Continuada publicação).
Um terceiro conjunto de desafios diz respeito à utilização de equipes virtuais.

Tradicionais, estruturas de gestão hierárquicos estão se tornando inadequado
devido à complexidade e diversidade da maioria das organizações. Um
paradigma de gestão (Matrix Management) surgiu em que os funcionários
relatam a diferentes fontes para diferentes tarefas. Isso resultou em uma rede
complexa de responsabilidade e um aumento risco de actividades que através
das rachaduras. Por outro lado, ele também permite que a organização para
fazer habilidades e conhecimentos disponíveis onde eles são mais necessários
para suportar o negócio. Gestão do Conhecimento eo mapeamento das
estruturas de autoridade se tornará cada vez mais importante como
organizações expandir e diversificar. Isso é discutido no ITIL Estratégia de
Serviço publicação.
Um dos desafios mais significativos enfrentados por gerentes de operação de

serviço é o equilíbrio de muitos interno e externo relaçãos. A maioria das
organizações de TI de hoje são complexas e os serviços se tornam mais
comoditizado há um aumento do uso de rede de valors, parcerias serviços e
compartilhada modelos. Enquanto uma vantagem significativa para
dinamicamente a evolução das necessidades de negócio, o que aumenta a
complexidade dos serviços de gestão coesa, eficiente e fornecer a costura
invisível entre o cliente ea intrincada teia de como os serviços são realmente
entregues. Um Gerente de Operação de Serviço deve investir em conhecimento
de gestão de relacionamento e habilidades para ajudar a lidar com a
complexidade do desafio.

9,2 Fatores Críticos de Sucesso
9.2.1 Gestão de apoio
Apoio da gerência sênior e Médio é necessária para todas as atividades de

ITSM e processos, particularmente na Operação de Serviço.
Apoio da alta administração é fundamental para a obtenção e manutenção de

um financiamento adequado e mobilização de recursos. Ao invés de ver
Operação de Serviço como um "buraco negro" para o investimento, diretores
devem quantificar e defendem os benefícios da operação de serviço bom. Eles
também devem ser plenamente informados dos resultados terríveis que podem
ocorrer por causa da Operação de Serviço pobres.
A alta gerência deve dar apoio visível durante o lançamento de iniciativas novo
serviço de operação (como através de aparições em seminários, signatários
memorandos e anúncios, etc) e seu apoio em curso deve ser igualmente bem
demonstrada. Totalmente a mensagens errado pode ser dada se um gerente
sênior não ligar-se a uma importante projeto reunião ou seminário de
lançamento. Pior ainda são os gerentes seniores que apóiam a iniciativa
verbalmente, mas abusam de sua autoridade para incentivar a evasão da
operação do serviço prática.
Administradores também deve capacitar os gerentes médios, que será

diretamente responsável pela operação do serviço. Apoiar a iniciativa
publicamente, mas em seguida, substituindo orçamento exigências ou
mudanças necessárias, irá prejudicar tanto a implementação ea iniciativa
operação em curso de Serviço.
Gerentes de nível médio também deve fornecer o apoio necessário - e, em

particular, este deve ser demonstrado por suas ações. Se um gerente médio é
visto como a evasão ou substituindo um acordo procedimento (Por exemplo, a
implementação de um mudar que não tenha sido através da Gestão da Mudança
processo), Então isso dá a mensagem clara de que os outros podem fazer o
mesmo - e que o procedimento é inútil e pode ser ignorado por todos. Gerentes
de nível médio deve sair de seu caminho para tornar conhecido o seu apoio, não
apenas por suas palavras, mas também por suas ações e adesão ao
organização'S acordado processos e procedimentos.
Gerentes de nível médio também deve dar seu total apoio à contratação de
pessoal para apoiar o processo, em vez de aceitar a necessidade de operação
de serviço formalizada e, em seguida, o simples aumento do carga de trabalho
do pessoal existente para fazê-lo.

9.2.2 O apoio às empresas
É importante que o Unidade de Negócioss também apoiar a Operação de

Serviço. Este nível de apoio pode ser muito melhor alcançado se o pessoal
Operação de Serviço envolvem o negócio em todas as suas atividades e são
abertas em seus relatórios de ambos os sucessos e falhas - e seus esforços
para melhorar.
É igualmente importante que as Unidades de Negócio compreender, aceitar e

realizar a papel que desempenham na Operação de Serviço. Bom serviço requer
boa clientes! Aderindo às políticas, processos e procedimentos, tais como a
utilização do Service Desk para registro de todos os pedidos, é uma
responsabilidade direta do cliente para apoiar e promover dentro da empresa.
Comunicações regulares com o negócio para entender suas preocupações e

aspirações e dar feed-back sobre os esforços para satisfazer as suas
necessidades são essenciais na construção da correta relaçãos e garantindo
suporte contínuo.
Além disso, a empresa deve concordar com o custars para a implementação

Operação de Serviço e compreender o retorno sobre o investimento, a menos
que este já tiver sido aprovado como parte do processo de Design.
9.2.3 Campeões
Projetos de ITSM e da prática resultante em curso (realizada por pessoal

Operação de Serviço) são muitas vezes mais bem sucedido se um ou mais
"campeões" são próximas, que pode levar os outros através de seu entusiasmo
e compromisso para ITSM.
Em alguns casos, estes podem ser campeões gerentes seniores que estão
liderando desde o início. Mas campeões também pode ser bem sucedida se
forem provenientes de outros níveis da organização. Um ou dois equipe júnior
ainda pode ter uma influência significativa benéfico sobre uma conclusão bem
sucedida.
Campeões são muitas vezes criados ou fortemente influenciados por meio

formal, Serviço de Gestão de formação, especialmente em níveis mais
avançados, onde os benefícios potenciais para um organização, E para os
indivíduos que fazem uma carreira em Gestão de Serviços, pode ser totalmente
explorado.
Deve notar-se que ao longo do tempo campeões emergir. Eles não podem ser
criados ou nomeados. Muitas vezes, é usuários ou clientes que fornecem a
maior ajuda na criação de bons processos de gerenciamento de serviços como
eles estão bem conscientes das melhorias necessárias a partir de um

perspectiva de negócios. É importante reconhecer que estas são geralmente
pessoal altamente motivado, que muitas vezes voluntariamente assumir maior
carga de trabalhos. Se a sua entrada é para ser mais eficaz que deve ser dado
tempo para trabalhar como o campeão.
9.2.4 Recrutamento e retenção
Tendo o número adequado de funcionários com as competências adequadas é

fundamental para o sucesso da operação de serviço. Alguns dos desafios que
têm de ser ultrapassados incluem o seguinte.
• Projetos para novos serviços são geralmente muito bom sobre a

especificação exigidas novas habilidades, mas muitas vezes subestimar o
número de pessoal necessário e como reter as novas habilidades. Ver
ponto 9.2.1 para algumas idéias sobre como facilitar uma melhor
comunicação sobre exigências.
• Escassez de recursos que têm uma boa compreensão de Gerenciamento
de Serviço. Ter boas pessoas técnicas é necessária, mas é preciso haver
um número de pessoas-chave que são capazes de mover-se entre as
questões tecnológicas e problemas no serviço.
• Uma vez que esses recursos são bastante escassos, é bastante comum
para treiná-los, apenas para tê-los renunciar e se juntar a outra empresa
por um salário melhor. Planos de carreira e incentivos claros boas devem
fazer parte de todas as iniciativas de Gerenciamento de Serviços.
• A tentativa de atribuir muito, muito em breve, a equipe existente. Alcançar
eficiente Operação de Serviço Vai levar tempo, mas se aproximou
corretamente ele será alcançado. Infelizmente, alguns gerentes de tentar
acelerar a economia, atribuindo o trabalho provisório de implementação
de novos processos e ferramentas para existente, muito ocupado, a
equipe. Invariavelmente, ou o projeto falhar, ou serviço sofre e às vezes
valioso da equipe vai sair. Projetos de gestão bem-sucedida de serviço
muitas vezes requerem um investimento de curto prazo, quer pessoal
temporário ou contratados, e isso não deve ser subestimada.
9.2.5 formação em Gestão de Serviços
Formação adequada e conscientização pode ter muito mais amplos benefícios

globais. Bem como criar campeões de poucos, ele pode ser usado para ganhar
os "corações e mentes" de muitos. Operação de Serviço equipe todos devem
estar cientes das conseqüências de suas ações, boas e ruins, sobre o
organização - E todos devem ser instilado com um Gerenciamento de Serviços "
cultura'.
É possível ter o melhor funcionamento de serviço prática e ferramentas do

mundo - mas a gestão de serviço não será bem sucedida a menos que as
pessoas também estão em sintonia com o Gerenciamento de Serviços em geral

objetivos. Buy-in e apoio de todos os funcionários são, portanto, muito
importante - e do papel de formação e sensibilização, e mesmo formal,
qualificaçãos que beneficiar o indivíduo, não deve ser subestimada.
Formação exigida para o Gerenciamento de Serviços de sucesso inclui:
• Treinar a equipe de TI sobre os processos que têm sido implementadas.

Isso vai incluir o treinamento genérico para que eles entendam os
conceitos totalmente, bem como de treinamento especialmente voltado
para os processos da própria organização
• Formação em 'soft' ou habilidades "povo", especialmente para aqueles
funcionários clienteVoltado para posições
• Treinamento sobre o entendimento do negócio, bem como a importância
de alcançar um cultura de serviço
• Onde as ferramentas foram implementadas, formação sobre como usar e
gerenciar essas ferramentas
• Também, clientes e usuários precisam de formação adequada sobre
como trabalhar com TI - serviços de acesso, mudanças solicitado,
apresentar pedidos, ferramentas de uso, etc
9.2.6 Ferramentas adequadas
Muitos Operação de Serviço processos e atividades não podem ser realizadas

de forma eficaz sem instrumentos de apoio adequados (como descrito no
Capítulo 7). A alta gerência deve assegurar que o financiamento para tais
ferramentas está incluído no curso orçamentos e apoiar a sua aquisição,
desenvolvimento e manutenção contínua.
9.2.7 Validade dos testes
O qualidade de De serviços de TIs que podem ser fornecidos em Operação de

Serviço está dependente da qualidade dos sistemas e componentes entregues
na operacional ambiente.
O nível de qualidade será significativamente melhorada se os testes adequados

e completa de novos componentes e liberars é realizada em tempo útil.
Documentação também deve ser testado para a completude e qualidade.
Isto requer um ambiente de teste abrangente e realista de estar no lugar para

todos os sistemas / componentes - o que espelha o operacional ambiente em
termos de volume, bem como características. Não deve ser testadores
independentes sempre que possível. Financiamento para ambientes de teste é
essencial se serviços de alta qualidade devem ser atingidos.
Além disso, o tempo suficiente e esforço são necessários para assegurar que o
teste é devidamente planejado e projetado - e tempo adequado é incluído para

testes, e re-teste deve falhar algumas partes! A melhor maneira de garantir isso
é seguindo a orientação do Transição de Serviço publicação.
9.2.8 Medição e comunicação
Uma definição clara é necessária de como as coisas vão ser medido e indicado
(como descrito no Apêndice B) para que todos os funcionários têm metas claras
a atingir e gerentes de TI e de negócios são capazes de forma rápida e fácil
rever progredir e identificar eventuais áreas de atenção.

9,3 Riscos
O não cumprimento da desafios já descrito no capítulo 9.1 ou de abordar a Fator
Crítico de Sucessos descrito na seção 9.2 são óbvias riscos - mas outros são
descritos como estabelecido abaixo.
9.3.1 Serviço de perda
O risco final para o negócio de deficiências na Operação de Serviço é a perda

da crítica De serviços de TIs com subsequente adverso impacto em seus
colaboradores, clientes e finanças. Em casos extremos, pode haver perda de
potencial à vida e à integridade física, onde o De serviços de TIs afetados são
usados para a saúde crítica ou fins de segurança - como a implantação de
emergência do veículo ou a digitalização de saúde, etc
9.3.2 Os riscos para a operação de serviço de sucesso
O riscos para a realização bem sucedida Operação de Serviço são numerosos -

e em muitos casos são o oposto do Fator Crítico de Sucessos como descrito
anteriormente -, mas também incluem:
• Financiamento adequado e recursos: O financiamento deve ser

justificada, alocados e mantidos em reserva para sua finalidade original.
• Perda de dinamismo: Onde o pessoal ver Serviço de Gestão de como
"sabor do mês" em vez de alterar permanentemente a forma como eles
trabalham para o futuro, qualquer impulso é perdido como resultado: deve
ficar claro desde o início que uma nova forma de trabalhar é necessário.
Além disso, os mecanismos devem estar no local para garantir que a
iniciativa sobrevive mudanças organizacionais.
• Perda de pessoal-chave: Por vezes, a perda de um ou dois quadros
podem ter um grave impacto: Tentar minimizar esse efeito, as
organizações devem procurar cruz trem-pessoal e reduzir dependências
de indivíduos. Isto é especialmente verdadeiro em organizações menos
maduras, onde o conhecimento ainda não foi formalizada em processos,
documentos e ferramentas. Estas organizações tendem a ser dependente
de esforços "heróicos" de algumas pessoas experientes, e estão
arrasados quando eles saem.
• Resistência à mudar: Às vezes as pessoas opor-se coisas novas e estão
relutantes em levá-los a bordo. Educação, formação, comunicação e
destacando os benefícios vai ajudar.
• Falta de apoio à gestão: Este gerentes freqüentemente occursamong
Média, que não podem ver o geral visão ou ganhar as mãos sobre os
benefícios que mais a equipe júnior pode ganhar. Ver ponto 9.2.1 para
mais informações sobre isso, mas os gerentes precisam de apoio à
gestão de serviço e participar das fases e processos adequados de
Design de Serviços, Transição e operação de apoio tangível.

• Se o primeiro projeto é deficiente, Uma implementação bem-sucedida
nunca vai dar os resultados pretendidos - e redesenho acabará por ser
necessário.
• Em algumas organizações Serviço de Gestão pode ser vista com
desconfiança pela TI e do negócio. A equipe de TI vê-lo como uma
tentativa de controlar eles, enquanto a empresa percebe como uma
tentativa por parte de TI para obter mais financiamento sem realmente
melhorar qualquer coisa. Os benefícios do Gerenciamento de Serviço
deve ser claramente articulada para todos das partes interessadass.
• Diferindo cliente expectativas. Enquanto operacional funcionários são
incentivados a executar contra padrãos do cliente, e usuário expectativas,
por vezes, diferentes. Em outros casos, um cliente pode ter pago mais por
um serviço de qualidade superior, mas quando um usuário de uma área
diferente vê o serviço de qualidade superior, que se sentem enganados.
Este problema devem ser resolvidos através SLM clara e comunicação
cuidadosa durante Design de Serviços. Queixas dessa natureza devem
ser tomadas através Melhoria de Serviço Continuada processos e não
deve envolver simplesmente Operação de Serviço automaticamente
aumentando o serviço, mediante solicitação.

Posfácio
A simples verdade deve guiar-nos todos em operação do serviço. Negócios e
tecnologia continuarão a evoluir no futuro. O que foi no ano passado inovador é
comum este ano. O que é melhores práticas hoje vai ser comum amanhã. Atingir
a excelência na operação de serviço requer equilíbrio, flexibilidade e bom
julgamento no uso de ITIL práticas. A orientação desta publicação é a chave
para alcançar o conhecimento, a sabedoria futuro, visão ea capacidade de
equilibrar as necessidades de negócios de hoje e demanda de amanhã.
Comuns, bons, melhores práticas e futuro, tudo contribui para o objetivo de

serviço excelência. ITIL fornece-los como base para orientá-lo em direção a
esse objetivo.
Estabilidade num mundo em mudança é a realidade para Provedor de Serviços.

Aqueles que se destacam, e permanecer o melhor da raça, entender isso e
saber que o caminho para alcançar é adaptar, aprender, inovar e liderar.
O Operação de Serviço publicação é uma parte integrante de um conjunto ITSM

Ciclo de Vida prática, usados em conjunto, a prática de ITIL Serviço de Gestão
de constitui uma ferramenta poderosa nas mãos de qualquer prestador de
serviços.

Apêndice A: orientações da indústria Complementar
Quando ITIL foi introduzido pela primeira vez na década de 1980, havia pouco
mais disponível em termos de não-proprietária orientação sobre ITSM melhores
práticas.
Hoje, há outros frameworks ou metodologias que têm contributos válidos para

fazer nesta área, que se complementam e têm sinergia com ITIL e que podem
ser de ajuda para Operação de Serviço.

A1 COBIT
O COBIT quadro, produzido pelo Information Systems Audit e Control
Association (ISACA) e gerido pelo IT Governance Institute, oferece uma
estrutura muito útil de orientação para TI auditar e segurança pessoal.
A corrente versão do COBIT, edição 4, inclui 34 Controle de Alto Nível Objetivos,

dos quais 13 são agrupadas sob o "domínio Entregar e suporte ', que mapeia
muito de perto para ITIL'S fase de operação do serviço. Estes têm direito:
• DS1 Definir e gerenciar nível de serviços.

• DS2 Gerenciar serviços de terceiros.
• DS3 Manage atuação e capacidade.
• DS4 Assegurar serviço contínuo.
• DS5 Garantir a segurança dos sistemas.
• DS6 Identificar e alocar custars.
• DS7 Educar e treinar usuários.
• DS8 Gerenciar balcão de atendimento e incidentes.
• DS9 Gerenciar a configuração.
• DS10 Gerenciar problemas.
• DS11 Gerenciar dados.
• DS12 Gerenciar o físico ambiente.
• DS13 Gerenciar operações.
Alguns aspectos da Operação de Serviço também são tocados em alguns dos

controlar objetivos em outros domínios -, mas a grande maioria do que COBIT
tem a dizer sobre "oviver operação"Fase de TI está contido nos objetivos de
controle acima mencionados.
COBIT é destinado principalmente a auditores, por isso tem uma ênfase sobre o
que deve ser auditado e como, em vez de incluir uma orientação detalhada para
aqueles que estão operando os processos que serão auditados - mas tem um
monte de material válido que as organizações podem achar útil.
Deve notar-se que COBIT e ITIL não são "competitivo" nem são mutuamente
exclusivos - pelo contrário, eles podem ser usados em conjunto, como parte de
um organização'S em geral e gerencial governo quadro. ITIL fornece uma
organização com as melhores práticas de orientação sobre como gerenciar e
melhorar a sua processo para fornecer altaqualidade, O custo-benefício De
serviços de TIs. COBIT fornece orientação sobre como estes processos devem
ser auditados e avaliados para determinar se eles estão operando conforme o
previsto e dar melhor benefício para a organização.
Para um quadro mais completo no geral, as organizações podem desejar ler e

familiarizar-se com o que tem a dizer COBIT ao lado de sua leitura e

compreensão do ITIL. Mais pormenores sobre o padrão pode ser encontrada
através da ISACA, em www.isaca.org

A2 ISO / IEC 20000
Em dezembro de 2005, o International Standards Organization lançou um
internacional formal padrão, ISO / ISE 20000, contra a qual as organizações
podem solicitar a acreditação independente para ITSM. Esta foi precedida por
uma norma britânica, BS15000, que foi originalmente lançado em 2000 e em
que algumas organizações se tornou acreditado, Mas foi substituída pela ISO /
ISE 20000 e acreditações foram transitadas.
Enquanto ISO / IEC 20000 inicialmente mapeada para o Serviço de Apoio antes
e publicação de Prestação de Serviços do ITIL, o padrão continua a mapear bem
a ITIL hoje e também cobre Segurança de TI, Gestão de Relacionamento com
Empresas e Gestão de Fornecedores.
Para as organizações que buscam acreditação formal a norma ISO / IEC 20000,
de modo a obter o reconhecimento externo, internacional para o êxito de seus
processos de ITSM, haverá um envolvimento significativo por pessoal Operação
de Serviço na preparação e sofrer a vigilância formal necessário para atingir o
padrão .
Mais detalhes sobre o padrão podem ser encontradas através do itSMF em

www.itsmf.com ou o ISO em www.iso.org

A3 CMMI
O Capability Maturity Model ® Integration (CMMI) é uma abordagem de melhoria
de processos desenvolvido pelo Software Engineering Institute (SEI) da
Carnegie Mellon Universidade. CMMI fornece às organizações os elementos
essenciais de processos efetivos. Ele pode ser usado para guiar a melhoria do
processo através de um projeto, Uma divisão, ou uma organização inteira. CMMI
ajuda a integrar tradicionalmente organizacional separada funçãos, definir metas
de melhoria de processos e prioridades, fornecer orientações para qualidade
processos e fornecer um ponto de referência para a avaliação de processos
atuais. Para mais informações, consulte http://www.sei.cmu.edu/cmmi/
Organizações de consultoria Um número de TI ter construído o maturidade

modelo em seu ITSM avaliação serviços, como forma de preparar-se para
organizações que ajudam e melhorias de processo juiz - incluindo os do
Operação de Serviço área. Organizações podem querer usar alguma forma de
modelo para ajudar a conduzir o seu caminho para a independência ISO /
20.000 ISE acreditação
Balanced Scorecard A4
Uma nova abordagem para estratégico gestão foi desenvolvido no início de 1990
pelos drs. Robert Kaplan (Harvard Negócio Escola) E David Norton. Eles
chamaram esta sistema o 'Balanced Scorecard'. Reconhecendo alguns dos
pontos fracos e imprecisões de abordagens de gestão anteriores, a abordagem
do balanced scorecard fornece uma prescrição clara sobre o que as empresas
devem medir a fim de "equilibrar" a perspectiva financeira. O Balanced
Scorecard sugere que o organização é visto a partir de quatro perspectivas, e é
valiosa para o desenvolvimento métricos, coletar dados e analisá-lo em relação
a cada uma dessas perspectivas:
• A Perspectiva de Aprendizado e Crescimento

• O Business Process Perspectiva
• O Cliente Perspectiva
• As Perspectivas Financeiras.
Algumas organizações podem optar por usar o método Balanced Scorecard

como uma forma de avaliar e relatar sua TI qualidade atuação em geral, e seu
desempenho Operação de Serviço, em particular.
Mais detalhes estão disponíveis através da Comunidade Balanced Scorecard do

usuário no www.scorecardsupport.com

A5 de Gestão da Qualidade
Há vantagens distintas de amarrar processos de uma organização, e os
processos de ITSM operação do serviço, em particular, à sua sistema de gestão
da qualidade. Se uma organização tem uma qualidade formal sistema de gestão
tais como ISO9000, Six Sigma, TQM etc, então isso pode ser usado para avaliar
o progresso regularmente e impulsionar concordou serviço iniciativas de
melhoria através de regular revers e relatórios.
Muitas organizações têm usado uma ordinária anual auditar ou externa

avaliação como uma forma de determinar as melhorias necessárias - e então
sua Gestão da Qualidade sistema de carro pelo específica programas de
trabalho.
A6 ITIL eo Quadro OSI

Em torno do tempo em que ITIL v1 estava sendo escrito, o International
Standards Organization lançou uma iniciativa que resultou no quadro de
Interconexão de Sistemas Abertos (OSI). Uma vez que esta iniciativa coberto
muitas das mesmas áreas como fez a equipe de ITIL, não é surpreendente que
eles cobriram grande parte do mesmo terreno.
No entanto, também não é de surpreender que eles classificaram os seus

processos de maneira diferente, utilizada uma terminologia diferente, ou a
mesma terminologia utilizada de diferentes maneiras. Para confundir ainda mais,
é comum para os diferentes grupos em uma organização para usar a
terminologia de ambos ITIL eo quadro OSI.
Embora não seja no escopo desta publicação para explorar o quadro OSI, ele
fez contribuições significativas para a definição e execução de programas de
ITSM e projetos em todo o mundo. Ela também causou um grande debate entre
as equipes que não percebem as origens da terminologia que eles estão
usando.
Por exemplo, algumas organizações têm dois Gestão da Mudança

departamentos - um após o Change Management ITIL processo e outro com a
utilização de instalação da OSI, movimentos, adições e mudanças (IMAC)
modelo. Cada departamento está convencido de que é completamente diferente
do outro, e que realizam diferentes papels. Uma análise mais atenta revela que
há várias áreas de comunalidade.
Em Operação de Serviço, A gestão dos Erro Conhecidos pode ser mapeado

para gerenciamento de falhas. Existe também uma secção relacionada com

Operational Gerenciamento da Capacidade, O que pode estar relacionado com
o conceito da OSI Gestão de Desempenho.

Apêndice B: Comunicação na Operação de Serviço
Comunicação B1 rotina operacional
Maior parte da comunicação na Operação de Serviço tem a ver com a garantia
de que todas as equipes e departamentos são capazes de executar as
atividades normais envolvidos no fornecimento de De serviços de TIs e
gerenciar a infra-estrutura de TI.

Séria consideração deve ser dada durante Design de Serviços à definição do
conteúdo, tipo e formato de comunicação que é necessário para operar Serviços
de TI.
Propósito • Para coordenar as atividades regulares de operação de serviço em todos

os níveis.
• Para garantir que todos os funcionários estão cientes do programado
atividade em todos os momentos e que está ciente de quaisquer
alterações ou iniciativas que possam afectar o normal operação da TI
ambiente
Freqüência Este tipo de comunicação é regular e é comunicada em ciclos diários, semanais e

mensais
Papel • Todos os gerentes e funcionários envolvidos na operação de serviço

Jogadores • Todos gerente de processos de processos executados por pessoal
Operação de Serviço - especialmente mudanças, incidentes e
Gerenciamento de Problemas
• Clientes e usuários
• Vendedor pessoal envolvido na operação de serviço
Conteúdo • Resumir eventos desde a última comunicação para garantir que todos
estejam cientes de qualquer acompanhamento que precisa ocorrer.
Também para garantir que todos os lotes foram concluídas e as equipes
ou departamentos estão prontos para o padrão operacional atividade
• Um relatório sobre a saúde dos principais sistemas
• Informar Gestão de Operações pessoal de qualquer notícia ou eventos
que podem afetar as operações nesse período
• Discuta qualquer notável problemas ou incidentes e garantir que uma
ação plano está no lugar para cada
• Discutir o cronograma de mudanças que se espera que sejam feitas
durante o dia, juntamente com um briefing de potenciais incidentes que
podem ocorrer como resultado ea ação apropriada a ser tomada. Isto não
deve ser confundido com a reunião do CAB. Esta é uma oportunidade
para verificar se as mudanças que foram acordadas e agendada pelo
CAB, ou através de um Mudança do modelo, Ainda estão no caminho
certo
• Qualquer manutenção planejada ou interrupções outras que foram
agendadas para o próximo período operacional
• Anúncio dos resultados de qualquer post mortem ou reuniões de crise
que foram realizadas desde a anterior comunicação
• Anúncio ou lembrete de treinamento que pode estar disponível durante a
próxima semana ou mês para dar o seu tempo pessoal e supervisores
para agendar o treinamento para o Horário de Operações
Contexto / • Logs operações

fontes • Relatórios de Incidentes
• Relatórios de Problemas
• Horários de manutenção

• Alterar agendamento
Tabela B.1 requisitos de comunicação em serviços de TI

Comunicação B2 entre os turnos
Nem todas as organizações trabalham em deslocars, mas para aqueles que o
fazem, Tabela B.2 irá resumir a comunicação que precisa ocorrer entre os
turnos.
Propósito Esta comunicação garante que a transferência entre turnos de entrada e saída é
suave e também faz com que a nova mudança consciente de eventuais
dificuldades. Eles também garantem que a nova mudança está ciente de todas
as tarefas que precisam ser concluídas.
Freqüência Aquando da entrega de cada turno
Jogadores • Mudar líderes de cada turno

de papel • Pessoal de cada turno que realizam tarefas semelhantes ·
Conteúdo • Um relatório de síntese sobre as operações realizadas durante o turno

anterior
• Um resumo de todas as exceções e alertars que foram resolvidos
durante o deslocar
• Pormenores de quaisquer exceções notáveis e alertas, com informações
sobre todas as ações tomadas até o ponto atual e qualquer informação
sobre futuras ações previstas (por exemplo, um fornecedor deverá estar
no local para prestar apoio durante os próximos quatro horas) ·
Contexto / A comunicação entre turnos normalmente irá basear-se nas seguintes fontes: ·
fontes
• Toras turno
• Mudar relatório Líder
• Interpessoal verbal ou eletrônica 'chat' de comunicação, onde o pessoal
de mudança estão em diferentes instalações
Tabela B.2 requisitos de comunicação entre os turnos

B3 Relato de Desempenho
Relatórios de desempenho no contexto da comunicação refere-se a três áreas
principais, conforme estabelecido a seguir. Além disso, as Tabelas B.3-B.5
respectivamente ilustram as três abordagens.
IT Performance Serviço
Este categoria de Relatórios de Desempenho geralmente é feito como parte de

SLM e é coberto no Melhoria de Serviço Continuada publicação. No entanto, não
é um aspecto muito importante da Serviço de Relatórios que as preocupações
Operação de Serviço, Ou seja, que são as equipes de serviço de operação ou
departamentos que são necessárias para registrar e comunicar a informação
que vai para esses relatórios.
No entanto, a equipe serviço de operação não estão na melhor posição para decidir
sobre o conteúdo, formato e periodicidade dos relatórios de desempenho do serviço. O
exigências para este tipo de comunicação tem que ser para ser claramente definidas
durante Design de Serviços e refinados durante Melhoria de Serviço Continuada.
Propósito Para fornecer informações para os grupos responsáveis por TI relatórios

de serviço para clientes e usuários, o que eles podem usar para
demonstrar o cumprimento das metas de serviço e como entrada para
Nível de Serviço Comente reuniões A informação pode também ser
utilizada como uma base para a carregamento para De serviços de TIs
Freqüência Conforme definido no SLA e OLA. Esta informação é normalmente

comunicado regularmente em uma base diária, mensal e trimestral.
Papel • Serviço equipes de operação e departamentos, geralmente

Jogadores Operações de TI pessoal
• SLM equipe
• As equipes de projeto de serviços (que ajudam a definir atuação
padrãos e aperfeiçoá-los através de Melhoria de Serviço
Continuada)
• Equipes de serviço contínuo de melhoria, especialmente aqueles
encarregados de Serviço de Relatórios
Conteúdo Exemplos do tipo de informações de desempenho do serviço que precisa

ser comunicada para permitir relatórios sobre o desempenho do serviço
são:
• Realização de atividades específicas definidas no OLAs

• Cumprimento de metas de entrega de saídas especificadas
• Serviço ou sistema disponibilidade realizações
• Capacidade de atender Objetivo de manutenção do serviços
vezes dentro visados e impacto níveis

Contexto / • Monitoramento e ferramentas de relatórios
fontes • Evento Logs
• Logs turno
Tabela B.3 requisitos relatórios de desempenho: de serviços de TI

Equipe do Serviço de Operação ou desempenho departamento
Esta é uma comunicação "interno" na medida em que ocorre entre os membros

de uma equipe ou departamento e seu gerente, ou um gerente de processo e da
equipe que executa o processo. As pessoas de fora dessas equipes ou
departamentos não devem ser envolvidos neste tipo de comunicação, uma vez
que visa a gestão de pessoas, em vez de medir o qualidade de um serviço.
No entanto, é um erro comum para os departamentos de TI para comunicar este

tipo de informação para clientes como se fosse o mesmo que informar sobre
Qualidade de Serviço. Por exemplo, um gerente pode relatar que o seu
departamento resolve 80% de toda a problemas. No que diz respeito à média
usuário está em causa, no entanto, esta informação é irrelevante. Eles estão
mais preocupados em saber se o serviço de TI se comportou conforme o
acordado. Além disso, a divulgação de informações internas para clientes e
usuários pode ser embaraçoso para o Operação de Serviço equipes e
departamentos e pode resultar em altos níveis de interferência do negócio para
"corrigir" problemas percebidos.
Propósito Existem três objetivos principais da equipe de Serviço de Operação ou

comunicação Desempenho departamento:
• Proativamente, para garantir que o pessoal Operação de Serviço estão

executando as atividades necessárias para entregar De serviços de TIs e
para apoiar o Infraestrutura de TI
• Para detectar possíveis problemas com recurso níveis, capacidade e
evasão de procedimentos
• Para assegurar que a ação corretiva foi corretamente implementado e
respeitado
Freqüência Não existe uma frequência definida para este tipo de comunicação. Embora
alguns relatórios de desempenho podem ser produzidos diariamente,
semanalmente ou mensalmente, a maioria dos gestores estão envolvidos em
comunicação permanente com suas equipes ou departamentos como a situação
exige.
Em situações normais de funcionamento, a presente comunicação tem tendência

para ser menos frequente do que em situações em que existe um elevado grau
de mudar ou em que o organização está experimentando um elevado número ea
gravidade dos incidentes
Papel • Operação de Serviço Gerentes

Jogadores • Pessoal Operação de Serviço
• Problemas de desempenho pode ser escalado para o Service Manager
ou CIO
Conteúdo • Comparação entre requerida e real atuação

• Tendências de desempenho ao longo do tempo

• Relatórios específicos de má conduta ou falha para executar uma ação
necessária
Contexto / • Relatórios periódicos de desempenho, por exemplo, Registros de

fontes incidentes, manutenção registros, processo métricos
• Comunicação interpessoal e verbal durante situações de trabalho
• Equipe ou departamento reuniões
• Coaching por um líder de equipe ou gerente
• Investigação após um Relatório de Serviço pobres podem iniciar uma
série de comunicações em Operação de Serviço
• Avaliações de desempenho individuais, geralmente usando (KPIs)
documentada no do indivíduo descrição do trabalho
Tabela B.4 requisitos relatórios de desempenho: equipe de operação de serviço ou

departamento

Infra-estrutura ou o desempenho do processo
Como com a equipe ou o desempenho do departamento, esta é uma

comunicação "interno" que ocorre entre os membros de uma equipe ou
departamento que são responsáveis pela gestão de uma infra-estrutura
componente ou sistema, Ou os membros de uma equipe de processo. As
pessoas de fora dessas equipes não devem ser envolvidos neste tipo de
comunicação, uma vez que visa a gestão de pessoas, em vez de medir a
qualidade de um serviço.
Propósito Existem pelo menos três finalidades deste tipo de comunicação: ·
• Para assegurar normais operação da infra-estrutura ou um processo

• Para detectar possíveis problemas com a infra-estrutura ou processo em
causa
• Para assegurar que a ação corretiva foi tomada e que era eficaz
Freqüência A frequência deste tipo de comunicação irá variar dependendo da natureza do

sistema(S) a ser gerido ou a processo sendo executado.
Alguns componentes da infra-estrutura são mais voláteis e irá requerer

frequentes comunicações e mesmo reuniões para garantir que ele executa
previsível. Componentes mais estáveis simplesmente exigem uma confirmação
de que tudo ainda está funcionando como esperado.
Alguns processos têm exigência de comunicação freqüente e de comunicação.

Por exemplo, a Gerenciamento de Incidentes pode exigir atualizações a cada
cinco minutos para uma altaimpacto incidente. Outros processos não precisa
comunicar que com freqüência. Por exemplo Planejamento de Capacidade
precisa comunicar mudanças em uma base mensal ou mesmo trimestrais.
Papel • Funcionários que gerenciar CIs chave

Jogadores • Pessoal que executar processos
• Proprietário do processos e gerentes de tecnologia
• Potencial escalada para os gestores mais seniores, a Service Manager
Conteúdo • Comparação entre requerida e real atuação

• Tendências de desempenho ao longo do tempo
• Relatórios específicos de objectivos falhados ou níveis inesperados de
desempenho
Contexto / • Evento Logs

fontes • Desempenho do Sistema Registros
• Relatórios de desempenho de processo
• Incidente e Grave problemas
• Relatório de ExceçãoRelatórios s e Auditoria
• Comente com o fornecedor
• Serviço de Relatórios pode indicar um problema com uma ou mais áreas

de tecnologia ou processos
Tabela B.5 Desempenho requisitos Relato: infra-estrutura ou processo

B4 Comunicação em projetos
Operação de Serviço funcionários estão freqüentemente envolvidos em projetos.
Isto pode ser para fornecer a entrada para um novo projeto, Ou para ajudar no
controlo da utilização ou rendimento taxas, ou para ajudar na realização de
testes de serviços novos ou alterados. Em outros casos, os projetos podem
afetar OLAs existentes e seus comentários serão necessários. Deve ser
reconhecido que este envolvimento irá adicionar para o nível de comunicação
que estes indivíduos será a recepção e transmissão. Isso vai exigir mais tempo e
foco, que devem ser autorizados pelo atribuindo gerentes recursos para projetos
em regime de part-time.
Propósito Comunicação do projeto, como a múltiplos propósitos, incluindo:
• Para ganhar o apoio de projeto das partes interessadass - esta

comunicação incidirá sobre a escopo,custar e benefícios do projeto e
procurará demonstrar um retorno total do investimento do projeto
• Para garantir que todos os membros da equipe do projeto entender e são
alinhados à objetivos do projeto
• Para atribuir trabalho a indivíduos ou equipes
• Para agendar as atividades e garantir que recursos estão prontos para
começar a sua fase do projeto
• Para verificar e relatar o progresso do projeto
• Para detectar e escalar exceções em potencial ou atrasos no projeto
• Para preparar projeto clientes e audiências para a lançamento da solução
a ser construído
Freqüência A freqüência, papel jogadores e conteúdos de comunicação irá depender da

natureza do projecto e do tipo de metodologia Project Management sendo usado
Comunicação tabela B.6 no âmbito de projectos
Comunicação formal do projeto tende a seguir o ciclo de reuniões do projeto. Por

exemplo:
• Reuniões semanais ou mensais do projeto será realizada com o Gerente

de Projeto e os líderes individuais da equipe
• Uma atualização de status mensal será enviado para o patrocinador do
projeto executivo e, possivelmente, outros chave das partes
interessadass
• Exceções eo resultado de garantia de qualidade verificações são
relatados em equipes de projeto Assurance, que por sua vez irá
comunicar a necessidade de medidas corretivas, se necessário.
Dentro de cada equipe, a comunicação será mais focado em completar suas

tarefas e, geralmente, mais frequente do que a comunicação do projeto como
um todo.

Não é provável que seja um alto nível de comunicação menos formal, dentro de
cada equipe e também entre as equipes para garantir que as tarefas sejam
concluídas em tempo e recursos prometidos estão disponíveis quando e onde
eles deveriam estar. Comunicação extensiva também é necessária como parte
da entrega de uma equipe para outra, como o projeto se move de um estágio ou
fase para outra. Uma importante regra de ouro é para documentar qualquer
comunicação que pode potencialmente afetar o resultado ou o custar do projeto.
Jogadores de • Gerente de Projeto e pessoal administrativo do projeto e coordenação

papel • Patrocinador do Projeto
• Principais stakeholders do projeto (por exemplo, clientes, Gerentes de
TI, membros do Conselho, usuários, etc)
• Projeto equipes e colaboradores individuais
• Vendedor de vendas e pessoal técnico, onde a aquisição de serviços
ou soluções fazem parte do projeto
Conteúdo • Coleta exigências para a solução que está sendo construída pelo
projeto
• Programação de projetos
• Informações 'Marketing' do projeto, incluindo retorno do investimento ou
Business Case informação
• Atualizações de status
• Coleta de informações para concluir uma tarefa
• Eventos que podem afetar a escopo,custar ou a conclusão atempada
do projecto
• Relatório de progresso dentro das equipes e entre equipes
• Informações sobre os resultados dos testes
• Notificações para as equipes ou indivíduos que o projeto está se
aproximando 'seu' palco ou atividade e que eles devem fazer os
preparativos adequados
• O relatório sobre a conclusão bem sucedida das atividades
• Revisão do sucesso global do projecto ·
Contexto / • Projeto Carta

fontes • Projeto Orçamento
• Declaração de requisitos
• Cronograma do Projeto
• Reuniões de projeto
• Reuniões de equipe
• Relatórios de status e progresso
• Teste relatórios
• Cliente sign-off documentação
• Pós-Implementação comentário ·
Comunicação Tabela B.7 na entrega de projetos

A comunicação relacionada com alterações B5
Gestão da Mudança é tratada em pormenor na ITIL Transição de Serviço
publicação e inclui informações sobre a comunicação da mudança. No entanto,
é necessário sublinhar a natureza da operacional comunicação sobre as
mudanças.
Propósito Para apoiar a Gestão da Mudança processo por: ·
• A avaliação do potencial impacto e de recursos requerido para a

alteração
• Garantir que cada equipe está ciente da natureza e cronograma de
mudanças que têm sido atribuídos a eles
• Construção, testes e implantação de mudanças em seu ambiente
• Garantir que cada equipe relata que o progresso em cada mudança
• Gestão da Mudança notificando que um mudar está pronto para
desenvolvimento
• Fazendo as mudanças que não tiveram sucesso e comunicar os
resultados à Gestão da Mudança
• Auxiliando na avaliação de mudanças para garantir que eles foram
implementados corretamente
Freqüência A frequência de comunicação relacionada com alterações é determinada pela

natureza da alteração e os tempos estabelecidos na Alterar agendamento.
A maioria das equipes ou departamentos vontade rever mudanças em uma base

diária ou semanal. Cada dia eles vão discutir e priorizar todas as novas
alterações que lhes foram atribuídos e relatar o progresso das mudanças que
estão trabalhando. Após cada mudança que apresentará um relatório sobre o
sucesso de cada mudança e garantir que qualquer ação corretiva necessária é
iniciado.
Papel • Change Manager, administradores e coordenadores

Jogadores • Equipe-líderes, chefes de departamento, gerentes de turno ou Projeto
Gerentes
• Operação de Serviço pessoal envolvido na construção, testes e
implantação de mudanças (geralmente as técnicas de aplicação, e TI
Gestão de Operações equipes ou departamento)
• Gestores de Ambiente de Testes e equipes
• Alterar ou Solte Equipes de implantação
Conteúdo • Os pedidos de autorização e de mudanças

• Relatórios sobre a viabilidade de uma mudança
• Relatórios sobre a recursos obrigadas a construir,teste ou implantar uma
mudança
• Alterar Programação de atividades
• Descrições detalhadas da mudança e as atividades necessárias de cada
equipe ou departamento

• Progresso e Relatório de status da mudança atividade
• Teste resultados
• Relatório de Exceçãos, incluindo detalhes da execução de Voltar-out
Planos
Contexto / • RFCs
fontes • Alterar comunicação Controle (durante a diária ou semanal operacional
reuniões, ou por e-mail conferência, chamar ou utilizando o Gestão da
Mudança ferramentas)
• Alterar Conselho Consultivo reuniões
• Solte Planos
• Projetada relatórios disponibilidade do serviço ·
• Mudar Comentes
Comunicação Tabela B.8 sobre mudanças

B6 comunicação relacionada com exceções
Neste contexto, uma excepção refere-se a qualquer acontecimento que está fora
normal ou esperado atividade ou atuação. A forma mais comum de exceção é
um incidente (o que é abordado em detalhes na seção 4.2 desta publicação). Há
outras exceções que não necessariamente passam pela gestão de incidentes,
tais como uma processo exceção (que será tratada no contexto desse processo
ou por uma Garantia de Qualidade processo), uma equipe do departamento ou
indivíduo cujo desempenho não é até normal (que será feita através de RH
disciplinar procedimentos), ou uma exceção para o desempenho contratual de
um fornecedor. Embora estes não estão diretamente relacionados com a Serviço
de Gestão de, Eles vão adicionar despesas geraiss para o nível de comunicação
necessária do pessoal durante o Operação de Serviço fase.
Propósito Comunicação durante ou após exceções visa:
• Informar as pessoas apropriadas da exceção

• Avaliar a importância, gravidade e impacto da excepção
• Garantir que recursos com as competências adequadas e antiguidade
estão envolvidos na resolução da exceção e tomar medidas para evitar a
recorrência futuro
• Fornecer atualizações para das partes interessadass que são afetadas
pela excepção
Freqüência Este tipo de comunicação é reactivo e ad hoc, na medida em que não ocorre a
menos que haja uma excepção identificados ou a risco de uma exceção. A
freqüência é, portanto, diretamente proporcional à freqüência de exceções.
Uma vez que uma excepção é detectada, a frequência e o conteúdo da

comunicação será determinada pelo impacto, urgência e da gravidade da
excepção.
Papel Os jogadores papel exacto dependerá do tipo e da extensão da excepção, mas

Jogadores podem incluir:
• Gerenciamento de Incidentes
• O Service Desk
• Gerenciamento de Problemas
• Proprietário do processos (se relaciona com a excepção processo
atuação)
• Gerentes de departamento ou equipe de líderes
• SLM
• Gestão de Recursos Humanos
• Os gerentes de tecnologia e especialistas
• Vendedor equipe de gerenciamento de conta
• Vendedor especialistas técnicos

Conteúdo • Descrição e avaliação da excepção
• Avaliação da impacto. Isto irá tipicamente envolvem a comunicação com
o das partes interessadass que são afetadas pela excepção
• Estimativa e, em seguida, a confirmação da custar de resolução
• A decisão sobre que ações serão tomadas
• Comunicação da decisão tomada. Isto é susceptível de ser de uma série
de formatos. Por exemplo, a comunicação de clientes é susceptível de
conter um pedido de desculpas e uma visão geral de alto nível do que
está sendo feito para resolver a exceção. A comunicação com as
pessoas que são esperadas para resolver a exceção será mais detalhada
e conter ações e prazos
• A confirmação de que a exceção foi resolvido
Contexto / • Processo Comentes

fontes • Alterar Comentários
• Nível de Serviço Comentários
• Eventos
• Análise de Tendências de processos, dispositivos de equipe, atuação, Etc
• Problema incidente, e Alteração do registros
• Cliente pesquisas de satisfação.
Comunicação Tabela B.9 durante exceções

Comunicação B7 relação às emergências
Embora ITIL especifica como lidar com urgência, de altaimpacto situações como
desastres (Gerenciamento da Continuidade do Serviço) E Incidente graves
(Gerenciamento de Incidentes), Os gerentes na fase de operação de serviço vão
encontrar-se lidar com diferentes tipos e escalas de emergência não previstas
nestes processos. É importante notar que esta não é uma separada processo,
Em vez disso, é uma vista de vários processos e situações de uma perspectiva
de comunicação.
Comunicação em situações de emergência é semelhante em propósito e

conteúdo para a comunicação durante exceções. As principais diferenças são no
nível de urgência e impacto da exceção.
Comunicações de emergência são geralmente iniciada pelo Gerente de

Incidentes (ver ponto 4.2.5 para uma discussão sobre incidentes graves) ou por
um gerente de TI sênior, que foi designado como o escalada ponto para todas
as emergências.
No caso em que um TI Plano de Continuidade do Serviço é chamado, isso vai

incluir um Plano de Comunicação detalhada a ser executada pela autoridade
competente.
O Gerente de Incidentes ou gerente designado, muitas vezes, formar uma

equipe de resposta, ea comunicação é iniciada e coordenada por esta equipe.
Propósito O objetivo da comunicação em caso de emergência é imediatamente investigar e

confirmar o impacto ea gravidade do incidente para confirmar que ele é realmente
uma situação de emergência. Ele também deve confirmar que este incidente não
representa um desastre ou qualquer eventualidade coberta nos Planos de
Continuidade de Serviços de TI.
Logo que o escopo da emergência foi identificado, a equipe responsável por gerir
a situação irá alocar recursos para criar uma ação plano e para começar a
resolver a situação de emergência e restabelecer o serviço.
Freqüência Este tipo de comunicação não ocorre a menos que haja um Incidente grave ou
situação de emergência.
Uma vez que uma excepção é detectada, a frequência e o conteúdo da

comunicação será determinada pelo impacto e gravidade de excepção, e,
potencialmente, por um Serviço Recuperação Plano.
Papel • Gerente de Incidentes

Jogadores • Administradores de grupos responsáveis pela equipe de TI que serão
necessários para resolver a situação
• Os gerentes de negócios e Executivos (possivelmente incluindo o pessoal
legal, se o organização é exposto a uma acção judicial potencial como

resultado da incidente)
• Clientes e usuários
• Serviços de TI Gerente de continuidade e equipe de coordenação central
• Equipe vendedor sênior e gerentes (dependendo da extensão e da
natureza da situação) ·
• Gestão Técnica funcionários e gerentes
• Aplicação de Gestão de funcionários e gerentes
• TI Gestão de Operações funcionários e gerentes
Conteúdo • A natureza e extensão da situação de emergência

• Avaliação do impacto. Isto irá tipicamente envolvem a comunicação com
o das partes interessadass que são afetadas pela excepção
• Estimativa e, em seguida, a confirmação da custar de resolução
• A decisão sobre que ações serão tomadas
• Comunicação da decisão tomada. Isto é susceptível de ser de uma série
de formatos. Por exemplo, a comunicação de clientes é susceptível de
conter um pedido de desculpas e uma visão geral de alto nível do que
está sendo feito para resolver a exceção. A comunicação com as
pessoas que são esperadas para resolver a exceção será mais detalhada
e conter ações e prazos
• A confirmação de que a exceção foi resolvido ·
Contexto / • Grave incidente para Incidente graves

fontes • Eventos
• Crise ou de emergência reuniões convocadas pelo Gerente de
Incidentes, o gerente designado, ou as Serviços de TI Gerente de
continuidade
Comunicação Tabela B.10 durante emergências

B8 A comunicação com os usuários e clientes
Esta seção aparece por último, não porque é o menos importante, mas porque
incorpora várias das áreas acima referidas. Um princípio importante na
comunicação com os clientes é que a comunicação não deve incidir sobre
aspectos internos da Operação de Serviço. O foco está no cliente ou usuários '
exigências E o que ele está fazendo para atendê-los. Isso não deve envolver
descrições técnicas e informações detalhadas sobre os processos internos.
Propósito Há uma série de razões para o usuário e comunicação com o cliente na operação
de serviço. Estes incluem:
• Assegurar que os serviços foram entregues conforme acordado

• Comunicação em torno de cumprir Solicitação de Serviços
• Relatórios de incidentes e manter os usuários e clientes atualizado em
seu estatuto até resolvido
• Notificadoras usuários e clientes das mudanças que poderão afetá-los
• Proporcionar acesso a serviços
• Lidar com potencial segurança questões
• Programação de atividades que envolvem usuários ou clientes, por
exemplo, manutenção
• Notificação de negócios especiais eventos que necessitam de apoio
adicional ou prioridades mudaram
• Comente do cliente e usuário satisfação
• Coordenação em situações de contingência
Freqüência A comunicação com os usuários e clientes está em curso. O formato eo conteúdo

de comunicação será definida pelos processos que estão sendo executados. Por
exemplo, a comunicação de um incidente será determinada pela Gerenciamento
de Incidentes processo.
Alguma comunicação será formal e programada, por exemplo, fornecendo

relatórios sobre o atuação de um serviço durante um rever reunião. Outra
comunicação será formal, mas ad hoc, por exemplo, comunicação sobre o estado
de um Incidente
Papel O identidade dos atores e seu número vai depender de qual processo está sendo
Jogadores executado, o tipo de situação que ocorreu e escopo do que está sendo
comunicada, por exemplo, fornecer uma atualização sobre o estado de um
Solicitação de Serviço terá um público muito diferente do que quando participar
de um Nível de Serviço Reunião de avaliação
Conteúdo O conteúdo da presente comunicação irá variar, dependendo do contexto. No

entanto, é importante que o equipamento de comunicação para o público. Isso
significa usar serviço em vez de nomes servidor ou aplicação nomes, ser
profissional, não evitando o jargão técnico, sendo condescendente e tratar os
clientes e usuários com respeito
Contexto / O contexto desta comunicação é o dia-a-dia de execução de operacional

fontes atividades ea entrega e suporte de serviços. Operação de Serviço equipes não

devem se comunicar com clientes ou usuários em planejamento questões,
estratégia,projeto ou teste - a menos que tenham sido atribuído a uma projeto
equipe que está lidando com uma dessas áreas
Comunicação Tabela B.11 com usuários e clientes

Anexo C: Kepner Tregoe e
Charles Kepner e Benjamin Tregoe desenvolveu um método útil para analisar
problemas. Neste apêndice, seu método é apresentado como um exemplo de
um método de análise do problema.
Kepner e Tregoe estado que Análise de Problemas deve ser um processo

sistemático de resolução de problemas e deve tirar proveito máximo de
conhecimento e experiência. Eles distinguem os seguintes cinco fases para
Análise de Problemas (descrito mais abaixo):
• Definindo o problema
• Descrevendo o problema com respeito à identidade, localização, tempo e
tamanho
• Determinar eventuais causas
• Testando a causa mais provável
• Verificar a verdadeira causa.
Dependendo do tempo e as informações disponíveis, estas fases podem ser

realizadas a uma maior ou menor extensão. Mesmo em situações em que
apenas uma quantidade limitada de informação está disponível, ou a pressão do
tempo é alta, vale a pena adotar uma abordagem estruturada para a Análise de
Problemas de melhorar as chances de sucesso

C1 Definindo o problema
Porque a investigação é baseada na definição do problema, Esta definição, tem

de indicar com precisão quais desvio (s) a partir do acordado nível de serviços
ter ocorrido.
Muitas vezes, durante a definição de um problema, a causa mais provável é

problema já indicado. Tome cuidado para não tirar conclusões precipitadas, que
podem orientar a investigação no sentido errado desde o início.
Na prática, a definição do problema é muitas vezes uma tarefa difícil por causa
de uma complicada Infraestrutura de TI e não transparente acordos sobre os
níveis de serviço
C2 Descrevendo o problema
Os seguintes aspectos são usados para descrever o problema, ou seja, qual é o

problema:
• Identidade. Qual parte não função bem? Qual é o problema?

• Localização. Onde o problema ocorre?
• Tempo. Quando o problema começa a ocorrer? Como freqüentemente
tem o problema ocorreu?
• Tamanho. O que é o tamanho do problema? Quantas peças são
afetados?
O "é" situação é determinado pelas respostas a estas perguntas. O passo

seguinte é o de investigar quais partes semelhantes de uma maneira similar
ambiente estão funcionando corretamente. Com isso, uma resposta é formulado
para a pergunta "O que poderia ser, mas não é?" (Que partes poderia mostrar o
mesmo problema, mas não?).
Em seguida, é possível pesquisar eficazmente às diferenças relevantes em

ambas as situações. Além disso, as mudanças anteriores, que podem ser a
causa dessas diferenças, podem ser identificados
C3 Estabelecer as possíveis causas
A lista de diferenças e alterações mencionadas acima provavelmente segurar a

causa do problema, de modo causas possíveis pode ser extraído a partir desta
lista.

C4 Testando a causa mais provável
Cada possível causa precisa de ser avaliada para determinar se poderia ser a
causa de todos os sintomas do problema.
C5 Verificando a verdadeira causa
As causas possíveis restantes tem que ser verificada como sendo a fonte de
problema. Isso só pode ser feito por provar isso de uma maneira ou de outra -
por exemplo, a implementação de um mudar ou substituir uma peça. Abordar as
possíveis causas que podem ser verificadas de forma rápida e simples primeiro

Anexo D: Diagramas de Ishikawa
O Diagrama de Ishikawa, Também conhecido como o Diagrama Espinha de
Peixe, Causa e Efeito, ou árvore, é uma ferramenta utilizada para a identificação
sistemática e apresentar todas as possíveis causas de um problema particular
em um gráfico. A técnica tem o nome de seu criador, Kaoru Ishikawa (1915-
1989), líder em qualidade japonesa controlar. Um exemplo é mostrado abaixo.
O objetivo principal é representada pela coluna ou tronco do diagrama e os

fatores principais são representados como ramos. Factores secundários são
então adicionados como hastes, e assim por diante. Criando o diagrama
estimula a discussão e muitas vezes leva a uma maior compreensão de um
problema complexo. Esses diagramas são amplamente utilizados na
identificação de soluções para os problemas sistêmicos, como identificar a
causa da perda de produtividade em linhas de montagem, ou inferior cliente os
níveis de satisfação em um serviço organização.
A técnica básica de desenvolver estes diagramas, juntamente com um exemplo

muito simples, é mostrada aqui. Uma equipa de resolução de problemas irá
utilizar o diagrama de Ishikawa como se segue:
• 1 -. Prepare um diagrama em branco em um formato que pode ser visto

por todo o grupo. Este poderia ser um flipchart, placa, projetoed através
de um projetor de dados a partir de um PC, etc
• 2 -. Definir o problema que o grupo está tentando resolver em termos
claros e específicos e escrever na caixa na caixa "cabeça de peixe" do
diagrama.
• 3 -. Escreva as categorias em causa as dicas dos "ossos de peixes. Estes
devem ser categorias bem amplas como as causas exatas ainda não são
conhecidos. Um exemplo é mostrado na Figura D.1 no qual o grupo está
a tentar encontrar a causa para níveis inaceitáveis de rede tempo de
inatividade.

Figura D.1 Amostra de iniciar um Diagrama de Ishikawa
• 4.-Use de brainstorming técnicas para levar os participantes a sugerir

possíveis causas, e observe-os no ramo relevante do diagrama. Um
diagrama simples foi concluída na Figura D.2.
Figura D.2 Exemplo de um Diagrama de Ishikawa concluída
• 5 -. Interpretar o diagrama. Isto poderia ser feito através da classificação

das causas principais com base nos dados disponíveis e experiência.
Uma vez que as principais causas foram selecionados, cada um vai ser
investigado de acordo com a sua classificação e prioridade

Apêndice E: Descrição detalhada de Gestão de
Instalações
O objetivo deste apêndice não é fornecer uma explicação detalhada de todos os
aspectos Gestão de Instalações. Pelo contrário, vai destacar as atividades mais
importantes para auxiliar no posicionamento alguns dos outros funçãos e na
identificação de onde o impacto específico sobre os processos de Gestão de
Instalações bom e vice-versa.
Facilities Management vai fornecer informações para Gerenciamento da

Configuração sobre a localização e estado de IC, e também será uma parte
integrante do Gestão da Mudança, Capacidade e Disponibilidade e
Planejamento Gestão da Continuidade do Serviço.
O principal componentes de Gestão de Instalações são os seguintes

E1 Gestão de Edifícios
Embora as atividades de gestão de muitos edifícios são terceirizados ou
contratados a outros fornecedors, eles ainda são da responsabilidade de gestão
de instalações. As atividades típicas incluem:
• Limpeza. Isso poderia ser feito por funcionários ou por terceiros. É muito
importante aqui para garantir que o pessoal de limpeza cumprir com todo
o acesso controlar e confidencialidade políticas.
• Eliminação de resíduos, Incluindo a separação de itens para reciclagem,
itens perigosos (pilhas, por exemplo, líquidos e gases, como refrigerante
para unidades de ar condicionado), documentação confidencial.
• Instalação de instalações físicas, Como energia, cabos, pisos elevados,
entrada e sistemas seguros de saída, escritórios, móveis, etc
• Estacionamento. Isto deve incluir a afectação de pessoal e
estacionamento contratante, estacionamento de visitantes e
estacionamento para funcionários deficientes ou visitantes. Gestão de
instalações também incluem documentação e fazer cumprir as políticas
em torno de quem deve estacionar onde.
• Controle de acesso e monitoramento de segurança. Isso é abordado
com mais detalhes na seção E6 abaixo e também no Apêndice F.
• Signage, Ou seja, garantir que o edifício pode ser encontrado, mas
obviamente não é um local chave digno de ataque.

E2 Equipamentos de Hospedagem
As instalações não são geridos simplesmente porque eles existem e são de
propriedade de um organização. Elas são gerenciadas de modo que as pessoas
e equipamentos que contêm podem ser utilizados para fins específicos. No caso
de instalações de TI, tais como centros de dados, este adiciona algumas
exigências muito específicas para o gerente daquela instalação.
Um destes é o equipamento de hospedagem de TI. Isto não é apenas um caso

de fornecimento de um quarto e permitindo que o Gestão Técnica equipes para
instalar e gerenciar equipamentos. Diferentes tipos de equipamentos têm muito
específico exigências da instalação em que se encontra, por exemplo:
• Refrigerado a água equipamento precisa de acesso a água fria - que tem

de ser fornecido pela unidade
• O peso do equipamento varia e tem de ser distribuído de modo a não
colocar demasiado stress no chão
• Alimentação eléctrica pode variar para diferentes tipos de equipamentos.
Se o equipamento é simplesmente colocado no centro de dados, na ordem em

que é recebido, que vai ser muito difícil encontrar qualquer coisa e de pessoal
pode ter que atravessar o andar várias vezes para tendem a equipamento
similar. Este tráfego compromete a integridade e segurança de outro
equipamento no chão.
Isto significa que, Gestão de Instalações tem de possuir a responsabilidade de

planejamento e projetar o layout do Centro de Dados para o acesso e segurança
ideais do equipamento que será hospedado lá. Ao mesmo tempo, deve ser
lembrado que este equipamento está a ser utilizado para entregar De serviços
de TIs, e os requisitos para que serviço devem ser tomadas em consideração no
que hospeda o equipamento. Por exemplo, Data Center padrãos podem ter de
ser alterado, a fim de acomodar um não-padrão servidor.
Além disso, a maioria dos centros de dados também oferecem as seguintes

atividades de hospedagem:
• Recebimento de novos equipamentos

• Desembalar, configurar e instalar equipamentos de série
• Produção e manutenção de dados diagramas de layout Centro
• Gerenciando o programa de qualquer manutenção atividade ao
equipamento hospedado no Centro de Dados
• Eliminação de aposentarEquipamento d.
A partir desta lista de actividades, é evidente que Facilities Management não

deve ser visto como um separado função, Mas uma grande parte do total
operação de TI no organização.

Gerenciamento de energia E3
Gerenciamento de energia refere-se a gerir o fornecimento e utilização de fontes
de energia que são usados para manter a unidade funcional. Esta definição de
gerenciamento de energia tem uma série de implicações, que são discutidas
abaixo.
Instalações primeira tarefa da administração no poder de gestão é para

determinar os requisitos de energia para a instalação. Isso inclui a definição:
• O que a energia vai ser necessária para - e.g. espaço de escritório,

equipamentos no Centro de Dados, o refeitório, etc
• Quando essa energia vai ser necessário. Algumas operações requerem
um fornecimento constante de energia elétrica 24 horas por dia. Outros,
como o espaço de escritório, vai usar mais energia durante o dia e muito
pouco à noite. Outros só precisam de eletricidade em um momento
específico
• Quanta energia vai ser necessário
• Qual o tipo de alimentação irá ser utilizado. Embora a maioria das
organizações utiliza eletricidade, em muitos locais os sistemas de
aquecimento são dependentes do gás natural.
Facilities Management também será responsável por estabelecer um contrato

com utilidade empresas, ou em muitos casos, a autoridade local ou município
que fornece esse serviço. Isto incluirá uma taxa combinada e um nível de
disponibilidade. Isto tornou-se muito importante em locais onde o abastecimento
de electricidade é variável, devido à falta de infra-estrutura ou devido a sobre-
utilização pelos consumidores gerais.
Gestão de Instalações será responsável por estabelecer espera fontes de

energia para poder falhas, catástrofes e outras contingências. Este é geralmente
na forma de Uninterruptible Power Supplies (UPS) para equipamentos-chave, e
também geradores alimentados por uma fonte de energia alternativa
(geralmente óleo diesel). Facilities Management é responsável não só pelo
fornecimento dessas alternativas, mas também para testá-los, mantendo o
fornecimento de combustível e manutenção.
É necessário dizer que qualquer fonte de energia alternativa deve ser modelada
e testados para assegurar que é capaz de lidar com a demanda necessária e
também que é automaticamente activado depois de uma falha de energia.
Outra chave atividade de Facilities Management é a gestão da utilização de

energia. Tradicionalmente, o papel de Gerenciamento de Facilidades foi apenas
para garantir que a energia estava disponível. No entanto, como natural recursos
se tornam mais escassos e caros, mais atenção está sendo focada em técnicas
para gerir a utilização mais responsável.

Uma dessas abordagens é a gestão dinâmica de poder em Centros de Dados. O
princípio é que durante os períodos de pico de processamento, mais
computadores serão utilizados para fazer o trabalho. À medida que o carga de
trabalho reduz, o trabalho é centralizado em computadores menos, enquanto
que aqueles que não estão sendo utilizados são desligado ou colocado em
modo de espera. Isso exige uma integração significativa entre as atividades de
TI Gestão de Operações, Gestão Técnica e todos os Design de Serviços
processos. Isso é discutido com mais detalhes na seção sobre as estratégias de
Centro de Dados.

E4 condicionamento ambiental e sistemas de alerta
Facilities Management garante que as condições físicas dentro dos Centros de
Dados ou salas de informática são mantidos nos níveis corretos para melhor
Operações de TI. Essas condições incluem:
• Temperatura
• Umidade
• Ar qualidade
• Liberdade de meio ambiente riscos, tais como incêndios, inundações, etc
A temperatura é mantida por meio de aquecimento e arrefecimento, bem como a

disposição do equipamento em instalações. Isso exigirá as seguintes atividades:
• Determinar a produção de calor para CIs e sua temperatura operacional

ideal.
• Identificando o arrefecimento total exigência para todo o equipamento na
instalação, bem como para itens específicos. Por exemplo, um aparelho
de ar condicionado pode ser capaz de manter um centro de dados, a uma
temperatura constante, mas pode haver equipamento que tem de ser
mantido a uma temperatura mais baixa.
• Modelagem o aquecimento global e refrigeração, bem como o
mapeamento de áreas específicas na instalação que podem ser
naturalmente mais quente ou mais frio. Esta informação é usada para
identificar a melhor localização onde é para o equipamento específico. É
importante notar que quando o equipamento novo é instalado em uma
instalação, ele vai mudar o mapeamento das áreas mais frias e mais
quentes na instalação, daí a necessidade de mapeamento mais
sofisticados e técnicas de modelagem. Estes modelos também terá de
levar em conta as variações sazonais de temperatura. Por exemplo,
algumas instalações podem ter de ser aquecida no Inverno e no verão
arrefecido.
• Compra e manutenção de aparelhos de ar condicionado com suficiente
capacidade, E manutenção destas unidades regularmente.
• Investir em apoio unidades de ar condicionado que pode ser usado se
uma unidade principal falhar, ou para fornecer capacidade de
resfriamento extra em excepcionalmente dias quentes (embora esta deve
ser uma rara exceção - se a unidade de backup é utilizado com muita
freqüência, isso implica que inicial planejamento era inadequada).
• Contínuo monitoramento da temperatura e ajuste das definições de
arrefecimento de acordo com mudanças na temporada e disposição do
equipamento. Estes monitores podem ser ligados ao Operações Ponte, O
que seria capaz de responder a qualquer desvio significativo da
temperatura normal.
• Identificar e evitar "óbvio" erros, tais como a localização da saída de calor
de um grande servidor perto da entrada de uma unidade de ar

condicionado, ou impedindo o fluxo de ar pelo empilhamento de manuais
no espaço "livre".
Medidas semelhantes devem ser tomadas para identificar os níveis de umidade

ideais e especificar se o equipamento de desumidificação é necessária.
Equipamentos de detecção de fumaça geralmente é instalado como parte do

controle de fogo global estratégia da unidade e está ligada à automatizados de
combate a incêndios. No entanto, Gestão de Instalações não deve presumir que
uma resposta automática para disparar ameaças será adequada. Unidades de
detecção de fumo deverá ser ligada ao Operações Ponte e qualquer exceção
deve ser investigada.
Unidades de detecção de movimento deve ser instalado em todas as áreas de

operação autônoma. Estes irão garantir que o acesso não autorizado é
detectado e reportado à Segurança Instalações e possivelmente também o
Operações Ponte. Isso vai ajudar a cumprir boa programação de atividades de
manutenção ou instalação.
Detecção poeira e partículas pode auxiliar na manutenção do ar qualidade em

torno de sistemas que são particularmente sensíveis. Mais uma vez, os
monitores devem ser encaminhados para o Operações Ponte de modo que os
desvios podem ser investigados e corrigidos antes de qualquer dano significativo
ocorre.
Há também um número de outros tipos de equipamento de monitorização, o qual

está baseado no local da instalação. Por exemplo, monitores de movimento de
construção instaladas em locais com altos níveis de sísmica atividade. Estes
agem como sistemas de alerta precoce para indicar que um sistema precisa ser
desligado ou falha para um local alternativo antes de um tremor de terra
significativo ou terremoto afeta equipamentos sensíveis. Monitores e
salvaguardas semelhantes também estão sendo instalados em locais onde há
atividade de tempestade elétrica de alta.
Estes sistemas são referidos coletivamente como a construção de Sistemas de

Gestão (BMSs), embora, como essas ferramentas são integradas, o termo é
usado para se referir a um único integrado sistema de gestão, Em vez de um
conjunto disperso de ferramentas de desempenho semelhante funçãos. O
pensamento deve ser dada ao uso de ferramentas de monitoramento que se
integram, ou pelo menos de acordo com, ferramentas de monitoramento
existentes. (Consulte o Capítulo 7 para obter mais detalhes sobre as
ferramentas.)

E5 Segurança
Uma grande preocupação de Facilities Management é a segurança das pessoas
que trabalham no edifício. Facilities Management é, portanto, responsável pela
compreensão e aplicação observância com segurança relevantes padrãos e
legislação.
Segurança é reforçada nas seguintes áreas:
• Edifício projeto e construção

• Disposição das salas e equipamentos na instalação
• Educação de todos os funcionários sobre a segurança padrãos em vigor
na facilidade
• Definição de evacuação procedimentos e rotas e pontos de coleta no
evento de um incêndio ou risco de vida outra
• Avisos e informações a respeito de qualquer informação de segurança de
que o pessoal precisa estar ciente.
E6 Controle de Acesso Físico

Esta é uma parte muito importante de Gestão de Instalações e cresceu em um
campo especializado. Como tal, o conteúdo é aqui resumido por conveniência,
mas discutidos em detalhe no Apêndice F.
O major componentes de Controle de Acesso Físico (como discutido no

Apêndice F) são:
• Assistência na definição e manutenção de Acesso Físico Controla como

parte do organização'Segurança Políticas s
• Manutenção de chão planos indica que as áreas são restritas
• Instalação e manutenção de acesso físico controlar dispositivos de
monitoramento e controle de acesso às instalações
• Pessoal de segurança
• Instalação e manutenção de equipamentos de vigilância
• Proteção contra engenharia social
E7 envio e recebimento
Grandes instalações requerem áreas especiais onde a entrega podem ser
tomadas de móveis e equipamentos, computador, racks, etc Esta área precisa
ser protegido para que o pessoal de entrega não ter acesso ao restante das
instalações. Há também precisa de ser um depósito seguro perto da área de

recepção onde os artigos podem ser armazenados até que possam ser movidos
para a sua posição final.
Aprocesso precisa estar no local para garantir que os itens a serem enviados
são contabilizados e que somente os itens são removidos pela entrega ou envio
contratante. Sempre que possível, esses itens devem ser ordenados para o
armazenamento seguro no transporte e área de entrega antes de ser
despachado. Isto irá prevenir o acesso não autorizado à facilidade.
Entrega e envio de documentação tem de ser concluído, inspecionado e

assinado para cada remessa que é entregue ou enviado. Um registo central de
todas as remessas também deve ser mantida como controle.
E8 Envolvimento em Gestão de Contratos

A maioria das instalações são fornecidos, gerenciado e atendido por uma série
de entidades. Embora o actual contratos com essas entidades seriam
normalmente ser gerido pelos departamentos comerciais adequados e legais,
Facilities Management vai jogar uma chave papel na especificação e negociação
desses contratos. Contratos típicos incluem:
• Gestão dos contratos de arrendamento de propriedades alugadas.

Isso é muito raro, pois a maioria das organizações de ver o seu Centro de
Dados como uma chave ativos. Leasing tais instalações seria visto como
um risco por causa do potencial que o prédio seja vendido, o locador sai
do negócio ou o locador não cumprir o contrato em termos de
manutenção adequada.
• Leasing ou manutenção de equipamento ambiental, Tais como
aparelhos de ar condicionado, ambientais monitoramento e alertar (Por
exemplo, detecção de fumaça e combate a incêndios ou de supressão).
• Construção de contratos de manutenção. Estes incluem a manutenção
de elevadores, piso, encanamento e rede elétrica.
• Instalações de telecomunicações. Apesar de telecomunicações
normalmente é gerenciado por uma equipe dedicada ou departamento ou
como parte de rede geográfica, são muitas vezes dependente de terceiros
para fornecimento e manutenção de equipamentos de telecomunicações
localizados dentro ou fora do Centro de Dados. Em muitos países, estes
são fornecidos pelo governo ou por organizações para-estatais de
telecomunicações. Gestão destes tipos de contratos requer um conjunto
de habilidades especiais.
• Serviços de segurança para o fornecimento de acesso físico controlar e
serviços de resposta armados.
Uma parte muito importante da gestão de contratos é assegurar que todos os

terceiros equipe está ciente, e cumprir, o políticas de segurança do
organização. Isso inclui controle de acesso físico, confidencialidade e uso não

autorizado de instalações da organização ou equipamentos. Regular auditars
devem ser realizadas para garantir que este está sendo imposta.
Manutenção E9
Gestão de Instalações é responsável pela coordenação de toda a manutenção
de rotina atividade no interior do edifício. Isto refere-se tanto a manutenção do
edifício, assim como para a manutenção do equipamento, no Centro de Dados.
A razão para incluir a manutenção de equipamentos é simplesmente para evitar

que o edifício seja exposto a demasiada actividade invulgar em qualquer
momento. Múltiplos grupos de trabalho em locais diferentes no centro de dados,
ao mesmo tempo representa um segurança e risco de segurança.
É importante notar que a manutenção de equipamento real é levada a cabo pelo

pessoal de Gestão Técnica, mas sob a coordenação de Gestão da Mudança e
Gestão de Serviços.
O Gerente de Instalações deve manter um plano-mestre de todas as atividades

de manutenção planejada para que a actividade de manutenção seja bem
coordenada. Este calendário faz parte do conjunto Gestão da Mudança Alterar
agendamento e é usado para garantir que não existem conflitos entre a
actividade e a manutenção de rotina do desenvolvimento de mudanças.

Anexo F: Controle de Acesso Físico
Seção 5.12 e Apêndice E introduziu a área de Controle de Acesso Físico como
parte da gestão de instalações. Esta seção apresenta uma discussão mais
detalhada da área.
Gestão de Segurança da Informação é responsável por definir e documentar

todas as políticas de controle de acesso. Estas políticas vai identificar todas as
medidas de segurança física que precisam ser tomadas e quais os grupos de
funcionários devem ter acesso a que tipo de instalação. Facilities Management
irá garantir que essas políticas são aplicadas adequadamente. Políticas devem
incluir:
• Que áreas são restritas e para quem

• O controle de acesso será colocado no lugar
• Sob que circunstâncias o acesso será permitido específicas áreas
restritas. Por exemplo, impeça o acesso a um piso Centro de Dados a
menos que um número autorizado RFC é digitada em um teclado
• Como o acesso controlar será monitorado
• Uma declaração de políticas de privacidade e as informações que tem
que ser conhecido, a fim de permitir o acesso
• As políticas relativas à vigilância de pessoal, por exemplo, o que pode ser
gravada, onde e se existem exceções.
A maioria das organizações utiliza vários níveis de controle de acesso,

começando com o acesso à propriedade, passando depois para o acesso a
áreas específicas no prédio e, em seguida, para o específico funçãos,
equipamento ou quartos. Cada nível de segurança é aplicada usando diferentes
mecanismos e pessoal, dando assim uma segurança adicional.
Todas as instalações devem ter um documentada, piso plano atual, que indica
exatamente quais áreas são restritas e que não são. Este plano também indicam
que as medidas de segurança são implementados e onde. Isto ajudará na
segurança auditars e também para a manutenção do equipamento de controlo
de acesso.
Dispositivos de controle de acesso precisam ser instalados em todas as

entradas e saídas. O objectivo destes dispositivos é a de assegurar que apenas
o pessoal autorizado tenha acesso à área restrita. Embora este parece à
primeira vista ser um assunto bastante simples, há uma série de itens que
precisam ser levados em conta (ver Tabela F.1).
O controle Exemplo Vantagens Desvantagens

de acesso
Mecânico Fechadura e chave Estável e de confiança Requer chave controlar

Barato Bloqueios têm de ser
substituídos cada vez
que alguém sai da
organização
Pode facilmente ser
comprometida por
qualquer pessoa com
conhecimento de
algumas técnicas
simples
Código de Mecânica (por exemplo, um Estável Alguém observação

acesso dispositivo de botão de Relativamente barato pessoal que utiliza o
pressão montado na porta) dispositivo pode
Eletrônica (por exemplo, facilmente obter o
um teclado utilizado para código
armar ou desarmar uma Código deve ser trocado
segurança alarme) a cada vez que alguém
deixa a empresa
As pessoas tendem a
escrever o código
abaixo · ·
O acesso Cartões-chave Fácil de usar Relativamente caros,

electrónico Pode ser usado para embora os custos
controlar o acesso de diminuíram, e muitas
pessoal da vezes mais barato do
Pode ser cancelada ou que usar humana
alterada central para recursos fisicamente
atender mudou para guardar cada ponto
exigências de acesso
Pode ser cancelada, Dependente de energia
mesmo quando a equipe disponibilidade
não retornar seu cartão Pode ser comprometida
por pessoas que
utilizam equipamentos
de cópia especializada
Biométrica Scanner de retina ou de Mecanismo muito fiável Dependentes da

análise de voz para identificar disponibilidade de
indivíduos específicos energia
Difícil de falsificar acesso Requer acesso à mais
Mais eficaz na luta sofisticada controlar
contra a engenharia sistemas
social · Relativamente caro
Acesso Porta com um cartão- Fácil de se deslocar de Difícil de controlar

múltiplo chave. Uma pessoa abre a um lugar para outro, "Tailgating '
porta e permite o acesso a especialmente onde os Dependente do
qualquer número de grupos estão segurança consciência
pessoas que os trabalhando juntos do pessoal autorizado
acompanham Extremamente
vulneráveis a
engenharia social
Não deve ser usado em
áreas altamente

seguras
Acesso Catraca permite apenas Mais fácil de controlar o Pode se tornar um

único uma pessoa para entrar. O acesso gargalo no horário de
mesmo cartão chave não Evita que a engenharia pico
pode ser utilizado para social mais eficaz Requer vigilância mais
introduzir uma segunda intensiva e de pessoal
pessoa
Uni- Porta giratória permitindo o Bom para situações em Requer mais

direcional acesso apenas ou apenas que não há necessidade monitoramento para
acesso de saída. Normalmente de monitorar o que as garantir que as pessoas
usado em aeroportos, onde pessoas levam para fora, não tentem passar a
o pessoal de segurança só mas onde as coisas que direção errada
estão preocupados com as eles tomam em poderiam Normalmente uni-
pessoas que entram no causar danos direcional; também
aeroporto, mas não sobre significativos implica equipamento de
aqueles sair varredura adicional e
vigilância
Bi- Acesso controlado porta Bom para o acesso geral Pessoas saindo pode
direcional a áreas restritas · fornecer acesso a
acesso pessoas não
autorizadas se movendo
em
Poderia ser um gargalo
(por exemplo, bi-
direcionais catracas
pessoas que vão para
fora tem que esperar
para as pessoas que
entram)
Ativo Requer uma acção pessoal Mais fácil de controlar o Requer pessoal se
para ter acesso, por acesso lembrar de um código
exemplo, , passar um Mais seguro · ou de levar um cartão-
cartão ou um código de chave
perfuração
Passiva Detector passivo Fornece mais segura de Fácil para pessoas não
desbloqueia uma saída de saída no caso de um autorizadas a ter acesso
dentro, sempre que alguém incêndio simplesmente
se aproxima Não requer cartões- esperando do lado de
chave para as pessoas fora
de se mudar para áreas Pode ser desencadeada
não seguras · a partir do exterior
através da inserção de
uma coisa debaixo da
porta e movendo-o
dentro do alcance do
sensor
Tabela F.1 dispositivos de controle de acesso

Como o acesso mais físico controlar mecanismos não são à prova de falhas,
que é importante para assegurar que o acesso pode ser monitorizada e
controlada. Isto é feito através especializado segurança pessoal e por
equipamentos de vigilância eletrônica.
Como a segurança é tudo sobre como gerenciar o acesso das pessoas a uma
instalação, é conveniente que as pessoas são usadas para impor medidas de
segurança. As organizações maiores, por vezes, fornecer sua equipe de
segurança própria, mas a maioria tende a terceirizar controle de acesso físico a
empresas especializadas. Este é geralmente pelos seguintes motivos:
• Guardas de segurança exigem formação especializada e são geralmente

sujeitos a um código (quase militar) disciplinar diferente da maioria dos
funcionários da empresa. Isso é muitas vezes em conflito com o tipo mais
comercial do código disciplinar e é melhor gerido por um conjunto
diferente de gestores com uma gestão diferente cultura.
• Empresas externas são menos propensos a ser influenciado por
situações de engenharia social, como eles têm treinamento especializado
e é improvável que entender algumas nuances internas da organização
que poderiam ser usados por um engenheiro social experiente.
Equipamentos de vigilância é usado para estender o eficácia de ambos os

mecanismos de controle de acesso físico e do pessoal de segurança. É
importante notar que nenhum equipamento de vigilância pode substituir a
presença de uma guarda de segurança formados, conscientes, meramente
aumentar a sua eficácia. Exemplos de equipamento de vigilância comumente
usados incluem:
• Câmeras de vídeo para monitorar pontos de acesso principais e também

em pontos de acesso menos utilizados, permitindo assim que um guarda
de segurança para monitorar vários locais ao mesmo tempo. Estes são
normalmente gravadas e os vídeos armazenados durante algum tempo
antes de serem utilizados novamente. Isto é para assegurar que se
qualquer erro é descoberto, as fitas podem ser utilizados na investigação.
Isto significa que o qualidade das imagens deve ser bom o suficiente para
facilitar a identificação de pessoas, mas ele também tem que estar em um
formato que torna fácil para armazenar grandes quantidades de dados
visuais.
• Acessar logs de eventos. Estes normalmente registrar cada entrada e
saída de pessoal por meio de mecanismos de acesso eletrônico.
• Unidades de detecção passiva para detectar a presença de pessoas em
uma área que não deverá ser composto.
• Alarmes que irá notificar o pessoal de segurança de acesso não
autorizado ou de saída, muitas vezes ligada a um alarme sonoro.

Não importa o quão seguro o ambiente, É dependente da percepção de
segurança dos funcionários e contratados que trabalham na instalação. A
engenharia social é ainda uma das violações mais comuns de segurança física.
Engenharia social se refere à prática de ganhar entrada para uma instalação
usando habilidades interpessoais e de comunicação para convencer alguém a
permitir o acesso não autorizado a um edifício, área restrita, o equipamento
restrito e dados, ou aos armários que contêm confidencial documentos.
Exemplos de engenharia social incluem:
• Posando como um empreiteiro legítimo ou funcionário da organização. A

técnica mais usual é aproximar o pessoal de segurança e do estado que
eles se esqueceram de seu cartão de acesso. Um log de acesso é
assinado e um cartão de visitante produzido. Muitas vezes não há a
verificação real de saber se a pessoa é um legítimo empregado,
especialmente em áreas de recepção ocupadas.
• Posando como alguém que tem uma razão para ter acesso não
autorizado à facilidade, por exemplo, um trabalhador de serviços públicos
ou de inspetor de incêndio.
• Um povo ex-empregado ou contratante que se aproximam com quem
estão familiarizados para permitir-lhes o acesso.
• "A utilização não autorizada", onde uma pessoa simplesmente segue um
empregado autorizado, por meio de uma entrada que eles abriram.
A engenharia social é melhor combatida através da aplicação estrita observância

com acesso controlar procedimentos, educação continuada programas, briefings
regulares de segurança pessoal e rigorosos auditars.
Um número crescente de empresas oferecem serviços para testar o rigor de

controle de acesso com pessoas que se especializam no uso de técnicas de
engenharia social.

Glossário
Lista de siglas
ACD Distribuição Automática de Chamadas
AM Gerenciamento de Disponibilidade
AMIS Disponibilidade do Sistema de Informação de Gestão
ASP Application Service Provider
BCM Gerenciamento da Capacidade de negócios
BCM Gestão de Continuidade de Negócios
BCP Plano de Continuidade de Negócios
BIA Análise de Impacto no Negócio
BRM Gerente de Relacionamento de Negócios
BSI British Standards Institution
BSM Business Service Management
CAB Alterar Conselho Consultivo
CAB / CE Alterar Conselho Consultivo / Comitê de Emergência
CAPEX Despesas de Capital
CCM Gerenciamento da Capacidade componente
CFIA Componente Análise de Impacto falha
CI Item de Configuração
CMDB Configuration Management Database
CMIS Capacidade do Sistema de Informação de Gestão
CMM Capability Maturity Model
CMMI Capability Maturity Model Integration
CMS Sistema de Gerenciamento da Configuração
COTS Comercial da Prateleira
CSF Fator Crítico de Sucesso
CSI Melhoria de Serviço Continuada
CSIP Plano de Melhoria de Serviço Continuada
CSP Pacote de serviços do núcleo

CTI Computer Telephony Integration
DIKW Dados para-Informação-para-Conhecimento-para-Sabedoria
ELS Life Support cedo
eSCM-CL eSourcing Capability modelo para organizações clientes
eSCM-SP eSourcing Modelo de Capacidade para prestadores de serviços
FMEA Modos de Falha e Análise de Efeitos
FTA Análise da Árvore de Falhas
IRR Taxa Interna de Retorno
ISG Grupo de Coordenação de TI
ISM Gestão de Segurança da Informação
ISMS Sistema de Gestão da Segurança
ISO Organização Internacional para Padronização
ISP Provedor de serviços de Internet
TI Tecnologia da Informação
ITSCM Gerenciamento da Continuidade do Serviço
ITSM IT Service Management
itSMF IT Service Management Forum
IVR Interactive Voice Response
BDEC Banco de Dados de erro conhecido
KPI Key Performance Indicator
LOS Linha de Serviço
M_o_R Gestão de Risco
MTBF Tempo médio entre falhas
TMEIS Tempo médio entre Incidentes de Serviço
MTRS Tempo médio para restaurar o serviço
MTTR Mean Time To Repair
VPL Valor Presente Líquido
OGC Office of Government Commerce
OLA Acordo de Nível Operacional
OPEX Despesas operacionais

OPSI Escritório de Informação do Sector Público
PBA Padrão de Atividade de Negócios
PIR Pós-Implementação comentário
PFS Pré-requisito para o sucesso
PSO Interrupção do serviço projetado
QA Garantia de Qualidade
SGQ Sistema de Gestão da Qualidade
RCA Análise de causa raiz
RFC Requisição de Mudança
ROI Retorno sobre Investimento
RPO Objetivo do ponto de recuperação
RTO Objetivo Tempo de recuperação
SoC Separação de preocupações
SAC Critérios de aceitação de serviços
SACM Ativos de Serviços e Gerenciamento de Configuração
SCD Fornecedor e banco de dados contrato
SCM Gerenciamento da Capacidade de serviço
SDP Pacote de Desenho de Serviço
SFA Análise de falha de serviço
SIP Plano de Melhoria de Serviço
SKMS Serviço do Sistema de Gestão do Conhecimento
SLA Acordo de Nível de Serviço
SLM Gerenciamento de Nível de Serviço
SLP Pacote de nível de serviço
SLR Exigência de Nível de Serviço
SMO Objetivo de manutenção do serviço
SOP Procedimentos Operacionais Padrão
SOR Declaração de requisitos
SPI Interface do provedor de serviços
SPM Gestão de Portfólio de Serviços

SPO Otimização de provisionamento de serviços
SPOF Ponto único de falha
TO Observation técnica
TOR Termos de referência
TCO Custo Total de Propriedade
TCU Custo Total de Utilização
TQM Gestão da Qualidade Total
UC Subjacente Contrato
UP Perfil do Usuário
VBF Função de Negócios Vital
VOI Valor do Investimento
WIP Work in Progress

Lista de definições
Os nomes incluídos na publicação parênteses após o nome de um termo de
identificar onde o leitor pode encontrar mais informações sobre esse termo. Isto
é porque o termo é usado principalmente por que a publicação ou porque
informações adicionais úteis sobre esse termo pode ser encontrado lá. Termos
sem um nome de publicação que lhes estão associados podem ser utilizados
geralmente por várias publicações, ou não pode ser definida em maior detalhe
do que pode ser encontrado no glossário, ou seja, nós apenas leitores apontam
para algures que podem esperar para expandir o seu conhecimento ou a ver um
contexto maior. Termos com nomes de publicação múltiplas são expandidas em
em várias publicações.
Quando a definição de um termo inclui outro termo, os termos relacionados são

destacadas em uma segunda cor. Isto é projetado para ajudar o leitor com a sua
compreensão, apontando-os a definições adicionais que são todos parte do
termo original que eles estavam interessados dentro A forma 'Ver também X, Y
prazo Term "é utilizada no fim de uma definição em que um termo importante
relacionado não é utilizado com o texto da própria definição.
Aceitação Acordo formal que um serviço de TI, Processo, Plano ou Deliverable

outro é completa, precisa, confiável e cumpre os seus requisitos
especificados. A aceitação é geralmente precedido por avaliação ou
teste e é muitas vezes necessária antes de prosseguir para a próxima
fase de um projeto ou processo. Ver também Critérios de aceitação de
serviços.
Contabilidade (Estratégia de Serviço) O Processo responsável por identificar os

custos reais de fornecimento de serviços de TI, comparando-os com
os custos orçados e gerenciamento de variância do Orçamento.
Atividade Um conjunto de ações destinadas a alcançar um determinado

resultado. Atividades são geralmente definidas como parte de
processos ou planos, e estão documentadas em procedimentos.
Tempo de serviço (Desenho de Serviço) Um sinônimo de horas de serviço, comumente

acordado utilizadas em cálculos formais de Disponibilidade. Veja também
Downtime.
Acordo Um documento que descreve um entendimento formal entre duas ou

mais partes. Um acordo não é juridicamente vinculativo, a menos que
ele faz parte de um contrato. Ver também Acordo de Nível de Serviço,
Acordo de Nível Operacional.
Alertar (Operação de Serviço) Um aviso de que um limite foi atingido, algo

mudou ou uma falha ocorreu. Alertas são muitas vezes criados e
gerenciados por ferramentas de gerenciamento do sistema e são
gerenciados pelo Processo de Gestão de Eventos.
Modelagem analítica (Estratégia de Serviço) (Desenho de Serviço) (Melhoria de Serviço

Continuada) Uma técnica que utiliza modelos matemáticos para prever
o comportamento de um Item de Configuração ou Serviço de TI.
Modelos analíticos são comumente usados em Gestão de Capacidade
e Gerenciamento da Disponibilidade. Veja também Modelagem.
Aplicação Software que fornece funções que são exigidas por um serviço de TI.
Cada aplicação pode ser parte de mais do que um serviço de TI. Um
aplicativo é executado em um ou mais servidores ou clientes. Veja
também Gerenciamento de Aplicativos, Application Portfolio.
Aplicação de Gestão (Desenho de Serviço) (Operação de Serviço) A Função responsável

de por gerenciar aplicativos durante todo seu ciclo de vida.
Application Portfolio (Desenho de Serviço) Um banco de dados de documentos ou

estruturado usado para gerenciar aplicativos em todo o seu ciclo de
vida. O portfólio de aplicativos contém atributos-chave de todas as
aplicações. O portfólio de aplicativos às vezes é implementada como
parte do portfólio de serviços, ou como parte do Sistema de Gestão de
Configuração.
Application Service (Desenho de Serviço) Um provedor de serviço externo que fornece

Provider serviços de TI utilizando aplicativos executados nas instalações do
prestador de serviços. Os usuários acessam os aplicativos por
conexões de rede para o provedor de serviço.
Aplicação de (Desenho de Serviço) A Atividade responsável por entender as

Dimensionamento necessidades de recursos necessários para suportar um aplicativo
novo, ou uma grande mudança para um aplicativo existente.
Dimensionamento aplicação ajuda a garantir que o Serviço de TI pode
cumprir as suas metas de serviço acordadas a nível de desempenho e
capacidade.
Arquitetura (Desenho de Serviço) A estrutura de um sistema ou serviço de TI,

incluindo as relações de componentes para o outro e para o meio
ambiente que estão dentro Arquitetura também inclui as normas e
diretrizes que orientam a concepção e evolução do sistema.
Avaliação Inspeção e análise para verificar se um padrão ou conjunto de

orientações está sendo seguido, que os registros são precisos, ou que
os objectivos de eficiência e eficácia estão sendo atendidas. Veja
também auditoria.
Ativos (Estratégia de Serviço) qualquer recurso ou capacidade. Activos de um

provedor de serviço, incluindo tudo o que poderia contribuir para a
prestação de um serviço. Os ativos podem ser um dos seguintes tipos:
Gestão, Organização, Conhecimento, Processo, Pessoas,
informações, aplicações, infra-estrutura e do capital financeiro.
Gestão de Ativos (Transição de Serviço) Asset Management é o processo responsável

por acompanhar e relatar o valor ea propriedade de ativos financeiros
em todo o seu ciclo de vida. Asset Management é parte de um activo
Serviço geral e processo de gestão de configuração.
Atributo (Transição de Serviço) Um pedaço de informações sobre um item de

configuração. Exemplos são: nome, localização, número da versão e
Custo. Atributos de ICs são registrados no Configuration Management

Database (CMDB). Veja também Relacionamento.
Auditar Inspeção formal e verificação para verificar se um padrão ou conjunto

de orientações está sendo seguido, que os registros são precisos, ou
que os objectivos de eficiência e eficácia estão sendo atendidas. Uma
auditoria pode ser efectuada por grupos internos ou externos. Veja
também avaliação, certificação.
Distribuição (Operação de Serviço) O uso da Tecnologia da Informação para

Automática de direcionar uma chamada telefónica para a pessoa mais adequada no
Chamadas menor tempo possível. ACD é às vezes chamado de distribuição
automática de chamadas.
Disponibilidade (Desenho de Serviço) Capacidade de um item de configuração ou

serviço de TI para executar sua função acordada quando necessário.
A disponibilidade é determinada pela Confiabilidade, Manutenção,
manutenção, desempenho e segurança. A disponibilidade é
normalmente calculada como uma percentagem. Este cálculo é muitas
vezes baseadas em tempo de serviço acordado e tempo de
inatividade. Ela é a melhor prática para calcular a disponibilidade
usando medições da saída de Negócios do Serviço de TI.
Gerenciamento de (Desenho de Serviço) O Processo responsável pela definição, análise,

Disponibilidade planejamento, medir e melhorar todos os aspectos da disponibilidade
dos serviços de TI. Gerenciamento de Disponibilidade é responsável
por garantir que todas as infra-estruturas de TI, Processos,
Ferramentas, Funções, etc são apropriados para as metas de serviço
acordado nível de disponibilidade.
Disponibilidade do (Desenho de Serviço) Um repositório virtual de todos os dados de

Sistema de gerenciamento de disponibilidade, normalmente armazenados em
Informação de Gestão vários locais físicos. Veja também Serviço de Sistema de Gestão do
Conhecimento.
Plano de (Desenho de Serviço) Um plano para garantir que os requisitos de

disponibilidade disponibilidade existentes e futuras por serviços de TI pode ser
fornecido de maneira rentável.
Voltar-out Veja Remediação.
Faça backup (Desenho de Serviço) (Operação de Serviço) Copiar dados para

proteger contra a perda de integridade ou disponibilidade do original.
Balanced Scorecard (Melhoria de Serviço Continuada) Uma ferramenta de gestão

desenvolvido pelos drs. Robert Kaplan (Harvard Negócio Escola) E
David Norton. O Balanced Scorecard permite uma estratégia a ser
dividido em indicadores de desempenho. Desempenho em relação ao
KPIs são usados para demonstrar o quão bem a estratégia está sendo
alcançado. O Balanced Scorecard tem quatro áreas principais, cada
um dos quais tem um pequeno número de KPIs. As mesmas quatro
áreas são consideradas em diferentes níveis de detalhe em toda a
Organização.
Linha de base (Melhoria de Serviço Continuada) Uma referência usada como um

ponto de referência. Por exemplo:

• Uma linha de base ITSM pode ser usada
como um ponto de partida para medir o efeito
de um Plano de Melhoria de Serviço
• Um parâmetro de desempenho pode ser
usado para medir as mudanças no
desempenho sobre o tempo de vida de um
serviço de TI
• A linha de base do Gerenciamento da
Configuração pode ser usado para permitir
que a infra-estrutura de TI para ser restaurado
para uma configuração de sabe se uma
Alterar ou lançamento falhar.
Referência (Melhoria de Serviço Continuada) O estado de algo gravado em um

ponto específico no tempo. A referência pode ser criado para uma
configuração, um processo, ou qualquer outro conjunto de dados. Por
exemplo, um valor de referência pode ser utilizada em:
• Melhoria de Serviço Continuada, para

estabelecer o estado atual para o
gerenciamento de melhorias
• Gerenciamento da Capacidade, para
documentar as características de desempenho
durante as operações normais.
Veja também Base de Benchmarking.
Aferição (Melhoria de Serviço Continuada) Comparando-se uma referência com

uma linha de base ou com a Melhor Prática. A avaliação do
desempenho termo também é utilizado para significar a criação de
uma série de parâmetros de referência ao longo do tempo, e
comparando os resultados para medir o progresso ou melhoria.
Melhores Práticas Atividades comprovadas ou processos que têm sido utilizados com
sucesso por várias organizações. ITIL é um exemplo de boas práticas.
Brainstorming (Desenho de Serviço) Uma técnica que ajuda uma equipe a gerar
idéias. As idéias não são revisados durante a sessão de brainstorming,
mas numa fase posterior. Brainstorming é muitas vezes usado pelo
Gerenciamento de Problemas para identificar as possíveis causas.
Orçamento Uma lista de todo o dinheiro que uma unidade organizacional ou

planos de negócios para receber, e planeja pagar, durante um período
de tempo especificado. Veja também Planejamento, Orçamento.
Orçamento A Atividade de prever e controlar o gasto de dinheiro. Consiste de um

ciclo de negociação periódica para definir orçamentos futuros
(geralmente anual) eo acompanhamento do dia-a-dia e de ajuste de
Orçamentos atuais.
Construir (Transição de Serviço) a actividade de montagem de uma série de

itens de configuração para criar parte de um Serviço de TI. Construir o
termo é também usado para se referir a uma versão que está
autorizado para distribuição. Por exemplo Build Server ou laptop

Construir. Veja também linha de base de configuração.
Negócio (Estratégia de Serviço) Uma entidade corporativa geral ou

Organização formada por um número de Unidades de Negócios. No
contexto do ITSM, o termo Business inclui setor público e sem fins
lucrativos, bem como empresas. Um provedor de serviço de TI fornece
serviços de TI para um cliente dentro de uma empresa. O prestador de
serviço de TI pode ser parte do negócio mesmo que o seu cliente
(prestador de serviços interno), ou parte de outro negócio (prestador
de serviços externo).
Gerenciamento da (Desenho de Serviço) No contexto do ITSM, Negócios Gerenciamento

Capacidade de da Capacidade é a Atividade responsável por entender Requisitos de
negócios Negócio de futuro para utilização no Plano de Capacidade. Ver
também Gerenciamento da Capacidade de serviço.
Business Case (Estratégia de Serviço) Justificação para um item significativo das

despesas. Inclui informações sobre custos, benefícios, opções,
problemas, riscos e possíveis problemas. Veja também Análise de
Custo-Benefício.
Gestão de (Desenho de Serviço) O processo de negócio responsável pela gestão

Continuidade de de riscos que podem afectar gravemente o negócio. BCM
Negócios salvaguardas os interesses dos principais interessados, marca,
reputação e atividades que criam valor. O processo de BCM envolve a
redução dos riscos para um nível aceitável e planejamento para a
recuperação de Processos de Negócios deve uma interrupção dos
negócios ocorrem. BCM estabelece os objectivos, âmbito e Requisitos
para Gerenciamento de Continuidade de Serviço.
Plano de (Desenho de Serviço) Um Plano que define os passos necessários

Continuidade de para restaurar os processos de negócios após uma interrupção. O
Negócios Plano também vai identificar os gatilhos para Invocação, pessoas a
serem envolvidas, comunicações, etc TI planos de continuidade de
serviço formam uma parte significativa dos Planos de Continuidade de
Negócios.
Cliente negócio (Estratégia de Serviço) Um destinatário de um produto ou um serviço

do negócio. Por exemplo, se a empresa é uma fabricante de
automóveis, então o cliente de negócios é alguém que compra um
carro.
Análise de Impacto (Estratégia de Serviço) BIA é a atividade em Gestão de Continuidade

no Negócio de Negócios que identifica funções vitais do negócio e suas
dependências. Estas dependências podem incluir fornecedores,
pessoas, outros processos de negócios, serviços de TI, etc BIA define
os requisitos de recuperação de serviços de TI. Estes requisitos são:
Objetivos tempo de recuperação, os objetivos de ponto de
recuperação e metas de serviço mínimo para cada nível de serviço de
TI.
Objetivo do Negócio (Estratégia de Serviço) O objectivo de um processo de negócio, ou da

empresa como um todo. Objetivos do Negócio apoiar a visão de
negócios, fornecer orientações para a Estratégia de TI, e são muitas
vezes apoiados por serviços de TI.

Operações (Estratégia de Serviço) O dia-a-dia de execução, monitoramento e
comerciais gerenciamento de processos de negócios.
Perspectiva de (Melhoria de Serviço Continuada) Uma compreensão do prestador de

Negócios serviços e serviços de TI a partir do ponto de vista do negócio, e uma
compreensão do negócio do ponto de vista do provedor de serviço.
Business Process Um processo que é de propriedade e realizada pelo Negócios. A

Business Process contribui para a entrega de um produto ou serviço a
um cliente de Negócios. Por exemplo, um varejista pode ter um
processo de compras que ajuda a fornecer serviços a seus clientes
corporativos. Muitos processos de negócio dependem de serviços de
TI.
Gestão de (Estratégia de Serviço) O Processo ou Função responsável por manter

Relacionamento com um relacionamento com a empresa. Gestão de Relacionamento de
Empresas Negócios geralmente inclui:
• Gerenciamento de relacionamentos pessoais

com gerentes de negócios
• Fornecer subsídios para Gerenciamento de
Portfólio de serviço
• Assegurando que o prestador de serviço de TI
é satisfazer as necessidades de negócios dos
clientes
Este processo tem fortes ligações com Service Level Management.
Business Service Um serviço de TI que suporta diretamente um processo de negócio, ao

contrário de um Serviço de Infra-estrutura, que é utilizado internamente
pelo provedor de serviço de TI e normalmente não é visível para o
negócio.
O Business Service termo também é usado para significar um serviço

que é entregue aos clientes empresariais por Unidades de Negócio.
Por exemplo, a prestação de serviços financeiros para clientes de um
banco, ou de mercadorias para os clientes de uma loja de varejo.
Entrega bem sucedida de serviços de negócios, muitas vezes depende
de um ou mais serviços de TI.
Business Service (Estratégia de Serviço) (Desenho de Serviço) Uma abordagem para o

Management gerenciamento de serviços de TI que considera a processos de
negócio suportados eo valor de negócio fornecida.
Este termo também significa a gestão de serviços de negócios

entregues a clientes empresariais.
Unidade de Negócios (Estratégia de Serviço) Um segmento do negócio que tem seus

próprios planos, métricas, proveitos e custos. Cada Unidade de
Negócio possui ativos e usa-os para criar valor para os clientes na
forma de bens e serviços.
Chamar (Operação de Serviço) Uma chamada telefónica para o Posto de

Serviço de um Usuário. Uma chamada pode resultar em um incidente
ou uma solicitação de serviço sendo registrado.

Call Center (Operação de Serviço) Uma Unidade de organização ou empresa que
lida com um grande número de chamadas telefónicas de entrada e
saída. Veja também Service Desk.
Capacidade (Estratégia de Serviço) A capacidade de uma organização, pessoa,

item de processo, configuração do aplicativo, ou serviço de TI para
realizar uma atividade. Recursos são os ativos intangíveis de uma
organização. Veja também de recursos.
Capacidade (Desenho de Serviço) a vazão máxima que um Item de Configuração

ou Serviço de TI pode entregar reunião enquanto acordaram metas de
nível de serviço. Para alguns tipos de CI, A capacidade pode ser do
tamanho ou do volume, por exemplo, uma unidade de disco.
Gerenciamento da (Desenho de Serviço) O Processo responsável por garantir que a

Capacidade capacidade dos serviços de TI ea infra-estrutura de TI é capaz de
entregar as metas de nível de serviço acordado de forma eficaz e
atempada. Gerenciamento da Capacidade considera todos os recursos
necessários para oferecer o serviço de TI e planos para curto,
Requisitos de Negócio de médio e longo prazo.
Capacidade do (Desenho de Serviço) Um repositório virtual de todos os dados de

Sistema de gerenciamento de capacidade, normalmente armazenados em vários
Informação de Gestão locais físicos. Veja também Serviço de Sistema de Gestão do
Conhecimento.
Plano de capacidade (Desenho de Serviço) Um Plano de Capacidade é usado para

gerenciar os recursos necessários para entregar serviços de TI. O
Plano contém cenários para as previsões de demanda de negócios
diferentes e opções orçamentados para entregar os objetivos de nível
de serviço acordado.
Planejamento de (Desenho de Serviço) a atividade dentro de Gerenciamento da

Capacidade Capacidade responsável pela criação de um plano de capacidade.
Categoria Um grupo nomeado de coisas que têm algo em comum. Categorias

são usadas para agrupar coisas semelhantes. Por exemplo, os tipos
de custos são usadas para agrupar tipos similares de custo.
Categorias incidentes são usadas para agrupar tipos semelhantes de
Incidentes, Tipos de CI são usadas para agrupar tipos semelhantes de
item de configuração.
Certificado Emissão de um certificado para confirmar a conformidade a um

padrão. Certificação inclui uma auditoria formal por um organismo
independente e credenciada. A Certificação termo também é usado
para significar a atribuição de um certificado para verificar se uma
pessoa tem alcançado uma qualificação.
Mudar (Transição de Serviço) A adição, modificação ou remoção de tudo o

que poderia ter um efeito sobre serviços de TI. O escopo deve incluir
todos os Serviços de TI, itens de configuração, processos,
documentação, etc
Alterar Conselho (Transição de Serviço) Um grupo de pessoas que aconselha o Gerente

Consultivo de Mudança na avaliação, priorização e agendamento de alterações.
Esta placa é geralmente composto por representantes de todas as

áreas dentro do provedor de serviço de TI, representantes do negócio
e terceiros, como fornecedores.
Mudar a História (Transição de Serviço) Informações sobre todas as alterações feitas

em um Item de Configuração durante a sua vida. História mudança
consiste de todos esses registros de mudança que se aplicam ao CI.
Gestão da Mudança (Transição de Serviço) O Processo responsável por controlar o ciclo de

vida de todas as alterações. O principal objectivo da Gestão da
Mudança é permitir que mudanças benéficas para ser feita, com o
mínimo de perturbação para serviços de TI.
Solicitação de Veja Requisição de Mudança.

Mudança
Alterar agendamento (Transição de Serviço) um documento que lista todas as alterações

aprovadas e as respectivas datas de execução previstos. Um
programa de troca é às vezes chamado de Programação Futura de
Mudanças, mesmo que também contém informações sobre as
mudanças que já foram implementadas.
Janela Alterar (Transição de Serviço) Um regular, concordou momento Alterações ou

Releases podem ser implementadas com o mínimo impacto sobre
Serviços. O Windows mudança normalmente são documentados em
SLAs.
Carregamento (Estratégia de Serviço) exigência de pagamento por serviços de TI.

Cobrança de Serviços de TI é opcional, e muitas organizações escolha
para tratar o seu fornecedor de serviço de TI como um Centro de
Custo.
Classificação O ato de atribuir uma categoria para algo. A classificação é usada para
garantir uma gestão coerente e de relatórios. CIs, incidentes,
problemas, mudanças, etc, são geralmente classificados.
Cliente Um termo genérico que significa um cliente, a empresa ou um cliente

de negócios. Por exemplo, Client Manager pode ser usado como
sinônimo de Gerente de Contas.
O cliente termo também é utilizado para significar:
• Um computador que é usado diretamente por

um usuário, por exemplo, um PC, computador
portátil, estação de trabalho ou
• A parte de uma aplicação cliente-servidor que
o usuário diretamente a interface com. Por
exemplo, um cliente de e-mail.
Fechado (Operação de Serviço) O status final no Ciclo de Vida de um Incidente,

Problema, Mudança, etc Quando o Estado está fechada, nenhuma
outra ação será tomada.
Fecho (Operação de Serviço) O ato de mudar o status de um incidente,

problemas, mudanças, etc, para Fechado.

COBIT (Melhoria de Serviço Continuada) Objetivos de Controle para
Informações e Tecnologia relacionada (COBIT) fornece orientação
prática e melhor para a gestão de processos de TI. COBIT é publicado
pelo Instituto de Governança de TI. Veja www.isaca.org para mais
informações.
Espera frio Ver recuperação gradual.
Commercial Off-the- (Desenho de Serviço) O software aplicativo ou Middleware que pode

shelf ser comprado de uma terceira parte.
Observância A garantia de que uma norma ou conjunto de orientações é seguida,

ou que as práticas adequada, contabilidade consistente ou outra estão
sendo empregados.
Componente Um termo geral que é utilizado para significar uma parte de algo mais
complexo. Por exemplo, um sistema de computador pode ser um
componente de um Serviço de TI, um aplicativo pode ser um
componente de uma Unidade de lançamento. Os componentes que
precisam ser gerenciados deve ser Itens de Configuração.
Gerenciamento da (Desenho de Serviço) (Melhoria de Serviço Continuada) O processo

Capacidade responsável por entender a capacidade de utilização e desempenho
componente dos itens de configuração. Os dados são recolhidos, registados e
analisados para o uso no Plano de Capacidade. Ver também
Gerenciamento da Capacidade de serviço.
Componente CI (Transição de Serviço) Um item de configuração que é parte de um

conjunto. Por exemplo, um IC CPU ou de memória pode fazer parte de
um CI Server.
Componente Análise (Desenho de Serviço) Uma técnica que ajuda a identificar o impacto da
de Impacto falha falha CI em serviços de TI. A matriz é criada com TI em uma
extremidade e IC, por outro. Isso permite a identificação de itens de
configuração crítica (que poderia causar o fracasso de múltiplos
serviços de TI) e de Serviços de TI (frágeis que têm vários pontos
únicos de falha).
Simultaneidade Uma medida do número de utilizadores que efectuam a mesma

operação ao mesmo tempo.
Confidencialidade (Desenho de Serviço) Um princípio de segurança que requer que os

dados devem ser acessados somente por pessoas autorizadas.
Configuração (Transição de Serviço) Um termo genérico, usado para descrever um

grupo de itens de configuração que trabalham em conjunto para
oferecer um serviço de TI ou uma parte reconhecível de um Serviço de
TI. Configuração também é utilizada para descrever as configurações
de parâmetros para um ou mais itens de configuração.
Base de configuração (Transição de Serviço) Uma linha de base de uma configuração que
tenha sido formalmente aceite e é gerido através do processo de
Gerenciamento de Mudança. A linha de base de configuração é usado
como base para futuras Builds, Releases e alterações.
Controle de (Transição de Serviço) A Atividade responsável por garantir que

Configuração adicionar, alterar ou remover um CI é adequadamente gerida, por
exemplo através da apresentação de um pedido de alteração ou
solicitação de serviço.
Identificação da (Transição de Serviço) A Atividade responsável por coletar

Configuração informações sobre itens de configuração e seus relacionamentos, e
carregar essa informação na CMDB. Identificação configuração
também é responsável para rotular o IC-se, de modo que os registos
de configuração correspondente pode ser encontrada.
Item de Configuração (Transição de Serviço) qualquer componente que precisa de ser gerida
de forma a oferecer um serviço de TI. As informações sobre cada IC é
registrada em um registro de configuração dentro do Sistema de
Gestão de Configuração e é mantido durante todo seu ciclo de vida
pelo Configuration Management. CIs estão sob o controle de
Gerenciamento de Mudança. ICs tipicamente incluem serviços de TI,
hardware, software, prédios, pessoas e documentação formal, como a
documentação do processo e SLAs.
Gerenciamento da (Transição de Serviço) O Processo responsável por manter

Configuração informações sobre Itens de Configuração necessários para entregar
um serviço de TI, incluindo seus relacionamentos. Esta informação é
gerenciada durante todo o ciclo de vida do CI. Gerenciamento de
Configuração é parte de um activo Serviço geral e processo de gestão
de configuração.
Sistema de (Transição de Serviço) Um conjunto de ferramentas e bases de dados

Gerenciamento da que são usados para gerenciar dados de um provedor de serviços de
Configuração TI de configuração. O CMS também inclui informações sobre
incidentes, problemas, erros conhecidos, mudanças e lançamentos, e
podem conter dados sobre os funcionários, fornecedores, locais,
unidades de negócios, clientes e usuários. O CMS inclui ferramentas
para coletar, armazenar, gerenciar, atualizar e apresentar dados sobre
todos os itens de configuração e seus relacionamentos. O CMS é
mantida pela Gerência de Configuração e é utilizado por todos os
processos de gerenciamento de serviços. Veja também Serviço de
Sistema de Gestão do Conhecimento.
Melhoria de Serviço (Melhoria de Serviço Continuada) Uma fase no Ciclo de Vida de um

Continuada Serviço de TI eo título de uma das ITIL Núcleo publicações. Melhoria
de Serviço Continuada é responsável pela gestão de melhorias para
os processos de gerenciamento de serviços de TI e Serviços. O
desempenho do prestador de serviço de TI é continuamente medido e
melhorias são feitas para Processos, Serviços de TI e infraestrutura de
TI, a fim de aumentar a eficiência, eficácia e rentabilidade. Veja
também Plan-Do-Check-Act.
Disponibilidade (Desenho de Serviço) Uma abordagem ou desenho para atingir 100%

contínua de disponibilidade. Um continuamente disponível de Serviços de TI
não tem tempo de inatividade planejado ou não.
Operação Contínua (Desenho de Serviço) Uma abordagem ou desenho para eliminar

tempo de inatividade planejado de um Serviço de TI. Note-se que itens
de configuração individuais podem ser baixo, embora o serviço esteja
disponível.

Contrato Um acordo legalmente vinculativo entre duas ou mais partes.
Controlar Um meio de gestão de um risco, garantindo que um objectivo de

negócio é alcançado, ou garantir que um processo é seguido.
Controles de exemplo incluem políticas, procedimentos, funções RAID,
fechaduras, etc Um controle às vezes é chamado de contramedidas ou
de salvaguarda. Controle também significa gerenciar a utilização ou o
comportamento de um sistema de configuração do item, ou Serviço de
TI.
Controle de (Estratégia de Serviço) Uma abordagem para a gestão de serviços de

perspectiva TI, processos, funções, bens, etc Pode haver várias perspectivas
diferentes sobre o Controle de Serviços de TI mesmo, processo, etc,
permitindo que diferentes indivíduos ou equipes a concentrar-se no
que é importante e relevantes para a sua função específica.
Perspectivas de Controle de exemplo incluem gestão reativa e proativa
dentro de Operações de TI, ou uma visão do ciclo de vida de uma
equipe de projeto de aplicação.
Custar A quantidade de dinheiro gasto em uma atividade específica, de

Serviços de TI, ou Unidade de Negócios. Custos consistem de custo
real (dinheiro), custo teórico, como o tempo das pessoas, e de
depreciação.
Análise de Custo- Uma atividade que analisa e compara os custos e os benefícios

Benefício envolvidos em um ou mais cursos alternativos de ação. Ver também
Processo de Negócios, Retorno sobre o Investimento.
Eficácia de Custo Uma medida do equilíbrio entre a eficácia eo custo de um serviço,

processo ou atividade. Um processo de custo eficaz é aquele que
atinge os seus objectivos a um custo mínimo. Veja também KPI,
Retorno sobre o Investimento, Value for Money.
Contramedida Pode ser usado para se referir a qualquer tipo de controlo. O termo de
contramedidas é mais frequentemente usado quando se refere a
medidas que aumentar a resiliência, tolerância a falhas ou a
confiabilidade de um serviço de TI.
Gestão de Crises (Gerenciamento de Continuidade de Serviços) de Gestão de Crise é o

processo responsável por gerenciar as implicações mais amplas de
Continuidade de Negócios. Uma equipe de Gestão de Crise é
responsável por questões estratégicas como a gestão de relações com
a mídia e confiança dos acionistas, e decide quando invocar Planos de
Continuidade de Negócios.
Fator Crítico de Algo que deve acontecer se um processo, projeto, plano ou Serviço de
Sucesso TI é ter sucesso. KPIs são usados para medir a realização de cada
CSF. Por exemplo, uma LCR de "proteger Serviços de TI ao fazer
alterações" poderiam ser medidos por KPIs como "redução percentual
de alterações mal sucedidas", "percentagem de redução Alterações
causando incidentes", etc
Cultura Um conjunto de valores que são compartilhados por um grupo de

pessoas, incluindo expectativas sobre como as pessoas devem se
comportar, as suas ideias, crenças e práticas. Ver também Visão.

Cliente Alguém que compra produtos ou serviços. O cliente de um provedor de
serviço de TI é a pessoa ou grupo que define e aprova as metas de
nível de serviço. Os Clientes prazo também é por vezes usado
informalmente para significar Usuários, por exemplo, 'Esta é uma
organização focada no cliente ".
Painel de (Operação de Serviço) Uma representação gráfica do desempenho

instrumentos geral do serviço de TI e disponibilidade. Imagens do painel podem ser
atualizados em tempo real, e podem também ser incluídos nos
relatórios de gestão e páginas web. Painéis podem ser utilizados para
apoiar Gestão de Nível de Serviço, Gestão de Eventos ou Diagnóstico
de Incidentes.
Deliverable Algo que deve ser fornecida para cumprir um compromisso em um

Acordo de Nível de Serviço ou um contrato. Deliverable também é
usado de uma forma mais informal de significar uma saída prevista de
qualquer processo.
Gerenciamento da Atividades que compreendem e influenciar a demanda de clientes por

Demanda serviços e na oferta de capacidade para atender a essas demandas.
Em uma Gestão Estratégica nível de demanda pode envolver análise
de padrões de atividade de negócio e perfis de usuário. Em um nível
tático que pode envolver o uso de taxas diferenciadas para incentivar
os clientes a usar serviços de TI em momentos de menor movimento.
Veja também Gerenciamento da Capacidade.
Dependência A dependência directa ou indirecta de um processo ou atividade em

outro.
Desenvolvimento (Transição de Serviço) A Atividade responsável pelo movimento de

hardware novo ou alterado, software, documentação, processos, etc,
para o ambiente ao vivo. A implantação é parte do lançamento e
Processo de Gestão de Implantação.
Projeto (Desenho de Serviço) uma atividade ou processo que identifica os

requisitos e depois define uma solução que é capaz de atender a
esses requisitos. Ver também Design de Serviços.
Detecção (Operação de Serviço) Uma fase no Ciclo de Vida de Incidentes.

Resultados de detecção no incidente se tornar conhecido para o
provedor de serviço. A detecção pode ser automática, ou pode ser o
resultado de um utilizador iniciar sessão um incidente.
Desenvolvimento (Desenho de Serviço) O Processo responsável pela criação ou

modificação de um serviço de TI ou de aplicativos. Também é usado
para significar a função ou grupo que realiza trabalho de
desenvolvimento.
Ambiente de (Desenho de Serviço) Um Ambiente utilizada para criar ou modificar

Desenvolvimento serviços de TI ou Aplicações. Ambientes de Desenvolvimento não são
normalmente sujeitas ao mesmo grau de controle como ambientes de
teste ou ambientes vivos. Veja também Desenvolvimento.
Diagnóstico (Operação de Serviço) no estádio A de os ciclos de vida de incidentes

e problemas. O objetivo do diagnóstico é identificar uma solução para
um incidente ou a causa raiz de um problema.

Diferencial de Uma técnica usada para apoiar Gestão de Demanda cobrando valores
carregamento diferentes para a mesma função de Serviços de TI em momentos
diferentes.
Documento Informações de forma legível. Um documento pode ser papel ou

eletrônico. Por exemplo, uma declaração política, Acordo de Nível de
Serviço, Registro de Incidentes, diagrama do layout da sala de
computador. Veja também Record.
Tempo de inatividade (Desenho de Serviço) (Operação de Serviço) O momento em que um

Item de Configuração ou Serviço de TI não está disponível durante o
seu tempo de serviço acordado. A disponibilidade de um serviço
muitas vezes é calculado a partir de tempo de serviço acordado e
tempo de inatividade.
Motorista Algo que influencia estratégia, objectivos ou exigências. Por exemplo,

a nova legislação ou as ações dos concorrentes.
Economias de escala (Estratégia de Serviço) A redução do custo médio que é possível de

aumentar o uso de um serviço de TI ou de Ativos.
Eficácia (Melhoria de Serviço Continuada) Uma medida se os objectivos do

Processo de um serviço ou atividade foram alcançados. Um processo
efetivo ou atividade é aquele que atinge os seus objectivos acordados.
Veja também KPI.
Eficiência (Melhoria de Serviço Continuada) Uma medida de se o direito

quantidade de recursos foi utilizada para fornecer um processo,
serviço ou atividade. Um processo eficiente alcança seus objetivos
com o mínimo de tempo, dinheiro, pessoas ou outros recursos. Veja
também KPI.
Ambiente (Transição de Serviço) Um subconjunto da infra-estrutura de TI que é

usado para um propósito particular. Por exemplo: Ambiente Live, Test
Environment, ambiente de construção. É possível para vários
ambientes para compartilhar um item de configuração, por exemplo,
ambientes de teste e ao vivo pode usar partições diferentes em um
computador único mainframe. Também é usado no ambiente de prazo
Física para significar a acomodação, ar condicionado, sistema de
energia, etc
Ambiente também é usado como um termo genérico para designar as

condições externas que influenciam ou afetam algo.
Erro (Operação de Serviço) falha ou mau funcionamento Um projeto que

faz com que uma falha de um ou mais itens de configuração ou
serviços de TI. Um erro cometido por uma pessoa ou um processo
deficiente que afeta um serviço IC ou também é um erro.
Escalada (Operação de Serviço) Uma Atividade que obtém recursos adicionais,

quando estes são necessários para cumprir as metas de nível de
serviço ou expectativas dos clientes. Escalada pode ser necessária
dentro de qualquer Processo de Gestão de Serviços de TI, mas é mais
comumente associado com a Gestão de Incidentes, Gestão de
Problemas e gestão de reclamações de clientes. Existem dois tipos de
escalada escalada, funcional e escalonamento hierárquico.

eSourcing Modelo de (Estratégia de Serviço) Uma estrutura para ajudar os provedores de
Capacidade para serviços desenvolvem as suas capacidades de gestão de serviços de
prestadores de TI a partir de uma perspectiva de serviço de sourcing. eSCM-SP foi
serviços desenvolvido pela Carnegie Mellon University,EUA.
Estimativa O uso da experiência para fornecer um valor aproximado para uma

Métrica ou Custo. Estimativa é usado também em capacidade e gestão
de disponibilidade como o método mais barato e Modelagem menos
preciso.
Avaliação (Transição de Serviço) O Processo responsável por avaliar um novo

ou alterado Serviço de TI para garantir que os riscos foram
gerenciados e para ajudar a determinar se deseja prosseguir com a
mudança.
Avaliação também é usada para significar comparar um resultado real

com o resultado pretendido, ou comparar uma alternativa com outra.
Evento (Operação de Serviço) Uma mudança de estado que tem importância

para a gestão de um Item de Configuração ou Serviço de TI.
O Evento termo também é usado para significar um Alerta ou

notificação criada por qualquer TI item Configuração do serviço, ou a
ferramenta de monitoramento. Eventos geralmente requerem pessoal
de operações de TI tomar medidas, e muitas vezes levam a Incidentes
sendo registrados.
Gestão de Eventos (Operação de Serviço) O Processo responsável por gerenciar eventos

durante todo seu ciclo de vida. Gestão de Eventos é uma das
principais atividades das operações de TI.
Relatório de Exceção Um documento contendo detalhes de um ou mais KPIs ou outros alvos

importantes que tenham ultrapassado os limites definidos. Exemplos
incluem SLA alvos sendo perdidas ou prestes a ser perdida, e uma
métrica de desempenho que indica um problema de capacidade
potencial.
Ciclo de Vida do (Gerenciamento de Disponibilidade) etapas detalhadas no ciclo de vida

Incidente Expandido de um incidente. Os estágios são detecção, diagnóstico, reparação,
restauração, reconstrução. O Ciclo de Vida do Incidente Expandido é
usado para ajudar a compreender todas as contribuições para o
impacto dos incidentes e planejar como esses poderiam ser
controlados ou reduzidos.
Prestador de serviços (Estratégia de Serviço) Um provedor de serviço de TI que faz parte de

externo uma organização diferente ao seu cliente. Um provedor de serviço de
TI pode ter clientes internos e clientes externos.
Externa de Sourcing Veja Outsourcing.
Gestão de Instalações (Operação de Serviço) A Função responsável por gerenciar o

ambiente físico onde a infra-estrutura de TI está localizado. Facilities
Management inclui todos os aspectos de gestão do ambiente físico,
para poder exemplo e refrigeração, construção de acesso, gestão e
monitoramento ambiental.

Falha (Operação de Serviço) Perda de capacidade de operar com a
especificação, ou para entregar a saída necessária. A falha termo
pode ser usado quando se refere a serviços de TI, processos,
atividades, itens de configuração, etc Uma falha muitas vezes causa
um Incidente.
Recuperação rápida (Desenho de Serviço) Uma opção de recuperação que também é

conhecido como Hot Standby. A provisão é feita para recuperar o
serviço que num curto espaço de tempo: geralmente menos do que 24
horas. Recuperação rápida geralmente usa uma instalação dedicada
fixo com sistemas de computadores, software e configurado pronto
para executar os serviços de TI. Recuperação rápida pode levar até 24
horas, se há a necessidade de restaurar os dados a partir de backups.
Culpa Veja erro.
Tolerância a Falhas (Desenho de Serviço) A capacidade de um serviço de TI ou Item de

Configuração para continuar a funcionar corretamente após falha de
um componente. Veja também Resiliência, de contramedidas.
Análise da Árvore de (Desenho de Serviço) (Melhoria de Serviço Continuada) Uma técnica

Falhas que pode ser usada para determinar a cadeia de acontecimentos que
conduz a um problema. Análise da Árvore de Falhas representa uma
cadeia de eventos usando a notação booleana em um diagrama.
Gestão Financeira (Estratégia de Serviço) A função e os processos responsáveis pela

gestão de Orçamento de um provedor de serviço de TI, contabilidade e
carregamento de Requisitos.
Apto para o efeito Um termo informal usado para descrever um processo, Item de
Configuração, Serviço de TI, etc, que é capaz de cumprir os seus
objectivos ou níveis de serviço. Estar apto para o efeito requer um
projeto adequado, implementação, controle e manutenção.
Cumprimento Realizar atividades para atender a uma necessidade ou exigência. Por

exemplo, através de um Serviço de TI novo, ou satisfazer um pedido
de serviço.
Função Uma equipe ou grupo de pessoas e as ferramentas que eles usam

para realizar um ou mais processos ou atividades. Por exemplo, o
Service Desk.
A Função termo também tem dois outros significados:
• Um destino de um item de configuração,

Pessoa, equipe, Processo, ou Serviço de TI.
Por exemplo, uma função de um serviço de e-
mail pode ser a de armazenar e encaminhar e-
mails de saída, uma função de um processo
de negócio pode ser a expedição de
mercadorias aos clientes.
• Para realizar a finalidade pretendida
corretamente, "O computador está
funcionando".

Governo Assegurar que as políticas e estratégia são realmente implementadas,
e que os processos necessários são corretamente seguidas.
Governança inclui a definição de papéis e responsabilidades, medir e
comunicar, e tomar medidas para resolver os problemas identificados.
Recuperação gradual (Desenho de Serviço) Uma opção de recuperação que também é

conhecido como espera Fria. Provisão é feita para Recuperar o
Serviço de TI em um período de tempo superior a 72 horas.
Recuperação gradual geralmente usa um mecanismo portátil ou fixo
que tem suporte ambiental e cabeamento de rede, mas não há
sistemas de computador. O hardware e software são instalados como
parte do Plano de Continuidade dos Serviços de.
Diretriz Um documento que descreve Melhores Práticas, que recomenda que

deve ser feito. Cumprimento de uma diretriz não é normalmente
aplicada. Veja também Standard.
Alta Disponibilidade (Desenho de Serviço) Uma abordagem ou desenho que minimiza ou

esconde os efeitos da falha Item de Configuração sobre os utilizadores
de um serviço de TI. Soluções de alta disponibilidade são projetados
para atingir um nível acordado de Disponibilidade e fazer uso de
técnicas como a Tolerância a Falhas, Resiliência e Recuperação
rápida para reduzir o número de incidentes, eo impacto dos incidentes.
Hot Standby Veja a rápida recuperação ou recuperação imediata.
Recuperação (Desenho de Serviço) Uma opção de recuperação que também é

imediata conhecido como Hot Standby. Provisão é feita para Recuperar o
Serviço de TI, sem perda de serviço. Recuperação imediata
geralmente usa espelhamento de balanceamento de carga e
tecnologias do site Split.
Impacto (Operação de Serviço) (Transição de Serviço) Uma medida do efeito

de um incidente, problema ou mudança nos processos de negócio.
Impacto é muitas vezes baseada em como os níveis de serviço serão
afetados. Impacto e Urgência são usados para atribuir prioridade.
Incidente (Operação de Serviço) Uma interrupção não planejada de um serviço

de TI ou a redução da qualidade de um serviço de TI. Falha de um
item de configuração que ainda não afetou serviço é também um
Incidente. Por exemplo, a falha de um disco a partir de um conjunto de
espelho.
Gerenciamento de (Operação de Serviço) O Processo responsável por gerenciar o ciclo

Incidentes de vida de todos os incidentes. O objetivo principal do Gerenciamento
de Incidentes é retornar o Serviço de TI para clientes o mais rápido
possível.
Grave incidente (Operação de Serviço) Um Registro contendo os detalhes de um

incidente. Cada registro Incidente documenta o ciclo de vida de um
único incidente.
Custos Indiretos (Estratégia de Serviço) Um Custo de prestação de um serviço de TI, o

que não pode ser alocado integralmente para um cliente específico.
Por exemplo, o custo da prestação de servidores compartilhados ou
licenças de software. Também conhecido como sobrecarga.

Gestão de Segurança (Desenho de Serviço) O Processo que garante a confidencialidade,
da Informação integridade e disponibilidade dos ativos de uma organização,
informações, dados e serviços de TI. Gestão de Segurança da
Informação geralmente faz parte de uma abordagem organizacional
para gerenciamento de segurança que tem um escopo mais amplo do
que o provedor de serviço de TI, e inclui a manipulação de papel,
construção de acesso, telefonemas, etc, para toda a Organização.
Sistema de Gestão da (Desenho de Serviço) O quadro de políticas, processos, normas,

Segurança orientações e ferramentas que garantem uma organização pode atingir
os seus objectivos de gestão de segurança de informação.
Política de Segurança (Desenho de Serviço) A política que governa abordagem da

da Informação Organização de Gestão de Segurança da Informação.
Tecnologia da O uso da tecnologia para o armazenamento, comunicação ou

Informação processamento de informações. A tecnologia normalmente inclui
computadores, telecomunicações, aplicativos e outros softwares. A
informação pode incluir dados de negócios, voz, imagens, vídeos, etc
Tecnologia da Informação é muitas vezes utilizados para apoiar
processos de negócios através de serviços de TI.
Serviço de Infra- Um serviço de TI que não é usado diretamente pela empresa, mas é
estrutura exigido pelo provedor de serviço de TI para que eles possam oferecer
outros serviços de TI. Por exemplo, serviços de diretório, serviços de
identificação, ou serviços de comunicação.
Insourcing Veja Interna Sourcing.
Integridade (Desenho de Serviço) Um princípio de segurança que garante que os

dados e itens de configuração são modificados somente por pessoas
autorizadas e Atividades. Integridade considera todas as possíveis
causas de modificação, incluindo software e hardware falha, eventos
ambientais e intervenção humana.
Recuperação (Desenho de Serviço) Uma opção de recuperação que também é

Intermediário conhecido como espera passiva. Provisão é feita para Recuperar o
Serviço de TI em um período de tempo entre 24 e 72 horas.
Recuperação intermediário geralmente usa um mecanismo comum
portátil ou fixo que tem sistemas de computadores e componentes de
rede. O hardware e software precisa ser configurado, e os dados
precisam ser restaurados, como parte do Plano de Continuidade dos
Serviços de.
Provedor de serviço (Estratégia de Serviço) Um provedor de serviço de TI que faz parte da

interno Organização mesmo que o seu cliente. Um provedor de serviço de TI
pode ter clientes internos e clientes externos.
Interna de Sourcing (Estratégia de Serviço) Usando um provedor de serviço interno para

gerenciar serviços de TI.
Organização A Organização Internacional de Normalização (ISO) é a maior

Internacional para desenvolvedora mundial de Normas. ISO é uma organização não-
Padronização governamental que é uma rede de institutos de padrões nacionais de
156 países. Veja www.iso.org para obter mais informações sobre a
ISO.

ISO 9000 Um termo genérico que se refere a uma série de normas e diretrizes
internacionais para Sistemas de Gestão da Qualidade. Veja
www.iso.org para mais informações. Veja também ISO.
ISO 9001 Uma norma internacional para Sistemas de Gestão da Qualidade. Veja
também ISO 9000, Norma.
ISO / IEC 20000 ISO Especificação e Código de Boas Práticas para o Gerenciamento
de Serviços. ISO / IEC 20000 está alinhado com ITIL Best Practice.
ISO / IEC 27001 (Desenho de Serviço) (Melhoria de Serviço Continuada) Especificação

ISO de Gestão de Segurança da Informação. O Código
correspondente da prática é a norma ISO / IEC 17799. Veja também
Standard.
Infraestrutura de TI Todo o hardware, software, redes, instalações, etc, que são

necessários para desenvolver, testar, entregar, monitorar, controlar ou
apoiar serviços de TI. O termo infra-estrutura de TI inclui toda a
Tecnologia da Informação, mas não as pessoas associadas,
processos e documentação.
Operações de TI (Operação de Serviço) Atividades realizadas pela TI Controle de

Operações, incluindo Management Console, Job Scheduling, Backup e
Restauração, e impressão e Gestão de Produção. Operações de TI
também é usado como sinônimo de Operação de Serviço.
Serviços de TI Um serviço prestado a um ou mais clientes por um fornecedor de

serviços de TI. Um serviço de TI é baseado no uso de Tecnologia da
Informação e Processos de suporte de negócio do cliente. Um serviço
de TI é feita a partir de uma combinação de pessoas, processos e
tecnologia e deve ser definido em um Acordo de Nível de Serviço.
Gerenciamento da (Desenho de Serviço) O Processo responsável por gerenciar os riscos

Continuidade do que poderiam afetar seriamente Serviços de TI. ITSCM garante que o
Serviço provedor de serviço de TI pode sempre fornecer níveis mínimos de
serviço acordado, reduzindo o risco a um nível aceitável e
Planejamento de Recuperação de Serviços de TI. ITSCM deve ser
projetado para suportar Gestão de Continuidade de Negócios.
TI Plano de (Desenho de Serviço) Um Plano que define os passos necessários

Continuidade do para recuperar um ou mais serviços de TI. O Plano também vai
Serviço identificar os gatilhos para Invocação, pessoas a serem envolvidas,
comunicações, etc O Plano de Continuidade de Serviços de TI devem
fazer parte de um Plano de Continuidade de Negócios.
IT Service A implementação e gestão da Qualidade de Serviços de TI que

Management atendam as necessidades do negócio. IT Service Management é
realizada por serviços de TI através de uma combinação adequada de
Tecnologia de pessoas, processos e informação. Ver também Serviço
de Gestão de.
Provedor de serviço (Estratégia de Serviço) Um prestador de serviços que fornece serviços

de TI de TI para clientes internos ou clientes externos.
Grupo de Um grupo formal, que é responsável por garantir que as empresas e

Coordenação de TI as estratégias de TI prestadoras de serviços e planos estão alinhados.

Um Grupo de Coordenação de TI inclui representantes de alto nível do
negócio e do provedor de serviços de TI.
ITIL Um conjunto de orientações de Melhores Práticas para o

Gerenciamento de Serviços. ITIL é de propriedade do OGC e consiste
de uma série de publicações com orientações sobre a prestação de
Qualidade de Serviços de TI, e sobre os processos e instalações
necessários para apoiá-los. Veja www.itil.co.uk para mais informações.
Descrição trabalho Um documento que define os papéis, responsabilidades, habilidades e

conhecimentos necessários por uma pessoa em particular. Uma
descrição do trabalho pode incluir várias funções, por exemplo, os
papéis do Configuration Manager e Change Manager pode ser
realizada por uma pessoa.
Job Scheduling (Operação de Serviço) Planejamento e gerenciamento da execução de

tarefas de software que são requeridos como parte de um serviço de
TI. Job Scheduling é realizado pela IT Operations Management, e
muitas vezes é automatizado usando ferramentas de software que
rodam em lote ou tarefas on-line em horários específicos do dia,
semana, mês ou ano.
Key Performance (Desenho de Serviço) (Melhoria de Serviço Continuada) Uma métrica

Indicator que é usado para ajudar a gerenciar um processo, serviço ou
actividade. Muitas métricas podem ser medidos, mas só o mais
importante deles são definidos como KPIs e usado para gerenciar
ativamente e informar sobre o processo, serviço ou actividade. KPIs
devem ser selecionados para garantir que eficiência, eficácia e custo-
eficácia são geridos. Veja como Fator de Sucesso também Crítica.
Base de (Transição de Serviço) Um banco de dados lógico que contém os

Conhecimento dados utilizados pelo Sistema de Gerenciamento de Serviços de
Conhecimento.
Gestão do (Transição de Serviço) O Processo responsável pela coleta, análise,

Conhecimento armazenamento e compartilhamento de conhecimento e informação
dentro de uma organização. O principal objetivo da Gestão do
Conhecimento é melhorar a eficiência, reduzindo a necessidade de
redescobrir o conhecimento. Veja também Serviço de Sistema de
Gestão do Conhecimento.
Erro Conhecido (Operação de Serviço) Um problema que tem uma causa raiz
documentada e uma solução alternativa. Erros Conhecidos são criados
e gerenciados durante todo seu ciclo de vida pelo Gerenciamento de
Problemas. Erros conhecidos também pode ser identificado por
Desenvolvimento ou Fornecedores.
Ciclo de Vida As várias fases na vida de um Serviço de TI, Item de Configuração,

Incidentes, Problemas, Mudanças, etc O ciclo de vida define as
categorias para Estado e as transições de estado que são permitidos.
Por exemplo:
• O Ciclo de Vida de uma Aplicação inclui

Requisitos, projetar, construir, implantar,
operar, Otimizar
• O Ciclo de Vida do Incidente Expandido inclui

detectar, responder, Diagnosticar, reparar,
recuperar, restaurar
• O ciclo de vida de um servidor podem incluir:
Pedido, recebeu, em teste, vivo, disposto, etc
Linha de Serviço (Estratégia de Serviço) Um Core Service ou serviço de apoio que tem
pacotes de múltiplos níveis de serviço. Uma linha de serviço é
gerenciado por um gerente de produto e cada pacote de nível de
serviço é projetado para suportar um determinado segmento de
mercado.
Viver (Transição de Serviço) Refere-se a um item de serviço ou de

configuração de TI que está sendo usado para fornecer serviço a um
cliente.
Viver Ambiente (Transição de Serviço) Um Ambiente controlado contendo itens de

configuração ao vivo usados para fornecer serviços de TI para clientes.
Manutenibilidade (Desenho de Serviço) Uma medida de como o serviço de forma rápida

e eficazmente um Item de Configuração ou pode ser restaurado ao
funcionamento normal após uma falha. Manutenibilidade é
frequentemente medido e relatado como MTRS.
Manutenibilidade é também usado no contexto de Software ou IT

Development Service para significar capacidade de ser alterado ou
reparado facilmente.
Incidente grave (Operação de Serviço) Categoria mais alto de Impacto de um

Incidente. A Principais resultados incidente em perturbação
significativa para o negócio.
Serviços Gerenciados (Estratégia de Serviço) Uma perspectiva em serviços de TI que

enfatiza o fato de que eles são geridos. Os Serviços Gerenciados
prazo também é usado como sinônimo de serviços de TI terceirizados.
Gestão da Informação Informações que são usadas para apoiar a tomada de decisão pelos
gestores. Gestão da informação é muitas vezes gerado
automaticamente por ferramentas que suportam os diversos processos
de Gerenciamento de Serviços. Gestão da Informação, muitas vezes
inclui os valores de KPIs como "porcentagem de alterações que levam
a incidentes", ou "taxa de correção pela primeira vez".
Gestão de Risco A metodologia de gerenciamento de riscos OGC. M_o_R inclui todas

as atividades necessárias para identificar e controlar a exposição ao
risco, o que pode ter um impacto sobre a realização dos objetivos de
uma organização de negócios. Veja www.m-o-r.org para mais
detalhes.
Sistema de Gestão O quadro de políticas, processos e funções que garante uma

organização pode alcançar seus objetivos.
Solução manual Uma solução que requer a intervenção manual. Solução manual
também é usado como o nome de uma opção de recuperação em que
o Business Process Funciona sem o uso de serviços de TI. Esta é uma
medida temporária e é normalmente combinada com outra opção de

recuperação.
Maturidade (Melhoria de Serviço Continuada) Uma medida da, Organização

Função confiabilidade, eficiência e eficácia de um processo, etc Os
processos mais maduros e funções são formalmente alinhados aos
objetivos de negócio e estratégia, e são apoiados por um quadro de
melhoria contínua.
Tempo médio entre (Desenho de Serviço) Uma Métrica para medir e relatar Confiabilidade.
falhas MTBF é o tempo médio que um Item de Configuração ou Serviço de TI
pode desempenhar sua função acordada sem interrupção. Este é
medido a partir de quando o serviço de CI ou ele começa a trabalhar,
até que próximo falhar.
Tempo médio entre (Desenho de Serviço) A métrica usada para medir e informar
Incidentes de Serviço Confiabilidade. TMEIS é o tempo médio de quando um sistema ou
serviço de TI falhar, até que próximo falhar. TMEIS é igual ao MTBF +
MTRS.
Mean Time To Repair O tempo médio para reparar um Item de Configuração ou Serviço de
TI após uma falha. MTTR é medido a partir de quando o serviço de CI
ou falhar até que seja consertado. MTTR não inclui o tempo
necessário para recuperar ou restaurar. MTTR é por vezes
incorretamente usado para significar tempo médio para restaurar o
serviço.
Tempo médio para O tempo médio para restaurar um Item de Configuração ou Serviço de
restaurar o serviço TI após uma falha. MTRS é medido a partir de quando o serviço de CI
ou falhar até que seja totalmente restaurado e entregar a sua
funcionalidade normal. Veja também Manutenibilidade, Tempo médio
para reparo.
Métrico (Melhoria de Serviço Continuada) Algo que é medido e relatado para

ajudar a gerenciar um processo, serviço ou actividade. Veja também
KPI.
Middleware (Desenho de Serviço) O software que conecta duas ou mais

componentes de software ou aplicativos. Middleware é geralmente
comprado de um Fornecedor, Em vez de desenvolver dentro do IT
Provedor de serviços. Veja também fora da prateleira.
Modelo Uma representação de um sistema, processo, serviços de TI, Item de

Configuração, etc, que é usado para ajudar a compreender e prever o
comportamento futuro.
Modelagem Uma técnica que é usada para prever o comportamento futuro de um

sistema, processo, serviços de TI, item de configuração, etc
Modelagem é comumente usado em Gestão Financeira, Gestão de
Capacidade e Gerenciamento da Disponibilidade.
Monitoramento (Operação de Serviço) a observação repetida de um item de

configuração, serviço ou processo para detectar eventos e para
garantir que a situação atual é conhecido.
Objetivo O objetivo definido ou fim de um processo, uma atividade ou de uma

Organização como um todo. Os objetivos são geralmente expressa

como metas mensuráveis. O Objetivo termo também é usado
informalmente para significar uma exigência. Veja também Resultado.
Off-the-shelf Veja Commercial Off-the-shelf.
Office of Government OGC é dona da marca ITIL (direitos autorais e marca registrada). OGC
Commerce é um departamento do Governo do Reino Unido que suporta a entrega
da agenda do governo de aquisições por meio de seu trabalho nos
contratos de colaboração e no aumento dos níveis de habilidades e
capacidade de aquisição dentro dos departamentos. Ele também
fornece suporte para complexos projetos do setor público.
Off-shore (Estratégia de Serviço) Provisão de Serviços a partir de um local fora

do país onde o cliente baseia-se, muitas vezes em um continente
diferente. Esta pode ser a prestação de um serviço de TI, ou de
funções de suporte, como um Service Desk. Veja também on-shore.
Em terra (Estratégia de Serviço) Provisão de serviços de um local dentro do

país, onde o cliente é baseada. Veja também off-shore.
Operar Para o desempenho esperado. Um processo ou Item de Configuração

é dito para operar se está entregando os resultados desejados. Operar
também significa executar uma ou mais operações. Por exemplo, para
operar um computador é fazer as operações do dia-a-dia necessários
para que o desempenho esperado.
Operação (Operação de Serviço) a gestão do dia-a-dia de um serviço de TI,

Sistema ou Item de Configuração outro. Operação também é usada
para significar qualquer atividade pré-definido ou transação. Por
exemplo carregar uma fita magnética, aceitando dinheiro em um ponto
de venda, ou leitura de dados a partir de uma unidade de disco.
Operacional O mais baixo dos três níveis de Planejamento e de entrega

(Estratégico, Tático, Operacional). Atividades operacionais incluem o
dia-a-dia de Planejamento ou de curto prazo ou entrega de um
processo de negócio ou de TI Processo de Gestão de Serviço. O
termo operacional é também um sinônimo para Live.
Custo Operacional Custo resultante da execução dos serviços de TI. Muitas vezes,
repetindo pagamentos. Por exemplo os custos de pessoal,
manutenção de hardware e eletricidade (também conhecido como
"despesas correntes" ou "despesas receitas»).
Acordo de Nível (Desenho de Serviço) (Melhoria de Serviço Continuada) um acordo

Operacional entre um provedor de serviço de TI e outra parte da mesma
organização. Um OLA suporta a entrega do provedor de serviço de TI,
serviços de TI para clientes. O OLA define os bens ou serviços a
serem prestados e as responsabilidades de ambas as partes. Por
exemplo, poderia haver um OLA:
• Entre o prestador de serviço de TI e um

departamento de compras para obter
hardware em tempos acordados
• Entre o Service Desk e um grupo de apoio
para fornecer a resolução de incidentes em

tempos acordados.
Ver também Acordo de Nível de Serviço.
Otimizar Plano de Revisão e solicitar alterações, a fim de obter a máxima

eficiência e eficácia de um processo, item de configuração, aplicação,
etc
Organização A empresa, pessoa jurídica ou outra instituição. Exemplos de

organizações que não são empresas incluem International Standards
Organization ou itSMF. A Organização termo é por vezes utilizado para
se referir a qualquer entidade que tenha pessoas, recursos e
orçamentos. Por exemplo, um projeto ou unidade de negócios.
Resultado O resultado do exercício de uma actividade, na sequência de um

processo; entregar um serviço de TI, etc O Resultado termo é usado
para se referir a resultados pretendidos, bem como os resultados reais.
Veja também Objetivo.
Terceirização (Estratégia de Serviço) Utilizando um prestador de serviços externo

para gerenciar serviços de TI.
Despesas gerais Veja custo indireto.
Parceria A relação entre duas organizações que envolve o trabalho em conjunto

de objetivos comuns ou benefício mútuo. O prestador de serviços de TI
deve ter uma parceria com a empresa, e com terceiros, que são
críticos para a entrega de serviços de TI. Ver também Rede de Valor.
Monitoramento (Operação de Serviço) O monitoramento de um item de configuração,

passivo um serviço de TI ou de um processo que depende de um alerta ou
notificação para descobrir o status atual.
Padrão de Atividade (Estratégia de Serviço) Um perfil de carga de trabalho de uma ou mais

de Negócios atividades empresariais. Padrões de atividade de negócio são usados
para ajudar o prestador de serviço de TI compreender e planejar para
os diferentes níveis de atividade comercial.
Atuação Uma medida que é alcançado ou entregue por um sistema, pessoa,

equipe, Processo, ou Serviço de TI.
Gestão de (Melhoria de Serviço Continuada) O Processo responsável pelo dia-a-

Desempenho dia de gerenciamento de capacidade. Estes incluem monitoramento,
limiar de detecção, análise e ajuste de desempenho e alterações de
execução relativas ao desempenho e capacidade.
Piloto (Transição de Serviço) Implantação A limitada de um Serviço de TI, um

lançamento ou um processo para o ambiente ao vivo. Um piloto é
usado para reduzir o risco e para obter feedback do usuário e
aceitação. Veja também Avaliação de Testes.
Plano Uma proposta detalhada que descreve as atividades e recursos

necessários para atingir um objetivo. Por exemplo, um plano para
implementar um novo serviço de TI ou processo. ISO / IEC 20000
requer um plano de gestão de cada um Processo de Gestão de
Serviços de TI.

Plan-Do-Check-Act (Melhoria de Serviço Continuada) Um ciclo de quatro fases para a
gestão de processos, atribuída a Edward Deming. Plan-Do-Check-Act
também é chamado de Ciclo de Deming.
PLANO: Desenho ou revisar processos que suportam os serviços de

TI.
DO: Implementar o Plano e gerenciar os processos.
VERIFICAÇÃO: medir os processos e serviços de TI, compare com

objetivos e produzir relatórios.
ACT: Planejar e implementar mudanças para melhorar os processos.
Tempo de inatividade (Desenho de Serviço) Acordado momento em que um serviço de TI

planejado não estará disponível. Tempo de inatividade planejado é
frequentemente usado para manutenção, atualizações e testes. Veja
também Alterar Janela, O tempo de inatividade.
Planejamento Uma Atividade responsável pela criação de um ou mais planos. Por

exemplo, planejamento de capacidade.
PMBOK Um padrão de gerenciamento do Projeto mantida e publicada pelo

Project Management Institute. PMBOK significa Corpo de
Gerenciamento de Projetos do Conhecimento. Veja www.pmi.org para
mais informações. Veja também PRINCE2.
Política Formalmente documentado expectativas da administração e intenções.

Políticas são usados para decisões diretas, e para garantir o
desenvolvimento coerente e adequado e implementação de
processos, padrões, papéis, atividades, infra-estrutura de TI, etc
Facilidade portátil (Desenho de Serviço) Um edifício pré-fabricado, ou um veículo de

grande porte, fornecido por um terceiro e se mudou para um local
quando necessário por um Plano de Continuidade de Serviço de TI.
Veja também opção de recuperação.
Pós-Implementação Uma revisão que ocorre depois de uma mudança ou um projeto foi
comentário implementado. A PIR determina se a alteração ou projeto foi bem
sucedido, e identifica oportunidades de melhoria.
Prática A maneira de trabalhar, ou uma maneira em que o trabalho deve ser

feito. Práticas podem incluir atividades, processos, funções, normas e
orientações. Veja também Best Practice.
Pré-requisito para o Uma atividade que precisa ser concluída, ou uma condição que
sucesso precisa ser cumprida, para permitir a implementação bem sucedida de
um Plano ou processo. A PFS é frequentemente uma saída de um
processo que é uma entrada necessária para outro processo.
Preços (Estratégia de Serviço) A Atividade para estabelecer o quanto os

clientes serão cobrados.
PRINCE2 O padrão Reino Unido metodologia de governo para a gestão do

projeto. Veja www.ogc.gov.uk/prince2 para mais informações. Veja

também PMBOK.
Prioridade (Transição de Serviço) (Operação de Serviço) Uma Categoria usada

para identificar a importância relativa de um incidente, problema ou
mudança. Prioridade é baseada em impacto e urgência, e é usado
para identificar os tempos necessários para as ações a serem
tomadas. Por exemplo, a SLA pode-se afirmar que a prioridade de dois
incidentes devem ser resolvidos dentro de 12 horas.
Problema (Operação de Serviço) Uma causa de um ou mais incidentes. A causa

geralmente não é conhecido no momento um registro de problema é
criado, eo processo de Gerenciamento de Problema é responsável por
uma investigação mais aprofundada.
Gerenciamento de (Operação de Serviço) O Processo responsável por gerenciar o ciclo

Problemas de vida de todos os problemas. Os principais objetivos do
Gerenciamento de Problemas são para evitar incidentes de acontecer,
e para minimizar o impacto dos incidentes que não podem ser
evitados.
Procedimento Um documento contendo os passos que especificam como realizar

uma atividade. Procedimentos são definidos como parte de Processos.
Ver também Instrução de Trabalho.
Processo Um conjunto estruturado de atividades destinadas a alcançar um

objetivo específico. Um processo leva uma ou mais entradas definidas
e as transforma em saídas definidas. Um processo pode incluir
qualquer um dos papéis, responsabilidades, ferramentas e gestão de
controlos necessários para entregar de forma confiável as saídas. Um
processo pode definir políticas, normas, orientações, atividades e
Instruções de Trabalho, se eles são necessários.
Controle de Processo A atividade de planejamento e regulação de um processo, com o

objetivo de realizar o processo de forma eficaz, eficiente e consistente.
Proprietário do Um papel responsável por garantir que um processo está apto para o
Processo efeito. As responsabilidades do proprietário do processo incluem
patrocínio, Design, Gestão de Mudança e melhoria contínua do
processo e suas métricas. Este papel é muitas vezes atribuída a
mesma pessoa que exerce a função de Gerente de Processo, mas as
duas funções pode ser separado em organizações maiores.
Proforma Um documento de modelo, ou exemplo contendo dados de exemplo

que serão substituídos pelos valores reais quando estes estão
disponíveis.
Programa Uma série de projetos e atividades que são planejadas e gerenciadas

em conjunto para alcançar um conjunto global de objectivos
relacionados e outros resultados.
Projeto A Organização temporária, com pessoas e outros Ativos necessários

para atingir um resultado objetivo ou outro. Cada projeto tem um ciclo
de vida que normalmente inclui iniciação, planejamento, execução,
encerramento, projetos etc geralmente são gerenciados usando uma
metodologia formal, como PRINCE2.

Qualidade A capacidade de um produto, serviço ou processo para fornecer o
valor pretendido. Por exemplo, um componente de hardware pode ser
considerado de elevada qualidade, se o desempenho esperado e
oferece a confiabilidade necessária. Qualidade processo também
exige uma capacidade de monitorar a eficácia e eficiência, e para
melhorá-los, se necessário. Veja também Sistema de Gestão da
Qualidade.
Sistema de Gestão da (Melhoria de Serviço Continuada) O conjunto de processos

Qualidade responsáveis por garantir que todo o trabalho realizado por uma
organização é de qualidade adequada para atender de forma confiável
Objetivos de negócios ou Nível de serviços. Veja também ISO 9000.
RACI (Desenho de Serviço) (Melhoria de Serviço Continuada) Um modelo

usado para ajudar a definir papéis e responsabilidades. RACI significa
Responsável, responsável, consultado e informado.
Acordo de (Desenho de Serviço) uma opção de recuperação. Um acordo entre

reciprocidade duas organizações para compartilhar recursos em uma emergência.
Por exemplo, o espaço Sala de Informática ou o uso de um mainframe.
Registro Um documento contendo os resultados ou outra saída a partir de um

processo ou atividade. Os registros são a prova de que uma atividade
ocorreu e pode ser papel ou eletrônico. Por exemplo, um relatório de
auditoria, um registro de incidentes, ou as atas de uma reunião.
Recuperação (Desenho de Serviço) (Operação de Serviço) Retornar um Item de

Configuração ou um Serviço de TI para um estado de funcionamento.
Recuperação de um serviço de TI, muitas vezes inclui a recuperação
de dados em um estado conhecido consistente. Após a recuperação,
medidas adicionais podem ser necessárias antes de o serviço que
pode ser disponibilizado para os Usuários (Restauração).
Opção de (Desenho de Serviço) Uma estratégia para responder a uma

recuperação interrupção de serviço. Estratégias comumente usados são não fazer
nada, solução manual, acordo de reciprocidade, recuperação gradual,
recuperação intermediária, rápida recuperação, recuperação imediata.
Opções de recuperação podem fazer uso de instalações específicas
ou instalações de terceiros compartilhados por várias empresas.
Redundância Veja tolerância a falhas.
O termo redundante também tem um significado genérico de obsoleto,

ou deixaram de ser necessários.
Relação Uma conexão ou interação entre duas pessoas ou coisas. Em Gestão

de Relacionamento de Negócios é a interação entre o prestador de
serviço de TI e de Negócios. Em Gerenciamento de Configuração, é
um elo entre dois itens de configuração que identifica uma
dependência ou conexão entre eles. Por exemplo candidaturas podem
ser ligados aos servidores são executadas. Serviços de TI tem muitos
links para todos os itens de configuração que contribuam com eles.
Processos de A ISO / IEC 20000 Processo de grupo que inclui Gestão de Negócios e
Relacionamento Gestão de Relacionamento Fornecedor.

Solte (Transição de Serviço) Uma coleção de hardware, software,
documentação, processos ou outros componentes necessários para
implementar uma ou mais aprovou alterações aos serviços de TI. O
conteúdo de cada lançamento são geridos, testado e implantado como
uma única entidade.
Gerenciamento de (Transição de Serviço) O Processo responsável tanto Gerenciamento

Liberação e de Liberação e Implantação.
Implantação
Gerenciamento de (Transição de Serviço) O Processo responsável por planejar,

Liberação programar e controlar o movimento de lançamentos para testar e Live
Ambientes. O objetivo primário do Gerenciamento de Liberação é
garantir que a integridade do ambiente vivo está protegido e que os
componentes corretos são liberados. Gerenciamento de Liberação é
parte do lançamento e Processo de Gestão de Implantação.
Registro de (Transição de Serviço) A Record no CMDB que define o conteúdo de

Lançamento um comunicado. A Record Lançamento tem relações com todos os
itens de configuração que são afectados pela libertação.
Confiança (Desenho de Serviço) (Melhoria de Serviço Continuada) Uma medida

de quanto tempo um item de configuração ou serviço de TI pode
desempenhar sua função acordada sem interrupção. Normalmente
medida como MTBF ou TMEIS. A Confiabilidade termo também pode
ser usado para indicar como provável é que um processo, função, etc
vai entregar suas saídas exigidas. Veja também disponibilidade.
Reparar (Operação de Serviço) A substituição ou correção de um item de

configuração falhou.
Requisição de (Transição de Serviço) Uma proposta formal de alteração a ser feita.

Mudança Uma RFC inclui detalhes da mudança proposta, e pode ser registrada
em papel ou eletronicamente. O RFC termo é freqüentemente mal
utilizada para significar um registro de mudança, ou a mudança em si.
Cumprimento de (Operação de Serviço) O Processo responsável por gerenciar o ciclo

Requisição de vida de todas as solicitações de serviço.
Exigência (Desenho de Serviço) Uma declaração formal de que é necessário.

Por exemplo, um requisito de nível de serviço, uma exigência do
projeto ou das entregas necessárias para um processo. Ver também
Declaração de requisitos.
Resiliência (Desenho de Serviço) A capacidade de um item de configuração ou

serviço de TI para resistir à falha ou recuperar rapidamente após uma
falha. Por exemplo, um cabo blindado irá resistir falha quando
colocado sob estresse. Veja também tolerância a falhas.
Resolução (Operação de Serviço) Ação tomada para reparar a causa raiz de um

incidente ou problema, ou para implementar uma solução alternativa.
Na norma ISO / IEC 20000, os processos de resolução é o grupo que
inclui Processo de Incidentes e Gestão de Problemas.
Recurso (Estratégia de Serviço) Um termo genérico que inclui infraestrutura de

TI, pessoas, dinheiro ou qualquer outra coisa que possa ajudar a

proporcionar um serviço de TI. Os recursos são considerados ativos de
uma organização. Veja também a capacidade, Serviço de ativos.
Tempo de Resposta Uma medida do tempo necessário para completar uma operação ou
transação. Usado em Gerenciamento da Capacidade como uma
medida do desempenho de TI Infra-estrutura, e em Gerenciamento de
Incidentes como uma medida do tempo necessário para atender o
telefone, ou para iniciar Diagnóstico.
Capacidade de A medição do tempo necessário para responder a qualquer coisa. Este

resposta poderia ser tempo de resposta de uma transação, ou a velocidade com
que um fornecedor de serviços de TI responde a um incidente ou
solicitação de mudança, etc
Restauração de Veja Restaurar.

Serviço
Restaurar (Operação de Serviço) Tomar medidas para devolver um serviço de TI

aos Usuários após reparação e recuperação de um incidente. Este é o
principal objetivo do Gerenciamento de Incidentes.
Aposentar (Transição de Serviço) a remoção permanente de um serviço de TI ou

Item de Configuração outro, do ambiente ao vivo. Aposentado é uma
fase do ciclo de vida de muitos itens de configuração.
Retorno sobre (Estratégia de Serviço) (Melhoria de Serviço Continuada) Uma medida

Investimento do benefício esperado de um investimento. No sentido mais simples é
o lucro líquido de um investimento dividido pelo patrimônio líquido dos
ativos investidos.
Retornar para Normal (Desenho de Serviço) A fase de um Plano de Continuidade dos

Serviços de completos durante o qual as operações normais são
retomadas. Por exemplo, se um centro de dados alternativo está em
uso, então essa fase vai trazer o centro de dados primário de volta em
operação, e restaurar a capacidade de invocar TI Continuidade do
Serviço de planos novamente.
Comente A avaliação de uma Mudança, Problema, Processo, Project, etc

Comentários são normalmente realizadas em pontos pré-definidos no
Ciclo de Vida e, especialmente, após o encerramento. O propósito de
um comentário é garantir que todos os resultados foram fornecidos, e
identificar oportunidades de melhoria. Veja também Revisão pós-
implementação.
Direitos (Operação de Serviço) direitos ou permissões, concedidas a um

usuário ou função. Por exemplo, o direito de modificar os dados
particulares, ou autorizar uma mudança.
Risco Um evento possível que possa causar danos ou perda, ou afetar a

capacidade de alcançar os objetivos. Um risco é medido pela
probabilidade de uma ameaça, a vulnerabilidade do Activo a essa
ameaça, e do impacto que teria se ele ocorreu.
Avaliação de Risco Os passos iniciais da gestão de risco. Analisando o valor dos ativos
para o negócio, identificando ameaças a esses ativos, e avaliar como
cada ativo é vulnerável a essas ameaças. Avaliação de Risco pode ser

quantitativa (com base em dados numéricos) ou qualitativa.
Gestão de risco O Processo responsável pela identificação, avaliação e controle de

riscos. Veja também Avaliação de Risco.
Papel Um conjunto de responsabilidades, atividades e autoridades

concedidas a uma pessoa ou equipe. Um papel é definido em um
processo. Uma pessoa ou equipe pode ter várias funções, por
exemplo, os papéis do Configuration Manager e Change Manager
pode ser realizada por uma única pessoa.
Causa raiz (Operação de Serviço) A causa subjacente ou original de um incidente

ou problema.
Custos de Veja Custo Operacional.

funcionamento
Escalabilidade A capacidade de um Serviço de TI, Processo, Item de Configuração,

etc, para executar sua função acordada quando as mudanças de
carga de trabalho ou de escopo.
Escopo O limite, ou extensão, para que um processo, procedimento contrato

de certificação, etc se aplica. Por exemplo, o escopo de
Gerenciamento de Mudança pode incluir todos ao vivo Serviços de TI
e itens de configuração relacionados, o escopo de uma norma ISO /
IEC 20000 Certificado pode incluir todos os serviços de TI entregues
fora de um centro de dados chamado.
Segurança Consulte Informações Gestão de Segurança.
Gestão de Segurança Consulte Informações Gestão de Segurança.
Política de segurança Consulte Informações Política de Segurança.
Separação de (Estratégia de Serviço) Uma abordagem para a criação de uma

preocupações solução ou serviço de TI que divide o problema em partes que podem
ser resolvidos de forma independente. Essa abordagem separa "o
que" está a ser feito a partir de "como" é para ser feito.
Servidor (Operação de Serviço) Um computador que esteja conectado a uma

rede e fornece funções de software que são utilizados por outros
computadores.
Serviço Um meio de entregar valor aos clientes, facilitando Resultados clientes

querem alcançar, sem a posse de Custos e riscos específicos.
Critérios de aceitação (Transição de Serviço) Um conjunto de critérios utilizados para garantir

de serviços que um serviço de TI cumpre a sua funcionalidade e requisitos de
qualidade e que o provedor de serviço de TI está pronta para operar o
serviço de TI novo quando foi implantado. Veja também Aceitação.
Serviço de ativos Qualquer capacidade ou recurso de um Provedor de serviços. Veja

também Ativos.
Gerenciamento da (Desenho de Serviço) (Melhoria de Serviço Continuada) A Atividade

Capacidade de responsável por entender o desempenho ea capacidade de serviços
serviço de TI. Os recursos usados por cada Serviço de TI e o padrão de uso

ao longo do tempo são coletados, registrados e analisados para uso
no Plano de Capacidade. Veja também Negócios Capacidade,
Gerenciamento de Capacidade de componentes.
Catálogo de Serviços (Desenho de Serviço) Um banco de dados de documentos ou

estruturado com informações sobre todos os serviços de TI ao vivo,
incluindo os disponíveis para a implantação. O Catálogo de Serviços é
a única parte do portfólio de serviços publicado aos Clientes, e é
usado para apoiar a venda e entrega de serviços de TI. O Catálogo de
Serviço inclui informações sobre entregas, preços, pontos de contacto,
ordenação e processos de solicitação.
Gestão da Veja TI Gestão da Continuidade do Serviço.

Continuidade do
Serviço
Cultura de serviço Uma cultura orientada ao cliente. Os principais objectivos de uma

cultura de serviço são a satisfação do cliente e ajudando os clientes a
atingir seus objetivos de negócios.
Design de Serviços (Desenho de Serviço) Uma fase no Ciclo de Vida de um Serviço de TI.
Design de Serviços inclui uma série de processos e funções e é o título
de um dos ITIL Núcleo publicações. Veja também Design.
Pacote de Desenho (Desenho de Serviço) documento (s) a definição de todos os aspectos

de Serviço de um serviço de TI e seus requisitos através de cada estágio de seu
ciclo de vida. Um Pacote de Desenho de Serviço é produzido para
cada Serviço de TI novo, grande mudança, ou TI Aposentadoria
Serviço.
Service Desk (Operação de Serviço) O ponto único de contato entre o prestador de

serviços e os usuários. Uma Central de Serviços típico gerencia
incidentes e solicitações de serviços, e também lida com a
comunicação com os usuários.
Análise de falha de (Desenho de Serviço) Uma Atividade que identifica as causas

serviço subjacentes de uma ou mais interrupções do serviço de TI. SFA
identifica oportunidades para melhorar os processos de o prestador de
serviços de TI e ferramentas, e não apenas a infraestrutura de TI. SFA
é um tempo limitado, a atividade de projeto semelhante, em vez de um
processo contínuo de análise.
Horas de serviço (Desenho de Serviço) (Melhoria de Serviço Continuada) Um período

de tempo acordado quando um determinado serviço de TI deve estar
disponível. Por exemplo, 'Segunda-feira a Sexta-feira 8:00-17:00,
exceto feriados. Horas de serviço devem ser definidos em um Acordo
de Nível de Serviço.
Plano de Melhoria de (Melhoria de Serviço Continuada) um plano formal para implementar

Serviço melhorias a um processo ou serviço de TI.
Serviço do Sistema (Transição de Serviço) Um conjunto de ferramentas e bases de dados

de Gestão do que são usados para gerenciar conhecimento e informação. Os SKMS
Conhecimento inclui o Sistema de Gerenciamento de Configuração, bem como outras
ferramentas e bancos de dados. O lojas SKMS, gerencia as
atualizações, e apresenta todas as informações de que um provedor

de serviço de TI precisa gerenciar o ciclo de vida completo de serviços
de TI.
Nível de serviço Medido e relatado conquista contra um ou mais objetivos de nível de

serviço. O nível de serviço termo é por vezes usado informalmente
para significar objetivo de nível de serviço.
Acordo de Nível de (Desenho de Serviço) (Melhoria de Serviço Continuada) um acordo

Serviço entre um provedor de serviços de TI e um Cliente. O SLA descreve o
serviço de TI, objetivos de nível de documentos de serviço, e
especifica as responsabilidades do fornecedor de serviços de TI eo
cliente. Uma única SLA pode abranger vários serviços de TI ou
clientes múltiplos. Veja Acordo de Nível Operacional também.
Gerenciamento de (Desenho de Serviço) (Melhoria de Serviço Continuada) O Processo

Nível de Serviço responsável por negociar Acordos de Nível de Serviço, e garantir que
estes sejam cumpridos. SLM é responsável por garantir que todos os
processos de TI Service Management, Acordos de Nível Operacional e
Contratos de Apoio, são adequadas para os objetivos de nível de
serviço acordado. SLM monitores e relatórios sobre os níveis de
serviço, e mantém Opiniões regulares.
Pacote de Nível de (Estratégia de Serviço) Um nível definido de Utilidade e Garantia para

Serviço um pacote de serviços específico. Cada SLP é projetado para atender
as necessidades de um padrão particular de atividade empresarial.
Veja também Linha de Serviço.
Exigência de Nível de (Desenho de Serviço) (Melhoria de Serviço Continuada) uma exigência

Serviço do cliente para um aspecto de um Serviço de TI. SLRs são baseados
em objetivos de negócios e são usados para negociar objetivos de
nível de serviço acordado.
Meta de nível de (Desenho de Serviço) (Melhoria de Serviço Continuada) Um

serviço compromisso que é documentado em um Acordo de Nível de Serviço.
Metas de nível de serviço são baseados em Requisitos de Nível de
Serviço, e são necessárias para garantir que o Design de Serviços de
TI está apto para o efeito. Metas de nível de serviço devem ser
SMART, e normalmente são baseados em KPIs.
Serviço de Gestão de Service Management é um conjunto de capacidades especializadas

organizacionais para o valor aos clientes na forma de serviços.
Serviço de Gestão de Uma abordagem para IT Service Management, que enfatiza a

ciclo de vida importância da coordenação e controle em diversas funções,
processos e sistemas necessários para gerenciar o ciclo de vida de
serviços de TI. O Serviço de Gerenciamento abordagem de ciclo de
vida considera que a estratégia, projeto, transição, operação e
melhoria contínua dos serviços de TI.
Service Manager Um gestor que é responsável por gerenciar o ciclo de vida de ponta a
ponta de um ou mais serviços de TI. O Gerenciador de Serviços termo
também é usado para significar qualquer gestor dentro do provedor de
serviço de TI. Mais comumente usado para se referir a um Gerente de
Relacionamento de Negócios, Gerente de Processos, Gerente de
Contas ou um gerente sênior com a responsabilidade de Serviços de
TI em geral.

Operação de Serviço (Operação de Serviço) Uma fase no Ciclo de Vida de um Serviço de
TI. Operação de Serviço inclui uma série de processos e funções e é o
título de um dos ITIL Núcleo publicações. Veja também Operação.
Proprietário do (Melhoria de Serviço Continuada) um papel que é responsável pela

serviço entrega de um serviço de TI específica.
Portfólio de Serviços (Estratégia de Serviço) O conjunto completo de serviços que são

gerenciados por um provedor de serviço. O portfólio de serviços é
usado para gerenciar o ciclo de vida de todos os Serviços, e inclui três
categorias: Serviço de Pipeline (proposto ou em desenvolvimento);
Catálogo de Serviço (Live ou disponíveis para implantação) e Serviços
de aposentados. Ver também Gestão de Portfólio de Serviços.
Gestão de Portfólio (Estratégia de Serviço) O Processo responsável por gerenciar o

de Serviços portfólio de serviços. Gestão de Portfólio de Serviço considera
Serviços em termos de valor de negócios que eles proporcionam.
Provedor de serviços (Estratégia de Serviço) Uma Organização prestação de serviços a um

ou mais clientes internos ou clientes externos. Prestador de serviço é
muitas vezes usada como uma abreviação para a TI do provedor de
serviço.
Serviço de relatório (Melhoria de Serviço Continuada) O Processo responsável pela

produção e entrega de relatórios de desempenho e as tendências em
relação aos níveis de serviço. Relatórios de serviço deve concordar o
formato, conteúdo e frequência dos relatórios com os Clientes.
Solicitação de serviço (Operação de Serviço) Um pedido de um usuário para obter

informações ou conselhos, ou para uma mudança de padrão ou de
acesso a um serviço de TI. Por exemplo, para redefinir uma senha, ou
a prestação de serviços de TI padrão para um novo usuário.
Solicitações de serviços são geralmente tratado por um Service Desk,
e não necessitam de uma RFC para ser apresentado. Veja também
Pedir Cumprimento.
Estratégia de Serviço (Estratégia de Serviço) O título de um dos ITIL Núcleo publicações.

Estratégia de serviço estabelece uma estratégia global de serviços de
TI e de IT Service Management.
Transição de Serviço (Transição de Serviço) Uma fase no Ciclo de Vida de um Serviço de

TI. Transição de Serviço inclui uma série de processos e funções e é o
título de um dos ITIL Núcleo publicações. Ver também Transição.
Garantia de serviço (Estratégia de Serviço) Garantia de que um serviço de TI irá atender

aos requisitos acordados. Este pode ser um acordo formal, como um
Acordo de Nível de Serviço ou Contrato, ou pode ser uma mensagem
de marketing ou imagem de marca. O valor de negócio de um Serviço
de TI é criado pela combinação de Service Utility (o que o serviço faz)
e garantia de serviço (como ele faz isso). Ver também Garantia.
Manutenção (Desenho de Serviço) (Melhoria de Serviço Continuada) A capacidade

de um terceiro fornecedor de cumprir os termos de seu contrato. Este
Contrato incluirá os níveis acordados de Confiabilidade
Sustentabilidade, ou disponibilidade para um item de configuração.

Deslocar (Operação de Serviço) Um grupo ou equipe de pessoas que realizam
uma função específica, por um período fixo de tempo. Por exemplo,
poderia haver quatro turnos de Operações de TI controle de pessoal
para suportar um serviço de TI que é usado 24 horas por dia.
Modelagem, (Desenho de Serviço) (Melhoria de Serviço Continuada) Uma técnica

simulação que cria um modelo detalhado para prever o comportamento de um
item de configuração ou serviço de TI. Modelos de simulação podem
ser muito precisos, mas são caro e demorado para criar. Um modelo
de simulação é muitas vezes criado usando os itens de configuração
reais que estão sendo modelados, com cargas de trabalho artificiais ou
transações. Eles são usados em Gestão de Capacidade quando
resultados precisos são importantes. Um modelo de simulação é às
vezes chamado de Referência de Desempenho.
Ponto único de falha (Desenho de Serviço) qualquer item de configuração que pode causar
um incidente quando falha, e para os quais uma contramedida não foi
implementado. A SPOF pode ser uma pessoa, ou um passo em um
processo ou atividade, bem como um componente da infra-estrutura
de TI. Veja também falha.
A SMART (Desenho de Serviço) (Melhoria de Serviço Continuada) Um acrônimo

para ajudar a lembrar que os objectivos em Acordos de Nível de
Serviço e Planos de projeto devem ser específicos, mensuráveis,
atingíveis, relevantes e oportunas.
Especificação Uma definição formal de Requisitos. A especificação pode ser usada

para definir os requisitos técnicos e operacionais, e pode ser interna ou
externa. Muitas normas públicas consistem de um Código de Prática e
uma Especificação. A especificação define o padrão contra o qual uma
organização pode ser auditado.
Stakeholder Todas as pessoas que têm interesse em uma Organização do Projeto,

Serviços de TI, etc Stakeholders pode estar interessado nas
atividades, metas, recursos, ou entregas. As partes interessadas
podem incluir clientes, parceiros, funcionários, acionistas, proprietários,
etc Veja também RACI.
Padrão Um requisito obrigatório. Exemplos incluem ISO / IEC 20000 (um

padrão internacional), um padrão de segurança interna para a
configuração do Unix, ou um padrão do governo para saber como
registros financeiros devem ser mantidos. O Standard termo também é
usado para se referir a um Código de Prática ou Especificação
publicado por uma organização de padrões como ISO ou BSI. Veja
também orientação.
Espera (Desenho de Serviço) Usado para se referir a recursos que não são
necessários para entregar os serviços de TI ao vivo, mas estão
disponíveis para apoiar TI Planos de Continuidade de Serviço. Por
exemplo, um centro de dados de espera pode ser mantido para apoiar
Hot Standby, espera aquecido ou frio arranjos de espera.
Declaração de (Desenho de Serviço) Um documento contendo todas as exigências

requisitos para a compra do produto, ou um novo ou alterado Serviço de TI. Ver
também Termos de referência.

Estado O nome de um campo obrigatório em muitos tipos de Record. Ele
mostra o estágio atual do ciclo de vida do item de configuração
associado, incidentes, problemas, etc
Estratégico (Estratégia de Serviço) O mais alto dos três níveis de Planejamento e

de entrega (Estratégico, Tático, Operacional). Atividades Estratégicas
incluem definição de objetivo e planejamento de longo prazo para
alcançar a visão global.
Estratégia (Estratégia de Serviço) Um Plano Estratégico concebido para alcançar

objetivos definidos.
Fornecedor (Estratégia de Serviço) (Desenho de Serviço) um terceiro responsável

pelo fornecimento de bens ou serviços que são necessários para
entregar serviços de TI. Exemplos de fornecedores incluem hardware
commodity e fornecedores de software, rede e provedores de
telecomunicações e Organizações de terceirização. Ver também
Subjacente Contrato,Cadeia de suprimentos.
Fornecedor e Banco (Desenho de Serviço) Um banco de dados de documentos ou

de Dados Contrato estruturado usado para gerenciar contratos de fornecedores ao longo
do seu ciclo de vida. O SCD contém atributos-chave de todos os
contratos com fornecedores, e devem fazer parte do Sistema de
Gerenciamento de Serviços de Conhecimento.
Gestão de (Desenho de Serviço) O Processo responsável por garantir que todos

Fornecedores os contratos com fornecedores de suportar as necessidades do
negócio, e que todos os fornecedores cumpram os seus compromissos
contratuais.
Cadeia de (Estratégia de Serviço) As Atividades em uma Cadeia de Valor

suprimentos realizado por Fornecedores. Uma cadeia de suprimentos normalmente
envolve vários fornecedores, cada um agregando valor ao produto ou
serviço. Ver também Rede de Valor.
Grupo de apoio (Operação de Serviço) Um grupo de pessoas com habilidades

técnicas. Os grupos de apoio fornecer o apoio técnico necessário a
todos os Processos de Gestão de Serviços de TI. Ver também Gestão
técnica.
Horas de suporte (Desenho de Serviço) (Operação de Serviço) Os tempos ou horas,

quando o apoio está disponível para os usuários. Normalmente estas
são as horas em que o Service Desk está disponível. Horas de suporte
devem ser definidos em um Acordo de Nível de Serviço, e pode ser
diferente da hora de serviço. Por exemplo, as horas de serviço pode
ser de 24 horas por dia, mas as horas de suporte podem ser 7:00-
19:00.
Serviços de apoio (Estratégia de Serviço) um serviço que permite ou melhora um serviço

essencial. Por exemplo, um serviço de diretório ou um serviço de
backup.
A análise SWOT (Melhoria de Serviço Continuada) Uma técnica que analisa e analisa
os pontos fortes e fraquezas internas de uma organização e as
oportunidades e ameaças externas que enfrenta SWOT significa
Forças, Fraquezas, Oportunidades e Ameaças.

Sistema Uma série de coisas relacionadas que trabalham em conjunto para
alcançar um objetivo global. Por exemplo:
• Um sistema de computador, incluindo

hardware, software e aplicativos
• Um sistema de gestão, incluindo vários
processos que são planejados e gerenciados
em conjunto. Por exemplo, um Sistema de
Gestão da Qualidade
• Um Sistema de Gerenciamento de Banco de
Dados ou Sistema Operacional que inclui
módulos de software que são projetados para
realizar um conjunto de funções relacionadas.
Sistema de Gestão de A parte da IT Service Management que se concentra na gestão de

infraestrutura de TI ao invés de processo.
Tático O meio de três níveis de Planejamento e de entrega (Estratégico,

Tático, Operacional). Atividades táticas incluem os planos de médio
prazo necessários para atingir objetivos específicos, normalmente
durante um período de semanas a meses.
Gestão técnica (Operação de Serviço) A Função responsável por fornecer

competências técnicas de apoio de serviços de TI e gestão da infra-
estrutura de TI. Gestão técnica define os papéis dos grupos de apoio,
bem como as ferramentas, processos e procedimentos necessários.
Serviço técnico Veja Serviço de Infra-estrutura.
Suporte técnico Ver Gestão técnica.
Termos de referência (Desenho de Serviço) Um documento especificando os requisitos,

escopo, entregas, Recursos e cronograma para um projeto ou
atividade.
Teste (Transição de Serviço) Uma Atividade que verifica se um item de

configuração, serviço, processo, etc cumpre a sua Especificação
Requisitos ou acordado. Veja também Aceitação.
Terceiro Uma pessoa, grupo ou empresa que não faz parte do Acordo de Nível
de Serviço para um serviço de TI, mas é necessário para garantir a
entrega bem sucedida do Serviço de TI. Por exemplo, um fornecedor
de software, uma empresa de manutenção de hardware, ou um
departamento de instalações. Requisitos para terceiros são
normalmente especificada na sustentação Contratos ou Acordos de
Nível Operacional.
Terceira linha de (Operação de Serviço) O terceiro nível em uma hierarquia de grupos

apoio de apoio envolvidos na resolução de incidentes e investigação de
problemas. Cada nível contém habilidades mais especializadas, ou
tem mais tempo ou outros recursos.
Ameaça Qualquer coisa que possa explorar uma vulnerabilidade. Qualquer

causa potencial de um incidente pode ser considerado uma ameaça.
Por exemplo, um incêndio é uma ameaça que pode explorar a

vulnerabilidade de revestimentos inflamáveis. Este termo é comumente
usado em Gestão de Segurança da Informação e Gerenciamento de
Continuidade do Serviço, mas também se aplica a outras áreas, como
Problema e Gerenciamento de Disponibilidade.
Limiar O valor de uma métrica que deve causar um alerta a ser gerado, ou de
gestão a adoptar. Por exemplo "Incidente Prioridade 1 não resolvido
em quatro horas", "mais de cinco erros de disco moles em uma hora",
ou "mais de 10 mudanças não em um mês.
Vazão (Desenho de Serviço) Uma medida do número de transações, ou

outras operações, realizadas em um tempo fixo. Por exemplo, 5.000 e-
mails enviados por hora, ou 200 de disco I / Os por segundo.
Custo Total de (Estratégia de Serviço) Uma metodologia usada para ajudar a tomar
Propriedade decisões de investimento. TCO avalia o Custo do Ciclo de Vida cheia
de possuir um item de configuração, não apenas o custo inicial ou
preço de compra.
Transação Uma função discreta realizada por um serviço de TI. Por exemplo
transferir dinheiro de uma conta bancária para outra. Uma única
operação pode envolver inúmeros acréscimos, supressões e
modificações de dados. Ou todos estes completo com êxito ou
nenhuma delas é realizada.
Transição (Transição de Serviço) Uma mudança no estado, o que corresponde a

um movimento de um serviço de TI ou Item de Configuração de um
outro estado de Ciclo de Vida para a próxima.
Análise de tendências (Melhoria de Serviço Continuada) Análise de dados para identificar

padrões relacionados com o tempo. Análise de tendências é usado em
Gerenciamento de Problema para identificar falhas comuns ou itens de
configuração frágeis, e em Gerenciamento da Capacidade como uma
ferramenta de modelagem para prever o comportamento futuro. Ele
também é usado como uma ferramenta de gestão para identificação
de deficiências nos processos de Gerenciamento de Serviços.
Afinação A Atividade responsável por planejar mudanças para tornar o uso mais
eficiente dos recursos. Tuning é parte de Gestão de Desempenho, que
também inclui o monitoramento de desempenho e implementação das
mudanças necessárias.
Subjacente Contrato (Desenho de Serviço) um contrato entre um fornecedor de serviços de

TI e um terceiro. O terceiro fornecer bens ou serviços que suportam a
entrega de um serviço a um cliente. O Contrato Subjacente define
metas e responsabilidades que são necessárias para cumprir as metas
de serviço acordado em um nível SLA.
Urgência (Transição de Serviço) (Desenho de Serviço) Uma medida de quanto

tempo será até que um incidente, problema ou mudança tem um
impacto significativo sobre o negócio. Por exemplo, um incidente de
alto impacto podem ter Urgência baixo, se o impacto não afetará o
negócio até o final do exercício financeiro. Impacto e Urgência são
usados para atribuir prioridade.
Usabilidade (Desenho de Serviço) A facilidade com que um aplicativo, produto, ou

serviço de TI pode ser utilizada. Requisitos de Usabilidade são
freqüentemente incluídos em uma declaração de requisitos.
Caso de Uso (Desenho de Serviço) Uma técnica usada para definir funcionalidade e
objectivos, e para projetar testes. Casos de Uso definir cenários
realistas que descrevem as interações entre usuários e um serviço de
TI ou outro sistema.
Usuário Uma pessoa que usa o serviço de TI em uma base dia-a-dia. Usuários
são distintos de clientes, como alguns clientes não usar o serviço
diretamente.
Utilidade (Estratégia de Serviço) Funcionalidade oferecida por um produto ou

serviço para atender a uma necessidade específica. Utilidade é muitas
vezes resumido como "o que ele faz".
Validação (Transição de Serviço) Uma Atividade que garante um novo ou

alterado Serviço de TI, Processo, Plano, ou Deliverable outro atende
às necessidades do negócio. A validação garante que Requisitos de
Negócio são atendidas mesmo que estes podem ter mudado desde
que o projeto original. Ver também Verificação, Aceitação.
Cadeia de Valor (Estratégia de Serviço) Uma sequência de processos que cria um

produto ou serviço que é de valor para um cliente. Cada passo da
sequência baseia-se nas etapas anteriores e contribui para o produto
final, ou de serviço. Ver também Rede de Valor.
Value for Money Uma medida informal de rentabilidade. Custo-benefício é muitas vezes
baseada em uma comparação com o custo de alternativas. Veja
também Análise de Custo-Benefício.
Rede de Valor (Estratégia de Serviço) Um conjunto complexo de relações entre dois

ou mais grupos ou organizações. Valor é gerado por meio do
intercâmbio de conhecimentos, informações, produtos ou serviços. Ver
também Cadeia de Valor, Parceria.
Variação A diferença entre o valor previsto e o valor real medido. Comumente

usado em Gestão Financeira, Gestão de Capacidade e Gerenciamento
de Nível de Serviço, mas pode ser aplicável em qualquer área onde os
planos estão no lugar.
Verificação (Transição de Serviço) Uma Atividade que garante um novo ou

alterado Serviço de TI, Processo, Plano, ou qualquer outra prestação é
completa, precisa, confiável e corresponde ao seu projeto
especificação. Ver também Validação, Aceitação.
Versão (Transição de Serviço) Uma versão é utilizado para identificar uma

linha de base específica de um item de configuração. Versões
tipicamente usam uma convenção de nomeação que permite a
seqüência ou data de cada linha de base a ser identificado. Por
exemplo folha de pagamento 3 Versão aplicativo contém
funcionalidade atualizada a partir da versão 2.
Visão Uma descrição do que a Organização pretende tornar-se no futuro.

Uma visão é criado pela alta administração e é usado para ajudar
Cultura influência e Planejamento Estratégico.

Função de Negócios (Desenho de Serviço) uma função de um processo de negócio que é
Vital fundamental para o sucesso do negócio. Funções vitais para os
negócios são uma consideração importante de Gestão de
Continuidade de Negócios, Gerenciamento da Continuidade de
Serviço e Gerenciamento de Disponibilidade.
Vulnerabilidade Uma fraqueza que pode ser explorada por uma ameaça. Por exemplo,
uma porta de firewall aberto, uma senha que nunca é alterado, ou um
tapete inflamável. A falta de controle também é considerado uma
vulnerabilidade.
Espera quente Veja Recuperação Intermediário.
Garantia (Estratégia de Serviço) Uma promessa ou garantia de que um produto

ou serviço irá satisfazer os seus requisitos acordados. Ver também
Garantia de serviço.
Instrução de Trabalho Um documento contendo instruções detalhadas que especificam

exatamente o que os passos a seguir para realizar uma atividade. A
Instrução de Trabalho contém muito mais detalhes do que um
Procedimento e é criada apenas se instruções muito detalhadas são
necessárias.
Solução (Operação de Serviço) Reduzir ou eliminar o impacto de um incidente

ou problema para o qual uma resolução completa ainda não está
disponível. Por exemplo, reiniciando um item de configuração falhou.
Soluções alternativas para problemas são documentadas em registros
de erro conhecidas. Soluções alternativas para a incidentes que não
têm registros de problemas associados estão documentadas no
registro de incidentes.
Workload Os recursos necessários para entregar uma parte identificável de um

Serviço de TI. Cargas de trabalho podem ser classificados por
usuários, grupos de usuários, ou funções no âmbito do Serviço de TI.
Isto é usado para auxiliar na análise e gestão do desempenho,
capacidade e utilização de itens de configuração e serviços de TI. A
carga de trabalho termo é usado às vezes como sinônimo de
throughput.

004 ITIL V3 Operacao de Servico PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

004 ITIL V3 Operacao de Servico PDF

Enviado por

Direitos autorais:

Formatos disponíveis

ITIL Versão 3

ITIL V3 - Operação de Serviço - Página: 1 de 423

ITIL V3 - Operação de Serviço - Página: 2 de 423

ITIL V3 - Operação de Serviço - Página: 3 de 423

ITIL V3 - Operação de Serviço - Página: 4 de 423

ITIL V3 - Operação de Serviço - Página: 5 de 423

ITIL V3 - Operação de Serviço - Página: 6 de 423

ITIL V3 - Operação de Serviço - Página: 7 de 423

ITIL V3 - Operação de Serviço - Página: 8 de 423

ITIL V3 - Operação de Serviço - Página: 9 de 423

ITIL V3 - Operação de Serviço - Página: 10 de 423

ITIL V3 - Operação de Serviço - Página: 11 de 423

Esta é uma das cinco publicações principais que descrevem as práticas de

Se você faz parte de uma empresa global, um departamento ou uma pequena

Office of Government Commerce

ITIL V3 - Operação de Serviço - Página: 12 de 423

A publicação traz Operação de Serviço Gerenciamento de Serviços de vida para

Esta publicação vai ajudar a orientar-nos a todos para alcançar a excelência do

Há um ditado que diz que a aprendizagem é 20/20. A orientação na Operação

Qualquer pessoa envolvida em serviços de operação irá beneficiar da orientação

Arquiteto Chefe, Práticas ITIL Service Management

ITIL V3 - Operação de Serviço - Página: 13 de 423

Os princípios básicos de boas práticas de serviços de TI de gestão enquadrada

No entanto, as tecnologias, ferramentas e relações mudaram significativamente,

Se você gostaria de nos informar de quaisquer alterações que possam ser

Para mais informações sobre qualificação e acreditação da formação, visite

APMG Service Desk

Tel: +44 (0) 1494 452450

ITIL V3 - Operação de Serviço - Página: 14 de 423

Sharon Taylor (Aspect Group Inc) Arquiteto Chefe

ITIL autoria da equipe

Os autores também gostariam de agradecer a Stuart Rance e Ashley Hanna, da Hewlett-

ITIL V3 - Operação de Serviço - Página: 15 de 423

O ITIL Grupo Consultivo

ITIL V3 - Operação de Serviço - Página: 16 de 423

O advento de novas tecnologias e as linhas ténues entre agora os silos de

Estas alternativas têm levado a uma miríade de relações de negócios de TI,

ITIL V3 - Operação de Serviço - Página: 17 de 423

Processos bem planejados e implementados será em vão se a operação do dia-

Operação equipe de serviço deve dispor de processos e ferramentas de apoio

Dado que os serviços podem ser fornecidos, no todo ou em parte, por um ou

Operação de Serviço não é nem uma unidade organizacional nem um único

ITIL V3 - Operação de Serviço - Página: 18 de 423

1.2.1 Gestão de Serviços

TI é um termo comumente utilizado que muda de significado com o contexto. A

A partir da terceira perspectiva, é uma categoria dos serviços utilizados pelas

1.2.2 Boas práticas no domínio público

Organizações operar em ambientes dinâmicos com a necessidade de aprender

Para lidar com a pressão, organizações referência se contra colegas e procurar

ITIL V3 - Operação de Serviço - Página: 19 de 423

Estruturas públicas e as normas são atraentes quando comparados com

• Conhecimento proprietário, está profundamente enraizado nas

ITIL V3 - Operação de Serviço - Página: 20 de 423

1.2.3 ITIL e boas práticas em Gestão de Serviços

A Biblioteca ITIL tem o seguinte componentes:

• ITIL Core: melhores práticas de orientação aplicável a todos os tipos de

ITIL V3 - Operação de Serviço - Página: 21 de 423

Cada publicação aborda as capacidades que têm impacto direto sobre um

A orientação em ITIL pode ser adaptado para as mudanças de uso em vários

ITIL V3 - Operação de Serviço - Página: 22 de 423

O Estratégia de Serviço volume fornece orientação sobre como projeto,

Organizações usam a orientação para definir objetivos e expectativas de

1.2.3.2 Design de Serviços