Itil v3 transição de serviço

ITIL Versão 3
Transição de Serviço
ITIL V3 - Transição de Serviço - Página: 1 de 424

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.

I N D I C E
Prefácio .............................................................................................................12
Prefácio da OGC........................................................................................................... 12
Prefaciar............................................................................................................16
Informações de contato ................................................................................................ 17
Agradecimentos.................................................................................................18
Arquiteto-chefe e autores ............................................................................................. 18
ITIL autoria da equipe................................................................................................... 18
Mentores ....................................................................................................................... 18
Outras contribuições..................................................................................................... 18
O ITIL Grupo Consultivo..................................................................................................19
Revisores.........................................................................................................................19
1 Introdução ......................................................................................................20
1.1 Visão Geral ............................................................................................................. 21
1,2 Contexto.................................................................................................................. 23
1.2.1 Gestão de Serviços ................................................................................................23
1.2.2 Boas práticas no domínio público...........................................................................23
1.2.3 ITIL e boas práticas em Gestão de Serviços ..........................................................25
1.2.3.1 Estratégia de Serviço.................................................................................................. 26
1.2.3.2 Design de Serviços..................................................................................................... 27
1.2.3.3 Transição de Serviço .................................................................................................. 27
1.2.3.4 Operação de Serviço .................................................................................................. 28
1.2.3.5 Melhoria de Serviço Continuada.................................................................................. 28
1,3 objetivo e escopo de Transição de Serviço ........................................................... 29
1.3.1 Meta........................................................................................................................29
1.3.2 Âmbito ....................................................................................................................29
1,4 Uso.......................................................................................................................... 31
1.4.1 Público-alvo ............................................................................................................31
1.4.2 Benefícios desta publicação...................................................................................31
Capítulo 2 - Gerenciamento de Serviços como uma prática .................................................... 32
Capítulo 3 - Princípios Transição de Serviço........................................................................... 32
Capítulo 4 - processos de transição de serviços...................................................................... 32
Capítulo 5 - Transição de Serviço atividades de operação comuns ......................................... 33
Capítulo 6 - Organizador Transição de Serviço....................................................................... 33
Capítulo 7 - Considerações de serviços de tecnologia de transição......................................... 33
Capítulo 8 - Transição de Serviço Implementação .................................................................. 33
Capítulo 9 - Desafios, fatores críticos de sucesso e riscos ...................................................... 33
Posfácio ................................................................................................................................. 33
Apêndice A: Descrição dos tipos de ativos.............................................................................. 33
2 Gerenciamento de Serviço como uma prática ................................................34
2.1 O que é Gerenciamento de Serviços?................................................................... 34
2.2 O que são serviços?............................................................................................... 36
2.2.1 O valor proposição..................................................................................................36
2.3 Funções e processos em todo o ciclo de vida....................................................... 37
2.3.1 Funções..................................................................................................................37
2.3.2 Processos...............................................................................................................37
2.3.3 Especialização e coordenação em todo o ciclo de vida..........................................38
2,4 Transição fundamentos Serviço............................................................................. 39
2.4.1 Objetivo, metas e objetivos.....................................................................................39
2.4.2 Âmbito ....................................................................................................................40
2.4.3 Valor para os negócios...........................................................................................42
2.4.4 Otimização do desempenho Transição de Serviço.................................................42

2.4.4.1 Medidas para o alinhamento com o negócio e planeja................................................. 42
2.4.4.2 Medidas de Transição de Serviço................................................................................ 43
2.4.5 Interfaces para estágios do ciclo de vida de serviços de outros.............................44
2.4.5.1 Entradas para a Transição de Serviço......................................................................... 44
2.4.5.2 Saídas de Transição de Serviço.................................................................................. 45
2.4.6 Processos dentro de Transição de Serviço ............................................................46
2.4.6.1 Processos que suportam o ciclo de vida do serviço..................................................... 46
2.4.6.2 Processos dentro de Transição de Serviço.................................................................. 46
3 Transição princípios do serviço ......................................................................46
3.1 Princípios de Transição serviço de apoio .............................................................. 48
3.1.1 Definir um serviço...................................................................................................48
3.1.2 utilitários de serviços e garantias............................................................................49
3.2 Políticas de Transição de Serviço.......................................................................... 51
3.2.1 Definir e implementar uma política formal de Transição de Serviço.......................51
3.2.2 Implementar todas as alterações aos serviços através de Transição de Serviço...51
3.2.3 Adoptar um quadro comum e normas ....................................................................53
3.2.4 Maximizar a reutilização de processos e sistemas consagrados............................53
3.2.5 Alinhar os planos de transição de serviços com as necessidades do negócio.......54
3.2.6 Estabelecer e manter relações com as partes interessadas ..................................55
3.2.7 Estabelecer controles eficazes e disciplinas...........................................................56
3.2.8 Oferecer sistemas de transferência de conhecimento e apoio à decisão...............57
3.2.9 Plano de liberação e implantação de pacotes ........................................................58
3.2.10 Antecipar e gerenciar correções de curso ............................................................59
Correções de curso.....................................................................................................................................59
3.2.11 proativamente gerenciar recursos através Transitions Serviço ............................60
3.2.12 garantir a participação precoce no ciclo de vida do serviço..................................61
3.2.13 Garantir a qualidade do serviço novo ou alterado ................................................62
3.2.14 proativamente melhorar a qualidade durante a Transição de Serviço..................63
4 de Transição de Serviço processos................................................................65
4.1 Planejamento de Transição e Suporte................................................................... 66
4.1.1 Finalidade, objetivos e metas .................................................................................66
4.1.2 Âmbito ....................................................................................................................66
4.1.4 Políticas, princípios e conceitos básicos.................................................................67
4.1.4.1 política de Transição de Serviço.................................................................................. 67
4.1.4.2 política de Lançamento ............................................................................................... 68
4.1.5 as atividades de processo, métodos e técnicas......................................................72
4.1.5.1 estratégia de transição................................................................................................ 72
Serviço estágios do ciclo de vida de transição...........................................................................................73
4.1.5.2 Prepare-se para a Transição de Serviço...................................................................... 74
4.1.5.3 Planejamento e coordenação Transição de Serviço .................................................... 74
Planejamento de um indivíduo Transição de Serviço ................................................................................74
Planejamento integrado..............................................................................................................................75
Adotar programas e práticas de projeto de manejo ...................................................................................76
Revisão dos planos de................................................................................................................................76
Antecipando circunstâncias de negócios alterados....................................................................................77
4.1.6 Fornecer suporte ao processo de transição ...........................................................78
4.1.6.1 Orientação.................................................................................................................. 78
4.1.6.2 Administração............................................................................................................. 78
4.1.6.3 monitoramento e geração de relatórios de progresso .................................................. 78
4.1.7 Triggers interfaces de entrada e saída, e entre processos.....................................79
4.1.8 Principais indicadores de desempenho e métricas.................................................79
4.2 Gestão de Mudança ............................................................................................... 81
4.2.1 Finalidade, objetivos e metas .................................................................................81
4.2.2 Âmbito ....................................................................................................................82
Mudança de serviço....................................................................................................................................82
Exclusões....................................................................................................................................................83

Exemplo de serviço de TI iniciou a mudança em negócios .......................................................................84
4.2.4 Políticas, princípios e conceitos básicos.................................................................86
4.2.4.1 Políticas...................................................................................................................... 86
4.2.4.2 Design e considerações de planejamento ................................................................... 87
4.2.4.3 Tipos de solicitação de mudança................................................................................. 88
4.2.4.4 Mudança de modelos de processos e fluxos de trabalho............................................. 90
4.2.4.5 Mudanças padrão (pré-autorizado).............................................................................. 90
4.2.5 planejamento Remediação.....................................................................................91
4.2.6 as atividades de processo, métodos e técnicas......................................................92
4.2.6.1 Procedimento de mudança normal.............................................................................. 96
4.2.6.2 Criar e registrar pedidos de mudança.......................................................................... 96
Alterar registro.............................................................................................................................................99
4.2.6.3 analisar a solicitação para a Mudança....................................................................... 100
4.2.6.4 Avaliar e avaliar a mudança ...................................................................................... 100
Os sete Rs de Gestão da Mudança..........................................................................................................100
Nenhuma mudança é sem risco...............................................................................................................102
Classificação dos riscos............................................................................................................................102
Alto risco indústria.....................................................................................................................................103
Avaliação das mudanças..........................................................................................................................103
Atribuição de prioridades ..........................................................................................................................103
Alterar o planejamento e programação ....................................................................................................105
Avaliando remediação ..............................................................................................................................106
4.2.6.5 Autorizar a mudança................................................................................................. 106
4.2.6.6 implementação da mudança de Coordenação........................................................... 108
4.2.6.7 Análise e registro de mudança perto ......................................................................... 108
4.2.6.8 Mudança Conselho Consultivo.................................................................................. 110
Reuniões CAB...........................................................................................................................................111
4.2.6.9 mudanças de emergência......................................................................................... 113
Autorização mudança de emergência ......................................................................................................113
Emergência mudança edifício, teste e implementação............................................................................114
Documentação mudança de emergência.................................................................................................115
4.2.7 Triggers interfaces de entrada e saída, e entre processos...................................116
Mudanças estratégicas.............................................................................................................................116
Mudar para um ou mais serviços..............................................................................................................116
Mudança operacional................................................................................................................................117
Mudanças para entregar a melhoria contínua..........................................................................................117
4.2.7.1 Entradas................................................................................................................... 117
4.2.7.2 Saídas ...................................................................................................................... 118
4.2.7.3 Interfaces.................................................................................................................. 118
Integração com os processos de mudança de negócios .........................................................................118
Programa e gerenciamento de projetos ...................................................................................................119
Terceirização e parcerias..........................................................................................................................119
4.2.7.4 Interfaces no Gerenciamento de Serviços ................................................................. 119
Ativos e Gerenciamento da Configuração................................................................................................120
Gerenciamento de Problemas..................................................................................................................120
Continuidade do Serviço de TI .................................................................................................................120
Gestão de Segurança...............................................................................................................................121
Capacidade e Gestão da Demanda .........................................................................................................121
4.2.8 Principais indicadores de desempenho e métricas...............................................121
4.2.8.1 Exemplos de tipos de medidas para a mudança........................................................ 122
Medidas de saída......................................................................................................................................122
As cargas de trabalho...............................................................................................................................123
Medidas de processo................................................................................................................................123
4,3 Ativo de Serviço e Gerenciamento de Configuração........................................... 124
Objetivo 4.3.1, finalidade e objectivo .............................................................................124
4.3.2 Âmbito ..................................................................................................................124
4.3.3 Valor para os negócios.........................................................................................125
4.3.4 Políticas, princípios e conceitos básicos...............................................................125
4.3.4.1 Ativo de Serviço e políticas de gerenciamento de configuração................................. 126
Ativo de Serviço e os princípios de gerenciamento de configuração.......................................................126
4.3.4.2 Conceitos básicos..................................................................................................... 127
O modelo de configuração........................................................................................................................127
"Dinamarquês relógio '..............................................................................................................................128
Itens de configuração................................................................................................................................128
4.3.4.3 Sistema de Gerenciamento da Configuração............................................................. 129

Exemplo de gestão de bases de dados de configuração múltiplas .........................................................130
Bibliotecas seguras e lojas seguras .........................................................................................................132
A Biblioteca de Mídia Definitiva ................................................................................................................132
Peças definitivas.......................................................................................................................................133
Configuração de referência ......................................................................................................................134
Instantâneo ...............................................................................................................................................134
4.3.5 as atividades de processo, métodos e técnicas....................................................135
4.3.5.1 Ativos e atividades de gerenciamento de configuração.............................................. 135
4.3.5.2 Gestão e planejamento ............................................................................................. 135
Exemplo de conteúdo de ativos e Plano de Gerenciamento de Configuração........................................136
4.3.5.3 identificação da configuração.................................................................................... 137
Estruturas de configuração e seleção de itens de configuração..............................................................138
Fatores que influenciam o nível de gravação de itens de configuração ..................................................140
Nomeando itens de configuração.............................................................................................................141
Rotulagem itens de configuração .............................................................................................................142
Atributos para itens de configuração ........................................................................................................142
Definindo documentação de configuração ...............................................................................................143
Relacionamentos ......................................................................................................................................145
Tipos de item de configuração..................................................................................................................146
Identificação de bibliotecas de mídia........................................................................................................146
Identificação de linhas de base de configuração......................................................................................146
Identificação da unidade de liberação ......................................................................................................148
4.3.5.4 Configuração de controle .......................................................................................... 149
4.3.5.5 Estado de contabilidade e relatórios.......................................................................... 151
Registros...................................................................................................................................................152
Ativos de serviço e relatórios de configuração.........................................................................................152
4.3.5.6 Verificação e auditoria............................................................................................... 153
4.3.6.1 Processo de relacionamentos ................................................................................... 155
4.3.7 Gestão da informação ..........................................................................................155
4.3.9 Desafios, fatores críticos de sucesso e riscos ......................................................157
4,4 Gerenciamento de Liberação e Implantação....................................................... 159
4.4.1 Finalidade, finalidade e objectivo..........................................................................159
4.4.2 Âmbito ..................................................................................................................160
4.4.4.1 Unidade de Lançamento e identificação.................................................................... 160
4.4.4.2 versão opções de design e considerações ................................................................ 161
Vs 'Big Bang' faseada...............................................................................................................................162
Empurrar e puxar ......................................................................................................................................164
Automação vs Manual ..............................................................................................................................165
Projetando pacotes de libertação e liberação ..........................................................................................166
Valiosa de lançamento do Windows..............................................................................168
4.4.4.3 modelos de lançamento e implantação...................................................................... 169
4.4.5.1 Planejamento............................................................................................................ 170
Planos de lançamento e implantação.......................................................................................................170
Aprovação / reprovação critérios..............................................................................................................171
Construir e testar antes da produção .......................................................................................................172
Planejamento pilotos.................................................................................................................................176
Exemplo de necessidade de múltipla pilotagem ......................................................................................178
Planejamento embalagem liberação e construir ......................................................................................178
Planejamento de implantação ..................................................................................................................180
Logística e planejamento de entrega........................................................................................................180
Financeiro / comercial planejamento........................................................................................................181
4.4.5.2 Preparação para construir, testar e implantação........................................................ 182
4.4.5.3 construir e testar ....................................................................................................... 183
Solte e documentação de construção ......................................................................................................184
Adquirir e testar itens de entrada de configuração e componentes.........................................................186
Lançamento embalagem ..........................................................................................................................187
Construir e gerenciar os ambientes de teste............................................................................................188
4.4.5.4 Serviço de testes e pilotos......................................................................................... 189
Ensaios de serviços..................................................................................................................................191
Plano - preparar para o dia.......................................................................................................................192

Não - entregar o ensaio ............................................................................................................................193
Check - documentar o dia.........................................................................................................................193
Agir - agir seguindo o ensaio ....................................................................................................................194
Pilotos .......................................................................................................................................................194
4.4.5.5 Planejar e preparar a implantação............................................................................. 196
Avaliação ............................................................................................................................. 198
Desenvolver planos e se preparar para a implantação .......................................................... 200
4.4.5.6 transferência executar a implantação e reforma ........................................................ 201
Transferir activos financeiros....................................................................................................................201
Transferência / transição e de organização empresarial .........................................................................201
Implantar processos e materiais...............................................................................................................202
Implantar capacidade de gerenciamento de serviços..............................................................................202
Serviço de transferência ...........................................................................................................................203
Implantar serviço.......................................................................................................................................203
Aposentadoria desmantelamento e serviço .............................................................................................203
Remover os ativos redundantes...............................................................................................................204
4.4.5.7 Verifique implantação................................................................................................ 205
4.4.5.8 apoio Início da vida................................................................................................... 205
4.4.5.9 Rever e fechar uma implantação............................................................................... 209
4.4.5.10 Análise e Transição de Serviço próximo.................................................................. 210
4.4.8.1 clientes ou negócios.................................................................................................. 213
4.4.8.2 Os prestadores de serviços....................................................................................... 213
4,5 Serviço de validação e teste................................................................................. 216
4.5.1 Finalidade meta e os objetivos .............................................................................216
4.5.2 Âmbito ..................................................................................................................217
4.5.4.1 Entradas de Design de Serviços ............................................................................... 218
4.5.4.2 A qualidade do serviço e garantia.............................................................................. 221
4.5.4.3 Políticas.................................................................................................................... 222
Política de qualidade de serviço...............................................................................................................222
Política de risco.........................................................................................................................................223
Política de Transição de Serviço ..............................................................................................................223
Política de liberação..................................................................................................................................223
Mudar a política de Gestão.......................................................................................................................223
4.5.4.4 estratégia de teste .................................................................................................... 224
Estratégia de conteúdo de ensaio......................................................................................... 225
4.5.4.5 Modelos de ensaio.................................................................................................... 227
4.5.4.6 Validação e perspectivas de testes ........................................................................... 229
Usuários de negócios e perspectiva do cliente ........................................................................................229
Aceitação (não) Emocional.......................................................................................................................230
Testes de usuário - sistema de aplicação, serviço...................................................................................230
Operações e perspectivas de melhoria de serviço...................................................................................231
4.5.4.7 Níveis de testes e modelos de teste.......................................................................... 231
4.5.4.8 abordagens de teste e técnicas................................................................................. 233
4.5.4.9 Considerações sobre o projeto.................................................................................. 234
4.5.4.10 Tipos de testes........................................................................................................ 237
Necessidades de serviço e testes de estrutura - prestador de serviços, usuários e clientes..................237
Teste de nível de serviço - gerentes de nível de serviço, gerentes de operações e clientes..................238
Garantia e garantia de testes - ajuste para o teste de uso ......................................................................239
Usabilidade - usuários e mantenedores...................................................................................................240
Contrato e testes de regulação.................................................................................................................240
Testes de conformidade ...........................................................................................................................241
Serviço de testes de Gestão.....................................................................................................................241
Testes operacionais - sistemas, serviços.................................................................................................244
Testes de regressão .................................................................................................................................245
1. Validação e gerenciamento de testes................................................................................ 246
2. Plano e projeto de teste.................................................................................................... 247
3. Verifique plano de teste e design de teste......................................................................... 247

4. Prepare ambiente de teste................................................................................................ 247
5. Realizar testes.................................................................................................................. 248
6. Avaliar os critérios de saída e relatório.............................................................................. 249
7. Teste limpeza e fechamento ............................................................................................. 249
4.5.6 interfaces de acionamento de entrada e saídas, e entre processos.....................249
4.5.6.1 Gatilho...................................................................................................................... 249
4.5.6.2 Entradas................................................................................................................... 249
4.5.6.3 Saídas ...................................................................................................................... 250
4.5.6.4 Interfaces para estágios do ciclo de vida de outros.................................................... 251
Os dados de teste.....................................................................................................................................252
Ambientes de teste ...................................................................................................................................252
4.5.8.1 primário (de valor para o negócio / clientes) .............................................................. 253
4.5.8.2 secundário (interno) .................................................................................................. 254
Avaliação 4,6............................................................................................................... 257
4.6.2 Âmbito ..................................................................................................................257
Políticas.....................................................................................................................................................258
Princípios ..................................................................................................................................................258
Conceitos básicos..........................................................................................................258
4.6.5.1 Avaliação termos de serviço...................................................................................... 258
4.6.5.2 Processo de avaliação.............................................................................................. 260
4.6.5.3 Plano de avaliação.................................................................................................... 262
4.6.5.4 Compreender o efeito pretendido de uma mudança .................................................. 262
4.6.5.5 Compreender o efeito não intencional de uma mudança ........................................... 262
4.6.5.6 Fatores para considerar o efeito de uma mudança de serviço ................................... 263
4.6.5.7 Avaliação de desempenho previsto........................................................................... 263
4.6.5.8 Avaliação de desempenho real ................................................................................. 264
4.6.5.9 A gestão de risco ...................................................................................................... 264
Desvios - previu vs desempenho real.......................................................................................................266
Plano de teste e resultados ......................................................................................................................266
4.6.6 Relatório de avaliação ..........................................................................................267
Perfil de risco ............................................................................................................................................267
Desvios denunciar ....................................................................................................................................267
Uma declaração de qualificação (se for o caso) ......................................................................................267
Uma declaração de validação (se for o caso) ..........................................................................................267
Uma recomendação..................................................................................................................................267
4.6.7 Triggers, entradas e saídas e as interfaces entre processos................................268
4.6.9.1 Desafios ................................................................................................................... 268
4,7 Gestão do Conhecimento..................................................................................... 270
4.7.2 Âmbito ..................................................................................................................270
4.7.2.1 Inclusões .................................................................................................................. 271
4.7.2.2 Exclusões ................................................................................................................. 271
4.7.4.1 A estrutura de dados-para-Informação-para-Conhecimento-para-Sabedoria.............. 272
4.7.4.2 O serviço de sistema de gestão do conhecimento..................................................... 273
4.7.5.1 estratégia de Gestão do Conhecimento ............................................................274
Captura de conhecimento identificação e manutenção ...........................................................................275
4.7.5.2 A transferência de conhecimento .............................................................................. 275
Estilos de aprendizagem...........................................................................................................................276
Visualização conhecimento ......................................................................................................................276

Comportamento de condução ..................................................................................................................277
Seminários, Seminários e publicidade......................................................................................................277
Revistas e boletins....................................................................................................................................277
Voltado para o público ..............................................................................................................................277
4.7.5.3 Gestão de dados e informações................................................................................ 278
Dados que comprovem e requisitos de informação .................................................................................278
Definir a arquitetura da informação ..........................................................................................................279
O estabelecimento de dados e procedimentos de gestão de informação ...............................................280
Avaliação e melhoria.................................................................................................................................281
4.7.5.4 Usando o serviço de sistema de gestão do conhecimento......................................... 281
Estudo de caso .........................................................................................................................................282
4.7.6 Triggers, entradas e saídas e as interfaces entre processos................................284
Operações de Serviço ..............................................................................................................................284
Equipe de operações................................................................................................................................284
Equipe de transição ..................................................................................................................................285
4.7.7.1 Avaliação e melhoria................................................................................................. 285
4.7.7.2 Indicadores relevantes para os negócios / clientes .................................................... 286
Medindo benefício de transferência de conhecimento.............................................................................286
4.7.7.3 As medidas directamente relevantes para o prestador de serviços............................ 287
5 Serviços de Transição comuns atividades de operação ............................... 288
5,1 comunicações de gestão e compromisso............................................................ 289
5.1.1 Comunicações durante Transição de Serviço ......................................................289
Exemplo: síndrome de Emergência..........................................................................................................289
5.1.2 Planejamento de Comunicação............................................................................290
5.1.3 Métodos de comunicação.....................................................................................292
Exemplo: O balcão de atendimento..........................................................................................................293
5.1.4 Motivação e a importância da comunicação.........................................................296
5.2 Organização Gestão e mudança das partes interessadas.................................. 297
5.2.1 O ciclo emocional da mudança.............................................................................297
5.2.1.1 A gestão eficaz da mudança ..................................................................................... 298
5.2.2 Organização, funções e responsabilidades ..........................................................299
Papel 5.2.3 Transição de Serviço na mudança organizacional .....................................299
5.2.3.1 Entendendo a cultura organizacional......................................................................... 301
5.2.4 Estratégia e design para a gestão da mudança organizacional............................304
5.2.5 Planejamento e implementação de mudança organizacional...............................304
5.2.6 Organizacionais produtos de mudança ................................................................305
5.2.7 Avaliação de prontidão para a mudança organizacional ......................................309
5.2.8 Monitoramento do progresso de mudança organizacional ...................................310
5.2.9 Lidando com a organização e as pessoas em mudanças de sourcing.................311
Choque empregado ..................................................................................................................................311
Mudanças nos negócios ...........................................................................................................................311
Alteração de local .....................................................................................................................................312
Vinculação das atividades de terceirização de toda a organização.........................................................312
5.2.10 Métodos, práticas e técnicas ..............................................................................314
5.2.10.1 Sugestões e dicas de gestão da mudança............................................................... 314
5.2.10.2 JP Kotter "Oito passos para transformar a sua organização..................................... 316
5.2.10.3 organizacionais estratégias de mudança................................................................. 317
5.2.10.4 Técnicas de superar a resistência dos indivíduos para mudar ................................. 319
5.3 Gestão de Stakeholders....................................................................................... 321
5.3.1 estratégia de gerenciamento das partes interessadas .........................................321
5.3.2 mapa de stakeholders e análise ...........................................................................322
5.3.2.1 mudanças Stakeholder.............................................................................................. 325
5.3.3 Mudanças no compromisso das partes interessadas...........................................326
6 Organizador Transição de Serviço................................................................ 326
6,1 papéis genéricos................................................................................................... 327
6.1.1 Processo de papel de dono..................................................................................327
6.1.2 papel de dono de serviço......................................................................................327
6,2 contexto organizacional para a transição de um serviço..................................... 329
6,3 modelos de organização para apoiar a Transição de Serviço ............................ 331

6.3.1 Gerenciamento de Transição de Serviço..............................................................331
6.3.2 Serviço de Transição papéis e responsabilidades................................................331
6.3.2.1 O gerente de Transição de Serviço ........................................................................... 332
6.3.2.2 Planejamento e apoio ............................................................................................... 333
6.3.2.3 Ativo de Serviço e Gerenciamento de Configuração e Mudança................................ 333
As funções de gerenciamento ..................................................................................................................333
O gestor de activos serviço.......................................................................................................................334
O gerenciador de configuração ................................................................................................................335
O analista de configuração .......................................................................................................................336
O administrador de configuração / bibliotecário .......................................................................................337
O administrador do CMS / ferramentas....................................................................................................338
O Conselho de Controle de Configuração................................................................................................339
A autoridade de mudança.........................................................................................................................339
O gerente de mudança .............................................................................................................................340
Alterar Conselho Consultivo .....................................................................................................................341
6.3.2.4 Avaliação de desempenho e gestão de risco............................................................. 341
O gerente de avaliação de desempenho e risco......................................................................................341
6.3.2.5 Serviço de Gestão do Conhecimento ........................................................................ 341
O processo de Gestão de Conhecimento proprietário .............................................................................342
6.3.2.6 gerente de teste do serviço ....................................................................................... 342
Suporte de teste........................................................................................................................................343
6.3.2.7 Lançamento e implantação ....................................................................................... 343
O gerente de lançamento e implantação..................................................................................................343
6.3.2.8 embalagem Lançamento e construir.......................................................................... 345
A embalagem de lançamento e construção de gerente...........................................................................345
6.3.2.9 Implantação.............................................................................................................. 345
6.3.2.10 apoio Início da vida ................................................................................................. 345
6.3.2.11 Build e gestão de ambiente de teste........................................................................ 346
Transição de Serviço 6,4 relacionamento com os estágios do ciclo de vida de outros
..................................................................................................................................... 348
6.4.1 relações a montante de Transição de Serviço......................................................348
6.4.1.1 mobilidade do pessoal Lógico ................................................................................... 348
6.4.1.2 Processo de comunicações....................................................................................... 349
6.4.2 processo de Downstream e influência procedimento ...........................................349
7 considerações de tecnologia ........................................................................ 351
7,1 Ferramentas de Gestão do Conhecimento.......................................................... 353
7,2 Colaboração.......................................................................................................... 354
7.2.1 Comunidades........................................................................................................354
7.2.2 gestão de fluxo de trabalho...................................................................................355
7,3 Sistema de Gerenciamento da Configuração...................................................... 356
8 Transição de Serviço Implementação........................................................... 359
8,1 Estágios da Transição de Serviço introduzindo................................................... 361
8.1.1 Transição de Serviço Justificando ........................................................................361
8.1.2 Transição de Serviço Projetando..........................................................................361
8.1.2.1 normas e políticas..................................................................................................... 361
8.1.2.2 Relacionamentos ...................................................................................................... 361
Outros serviços internos de apoio ............................................................................................................362
Programa e gerenciamento de projetos ...................................................................................................362
Equipes internas de desenvolvimento e fornecedores externos..............................................................362
Clientes / utilizadores................................................................................................................................362
Outras partes interessadas.......................................................................................................................363
8.1.2.3 Orçamento e recursos............................................................................................... 363
Abordagem de financiamento...................................................................................................................363
Recursos...................................................................................................................................................364
8.1.3 Transição de Serviço Apresentando.....................................................................364
8.1.4 Culturais aspectos de mudança............................................................................365
8.1.5 Risco e valor.........................................................................................................365
9 Desafios, fatores críticos de sucesso e riscos .............................................. 366
9,1 Desafios ................................................................................................................ 366
9,2 Fatores críticos de sucesso.................................................................................. 368

9,3 Riscos ................................................................................................................... 370
9,4 Transição de Serviço em condições difíceis........................................................ 371
9.4.1 Quando a velocidade é mais importante do que a precisão ou suavidade...........371
9.4.2 recursos restritos ..................................................................................................373
9.4.3 serviços de segurança críticas e ambientes de alto risco.....................................373
9.4.4 Trabalhando com clientes difíceis.........................................................................374
Posfácio........................................................................................................... 375
Apêndice A: Descrição dos tipos de ativos ...................................................... 376
Gestão......................................................................................................................... 376
Organização................................................................................................................ 376
Processo ..................................................................................................................... 376
Conhecimento............................................................................................................. 377
Pessoas ...................................................................................................................... 377
Informações ................................................................................................................ 378
Aplicações................................................................................................................... 378
Infra-estrutura.............................................................................................................. 379
O capital financeiro ..................................................................................................... 379
Outras informações ......................................................................................... 380
Referências................................................................................................................. 380
Glossário ......................................................................................................... 383
Lista de siglas ............................................................................................................. 383
Lista de definições ...................................................................................................... 387

Prefácio
Prefácio da OGC
Desde a sua criação, ITIL cresceu e se tornou a abordagem mais amplamente
aceito para IT Service Management em todo o 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.
Serviço de Gestão de Requisitos 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 publicação é uma das cinco publicações centrais descrevendo as práticas
de serviço de gerenciamento 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 Service
Management. 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

Esta publicação, IT Infrastructure Library (ITIL) Transição de Serviço, fica no
centro da estrutura de ciclo de vida do ITIL. Transição não é uma palavra
cotidiana - palavras como 'design' e 'operar', Descrevendo a ciclo de vida fases
de cada lado da passagem, estão mais familiarizados. Mas esses termos mais
familiares que a transição suporte também pode servir para ajudar a definir e
explicar seus objetivos e propósitos.
A necessidade de conceber um serviço, Totalmente novo ou alterado, é aceito -
sem visão da finalidade do serviço esse fim será sempre não entregue. E ao
longo dos últimos 17 anos (desde o início da ITIL) a necessidade tem sido
firmemente estabelecida para o gerenciamento contínuo dos serviços. Isso tem
sido reconhecido como o "núcleo" de IT Service Management - fornecer e
suportar o 'business as usual' entrega de exigências da organização de TI.
E assim, é facilmente perceptível que conseguem se mover a partir do conceito
de "como" - desenvolvido pelo projeto - em "o que" - como apoiado por
operações - vai ser o elemento-chave de fornecer o apoio às empresas que são
acusados. E para que haja sempre uma necessidade de uma transição de
serviço.
A importância de realmente entregar um projeto, adaptando-o conforme
necessário, garantindo e assegurando a sua relevância, tem sido menos óbvio
para muitos. Transição de Serviço concentra em fornecer a visão de serviços de
uma forma relevante e rentável. Transição de Serviço como tal, é efetivamente
definido pelos conceitos de prestação de serviços que fornecem suas entradas e
as Operação de Serviços expectativas que servem como destinatários de suas
saídas - que são serviços utilizáveis.
A melhor maneira de alcançar Transição de Serviço irá variar entre organizações
e tem de reflectir os riscos, recursos e outros parâmetros relacionados a essa
organização em geral e do serviço a ser transferida, em particular.
Uma analogia útil é uma corrida de revezamento, onde a equipe de corredores
devem levar um bastão rodada da pista - passando de mão em mão entre os
membros da equipe. A expectativa inicial pode ser que a vitória em uma corrida
depende de ter os mais rápidos atletas. No entanto, importante como a
velocidade ea aptidão dos corredores estão, é igualmente importante para não
deixar cair o bastão. Por outro lado, a concentração total na passagem
cuidadoso e livre de risco de o bastão também não vai fazer uma equipe
vencedora. Para ganhar a corrida requer a combinação certa de velocidade e
entrega do bastão.
De um modo semelhante, Transition serviço deve oferecer serviços relevantes
com o balanço adequado de velocidade, custo e segurança.

As prioridades, preocupações, limitações e condições que ditam as decisões e
foco da Transição de Serviço irá variar entre prestadores de serviços. Para
aqueles em segurança crítica indústrias, tais como suporte tecnológico médica e
controle de estação de energia nuclear, o foco será na redução de rigor e de
risco - a principal prioridade aqui não é deixar cair o bastão: "levá-la
cuidadosamente" é a abordagem correta. Isto é típico em que a concorrência é
baixa, como no setor público, ou onde os controles governamentais insistem em
cautela, ou a percepção do cliente de sua exigência de confiabilidade é alta.
Alternativamente, em setores altamente competitivos, como a venda de produtos
on-line ou instalações de telefonia móvel, a velocidade pode ser mais
importante. Em uma corrida de revezamento com 100 equipes, a concentração
no seguro de entrega vai lhe trazer de forma consistente no primeiros 20%, mas
você provavelmente nunca vai ganhar. Necessidades de negócio do cliente pode
ditar que faz mais sentido para largar o bastão de 80% do tempo, mas em
primeiro lugar para o resto.
Isto pode parecer tangencial, mas é importante para definir a cena aqui, e
reconhecer que esta publicação das melhores práticas, com base em práticas de
sucesso seguido em muitas organizações, não vai entregar orientação absoluta
em todas as áreas. Em vez disso, a orientação se baseia em julgar um prestador
de serviços corretos parâmetros de transição e, em seguida, ajudando a
construir e implementar a melhor abordagem para as suas circunstâncias.
Seguindo esta lógica, a publicação se dirige a toda a gama de circunstâncias
diferentes e permite interpretação flexível. Deve ser lido, compreendido e
seguido de uma forma flexível e pragmática, consciente de que Transição de
Serviço é, com efeito, oferecendo um serviço interno; tomar as saídas de projeto
e entregá-los a um estado operacional, a fim de melhores requisitos de apoio às
empresas. Isso requer compreensão suficiente de saídas de projeto e insumos
operacionais, e do requisito de negócio verdadeiro e final. Este conhecimento é
necessário na avaliação e garantia (ou rejeição) de requisitos e especificações
de design, restrições e parâmetros.
O sucesso de Transição de Serviço é a capacidade de operações de serviços
para apoiar os processos de negócio através da base de serviço instalado. O
mecanismo para atingir a meta é secundário e adaptável - e isso se aplica se
uma organização é a transição de serviços em projetos de apoio às empresas
ou componentes e materiais para motocicletas (veja a publicação Estratégia de
Serviço). O objetivo desta publicação é o de apoiar os gestores e profissionais
de serviço de transição na sua aplicação de práticas de Transição de Serviço.

Sharon Taylor
Arquiteto Chefe, Práticas ITIL Service Management

Prefaciar
"Eles sempre dizem que o tempo muda as coisas, mas você realmente tem que
mudá-las" Andy Warhol, A Filosofia de Andy Warhol. EUA artista (1928-1987).
Eficaz Transição de Serviço não aconteça até uma organização reconhece a
necessidade e os benefícios que ela lhes trará.
Transição de Serviço e eficaz é necessária porque os ambientes de negócios
estão em um constante estado de transição. A busca da vantagem competitiva,
o melhor da inovação raça e auto-preservação são catalisadores para a
mudança eternos que devem ser entregues.
Transição de Serviço é o guia do Information Technology Service Management
(ITSM) profissional para entregar essas mudanças através de transição ciclo de
vida passos, que ajudá-los a gerir a mudança em um contexto mais amplo.
Grande escala mudança muitas vezes é conduzido através de iniciativas do
projeto ou programa. Estes são erroneamente vista como "Gestão da Mudança"
de fora, e muitas vezes não é considerado um Serviço de Gestão de dizem
respeito até a hora de implementar. No entanto, a experiência ensina que essa
abordagem raramente produz o melhor benefício possível para o negócio.
Esta publicação fornece respostas a gestão Transição de Serviço a partir de
especificações projetadas,, mudança de configuração, teste de lançamento, e
implantação e cada passo no meio.
Transição de Serviço eficaz garante que necessidade reunião de negócios,
custo e eficiência são alcançados com o mínimo de risco, otimização máxima eo
maior grau de confiança possível.
Transição de Serviço também exige uma gestão eficaz do conhecimento
organizacional, cultura e transição em circunstâncias difíceis ou inusitadas. Cada
profissional ITSM conhece a maior parte de qualquer mudança - que pode fazer
ou quebrar seu sucesso - está relacionado com o fator humano, especialmente
aversão cultural à mudança.
Esta publicação explora as práticas da indústria para todos os tamanhos e tipos
de organizações e irá beneficiar todos os envolvidos no Serviço de Gestão de.
As práticas contidas nestas páginas culminam de décadas de experiência,
conhecimento e evolução de pesquisa emergente em matéria de IT Service
Management.

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
Shirley Lacy (ConnectSphere) Autor
Ivor Macfarlane (Guillemot Rock) 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),
David Cannon (HP), o caso de Gary (Pink Elephant), Ashley Hanna (HP), Majid
Iqbal (Carnegie Mellon Universidade), Vernon Lloyd (Fox IT), Michael Nieves
(Accenture), Stuart Rance (HP), Colin Rudd (itens), George Spalding (Pink
Elephant) e David Wheeldon (HP).
Mentores
Malcolm Fry e Robert Stroud
Outras contribuições
Um número de pessoas contribuíram generosamente seu tempo e conhecimento
para esta publicação Transição de Serviço. Jim Clinch, como OGC Gerente de
Projeto, é grato ao apoio prestado por Jenny Dugmore, Convocador de Grupo de
Trabalho da ISO / IEC 20000, Eves Janine, Hulm Carol, Lawes Aidan e Michiel
van der Voort.
Os autores também gostariam de agradecer a Jane Clark, Michelle Hales e
Carol Chamberlain de ConnectSphere, Dr. Paul Drake, Lyn Jackson, LJ
Treinamento, Amanda Robinson, Luciana Abreu, EXIN Brasil, Kate Hinch, KFA e
Candace Tarin, a Aspect Group Inc.
Para desenvolver ITIL v3 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
Alfonso Abad, HP; Simon Adams, Lloyds TSB; Terry Adams, iCore Ltd; Tina Anderson,
IBM, Daniel Andrade, Pink Elephant, Deborah Anthony, HP; Ramirez Arnoldo; Andrew
Atencio; Graham Barnett, Fujitsu Services; Piet Beek; Karen Benitez , Tiago Biglin,
Lloyds TSB, Robert Blackburn, HP; Roland Boettcher, Fachhochschule Bochum;
Maarten Bordewijk, Getronics PinkRoccade NL; Elizabeth Brewster, Itech Consulting,
Josué Brusse; Gerban CDAEE; Alison Cartlidge, Xansa; Chia-jen liu Chyan, HP; Jane
Cooney, David Clifford, PRO-Attivo; Lynda Cooper, Fox IT; Stewart Crymble, HP; Helen
Curran, IBM; Alvin Deen, HP; Thiemo Doleski, iCore Ltd, Paul Donald, Lucidit; James
Doss, UD Defesa Agência de Inteligência; Jenny Ellwood-Wade, Bowood Ltd; Anneriek
Favelle, Lucidit; James Finister, PA Consulting; Vitaly Frolov, Motorola, Frank Gogola,
Mayer, Brown, Rowe & Maw LLP; Gunning Ian, Standard Life Assurance plc; Susan
Hall, da Universidade de Dundee; Gregory Hines; Andreas Hoffmann, Negócios Valor 4;
Liz Holmes, iCore Ltd; Wim Hoving, BHVB; Alison Howitt, o Parlamento escocês,
Michael Hughes, Sensis; Robin Hysick, Pink Elephant, Steve Ingall, Fox IT, Samantha
Keyse; Daniel Klemm, IBM; Lasse Wilen Kristensen, da Microsoft; Horacio Laprea, HP;
Marty Larsen, Microsoft; Volker Leitzgen, Microsoft, Peter Lijnse, Gestão de Serviços de
Arte; Kerry Litten, INS Ltd; Donald MacLean; Venugopal Maddukuri, UCB Grupo;
Ramachandra- Rao Madhukar; Brenda McCabe, McCain Foods, Peter McLoughlin,
ConnectSphere; Vinay Nikumbh, Quint Wellington Redwood Índia Consultoria; Tsuyoshi
Ohata, NEC; Sekhar Pidathala, UBS; cristã Piechullek, Prinovis Ahrensburg GmbH & Co
KG, Mikhail Pototskiy, especialista em TI, David Pultorak; Glen Purdy, Fujitsu
Consulting; Doug Read, Dreamland Consultants Ltd; Douglas Leia, Proattivo; Neil
Reynolds, SNS; Jonathan Ridler, HP; Luis Rodriguez, CA; Gerard Roth, Microsoft;
Frances Scarff, OGC; Steffan Scholtze; Moira Shaw , Xansa plc; Dejan Sloker, Deloitte,
Marco Smith, iCore Ltd, João Sowerby, Serviços de Informação da DHL; George Stark,
IBM; Randy Steinberg, ITSM Estratégias Inc; Michal Tepczynski, Nokia Finlândia; Kay
Thomas, iCore Ltd; Adrian van de Rijken , Plexent; Bruce Weiner, GEICO; Natalie
Welch, Severn Trent Sistemas; Kathleen Wilson, da Microsoft; Abbey Wiltse,
ITpreneurs; Grover Wright, Computacenter Serviços; Robin Yearsley; Graham Young,
TCS.

1 Introdução
O Transição de Serviço publicação é parte do ITIL Práticas de gestão de
serviços, que diagnóstico indústria melhores práticas para o serviço ciclo de vida
gestão de TI permitiu serviços. Embora esta publicação pode ser lido de forma
isolada, recomenda-se que seja utilizada em conjunto com o outro ITIL
publicações. Serviço de Gestão de é um conceito genérico e as orientações do
novo ITIL publicações se aplica genericamente. A orientação também é
escalável - aplicável a pequenos e grandes organizaçãos. Ela se aplica a
distribuída e centralizada sistemas, seja em casa ou fornecidos por terceiros. É
burocrática nem pesado, se implementado com sabedoria e no pleno
reconhecimento da negócio necessidades de sua organização.
Adoção de práticas de serviço melhor transição permitem melhorar a serviços e
Serviço de Gestão de capacidade assegurando que a introdução,
desenvolvimento, Transferência e encerramento de serviços novos ou alterados
é consistentemente bem gerida

1.1 Visão Geral
Provedor de serviçoss estão cada vez mais focados em serviços qualidade
adoptando uma abordagem mais empresarial e orientada para o cliente para
oferecer serviços e custar otimização.
Muitas organizações entregar significativo mudar através formais projetos, eo
fracasso em garantir que projetos o endereço completo Serviço de Gestão de e
operacional bem como os requisitos do funcional exigências pode ser caro, ou
mesmo fatal erro, a uma organização. Transição garante que o serviço transição
processoes são simplificados, eficaz e eficiente, de modo que a risco atraso é
minimizado. Ela estabelece garantia do serviço real e esperado entregas, e
elementos integrados que cada serviço depende de entregar e operar o serviço
com sucesso. Esses elementos incluem aplicaçãos, infra-estrutura,
conhecimento, documentação, instalações, finanças, pessoas, processos,
habilidades e assim por diante.
Onde há grande mudança haverá complexidade e risco. Normalmente existem
muitas interdependências para administrar e prioridades conflitantes para
resolver, em particular como serviços novos e modificados transição e ir viver.
Transição de Serviço leva em consideração aspectos como a mudança
organizacional e adaptação do ambiente mais amplo em que se inserem que
influenciam o uso de uma organização dos serviços e os riscos associados. É
necessário mais do que meramente a receber um projeto detalhado contendo
Aceitação Critérios, a implementação de acordo com esse projeto e medição de
acordo com os critérios. Este seria o caso, se a estabilidade pode ser
assegurada, mas no mundo real, os critérios de projeto e aceitação pode ser
afetado por mudanças de TI, outros serviços, a negócios ou outros fatores
externos. Observação, interpretação e manipulação do ambiente de serviços
mais amplo são muitas vezes necessárias para oferecer os benefícios dos
serviços requeridos pelo cliente e prevista pelo projeto.
Em todas as fases a probabilidade de sucesso é equilibrado contra as
consequências da falha e os custos (financeiros e outros). O avaliação e
previsão de atuação eo risco é, portanto, um elemento essencial e do dia-a-dia
da Transição de Serviço processo.
Transição de Serviço sucesso repousa na compreensão e aplicação da Gestão
da Mudança,garantia de qualidade, E gestão de risco e eficaz programa e
gerenciamento de projetos. Isso torna possível, em cada etapa através do
processo de Transição de Serviço, para planejar, acompanhar e confirmar o
progresso em relação às necessidades atuais, não apenas para um serviço, mas
em todos os serviços em transição.

Transição de Serviço não termina abruptamente quando um serviço novo ou
alterado vai viver, mas sim que trabalha com Operação de Serviços para
proporcionar apoio início da vida

1,2 Contexto
1.2.1 Gestão de Serviços
Tecnologia da informação (TI) é um termo comumente usado que muda de
significado com o contexto. A partir da perspectiva de primeira, TI sistemas,
aplicações e infra-estrutura são componentes ou subconjuntos de um produto
maior. Eles permitem ou são incorporados em processoes 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 negócio funçãos, compartilhados unidades de serviços e unidades de nível
empresarial do núcleo.
A partir da terceira perspectiva, é uma categoria de serviços utilizadas pelas
empresas. Eles são tipicamente aplicações de TI e infra-estrutura que são
empacotados e oferecidos como serviços de TI internos ou organizações
prestador de serviços externos. Os custos de TI 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 renda de receita 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 na dinâmica ambientes com a necessidade de aprender e
se adaptar. Existe uma necessidade de melhorar atuação enquanto gestora
trade-offs. Sob pressão semelhante, os 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, agências
governamentais e organizações sem fins lucrativos 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 tem particularmente expostos provedores de serviços internos
à concorrência incomum.
Para lidar com a pressão de referência das organizações, se contra colegas e
buscam fechar brechas em capacidades. Uma forma de fechar essas lacunas é
a adoção de boas práticas em uso de toda a indústria. Existem várias fontes de
boas práticas, incluindo quadros públicos, padrãos e do conhecimento de
propriedade de organizações e indivíduos (Figura 1.1).

Figura 1.1 Fornecimento de prática Gestão de Serviços
Estruturas públicas e as normas são atraentes em comparação com
conhecimento proprietário.
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, através de
compras e de licenciamento acordos.
• Estruturas disponíveis publicamente e padrões como ITIL,Objetivos de
Controle para Informações e Tecnologia relacionada (COBIT), Capability
Maturity Model Integration (CMMI), eSourcing Modelo de Capacidade
para provedores de serviços (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ãos pode 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 a partir de práticas e normas comuns.
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 boa prática em
Serviço de Gestão de. ITIL é usado por organizações em todo o mundo para
estabelecer e melhorar as capacidades em Serviço de Gestão de. ISO / IEC
20000 fornece um padrão formal e universal para organizações que buscam ter
seu Serviço de Gestão de recursos auditados e certificados. 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:
• O Core ITIL: melhores práticas orientações aplicáveis a todos os tipos de
organizações que fornecem serviços a um negócio
• Orientação ITIL complementar: um conjunto complementar de
publicações com orientações específicas para os setores da indústria,
tipos de organização, operando modelos e tecnologia arquiteturas.
O Core ITIL é composto por cinco publicações (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:
• Estratégia de Serviço
• Design de Serviços
• Transição de Serviço
• Operação de Serviço
• Melhoria de Serviço Continuada.

Figura 1.2 ITIL Núcleo
Cada publicação aborda capacidades que têm um impacto direto sobre a
provedor de serviços'S atuação. A estrutura do núcleo é na forma de um ciclo de
vida. Ele é interativo e multidimensional. Ele garante organizações são criadas
para alavancar as capacidades em uma área de aprendizagem e melhorias em
outras. O núcleo deve proporcionar 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 na ITIL pode ser adaptado para uso em várias negócio ambientes e
estratégias organizacionais. Orientação Complementar fornece flexibilidade para
implementar o núcleo em uma variedade 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, bem como 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 para proteger investimentos em Serviço de Gestão de
capacidades.
1.2.3.1 Estratégia de Serviço

A publicação Estratégia de Serviço fornece orientações sobre como projeto,
Desenvolver e implementar Serviço de Gestão de não só como uma
organização capacidade mas como um ativo estratégico. São fornecidas
orientações sobre os princípios subjacentes à prática de Serviço de Gestão de
os quais são úteis para o desenvolvimento Serviço de Gestão de políticas,
diretrizs e processoes entre o ITIL serviço ciclo de vida. Estratégia de Serviço
orientaçã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çosE implementação de
estratégia por meio do serviço ciclo de vida.Gestão financeira,O gerenciamento
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 as expectativas de
atuação para servir os clientes e espaço de mercados, e de identificar,
selecionar e priorizar oportunidades. Estratégia de Serviço consiste em garantir
que as organizações estão em posição de lidar com os custos e riscos
associados à sua Portfólio de Serviçoss, e são criados não só para operacional
eficácia, mas para um desempenho diferenciado. Decisões tomadas sobre
Estratégia de Serviço tem conseqüências de longo alcance, incluindo aqueles
com efeito retardado.
Organizações já praticando ITIL usar esta publicação 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.
Esta publicação 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 framework ITIL além do público tradicional de IT Service
Management profissionais.
1.2.3.2 Design de Serviços
O Design de Serviços publicação fornece orientação para a concepção e
desenvolvimento de serviços e Serviço de Gestão de processos. 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, conformidade e
para padrãos e regulamentos. Ele orienta as organizações sobre como
desenvolver capacidades de design para Serviço de Gestão de.
1.2.3.3 Transição de Serviço

A publicação Transição de Serviço fornece orientações para o desenvolvimento
e melhoria de capacidades para a transição de serviços novos e modificados
para operações. Esta publicação fornece orientação sobre como o exigências de
Estratégia de Serviço codificado em Design de Serviços são efetivamente
realizados em Operações de Serviço ao controlar os riscos de falha 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 Gerenciamento de
Serviço. Ele fornece orientações sobre o gerenciamento da complexidade
relacionada a alterações nos serviços e processos de gerenciamento de
serviços, 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
Esta publicação 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 a 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 capacidade crítica. São
fornecidas orientações sobre como manter a estabilidade em operações de
serviços, o que permite mudanças em projeto, Escala, escopo e nível de
serviços. Organizações são fornecidos com informações detalhadas processo
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, utilização de operações, e fixando 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
O Melhoria de Serviço Continuada publicação oferece orientação instrumental
na criação e manutenção de valor para os clientes através de uma melhor
concepção, introduçã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 capacidade
melhoria. 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 Estratégia de Serviço, Design e transição. A realimentação de circuito
fechado sistema, Com base no Plan-Do-Check-Act (PDCA) modelo especificado
na norma ISO / IEC 20000, é estabelecido e capaz de receber insumos para
mudar a partir de qualquer planejamento perspectiva.

1,3 objetivo e escopo de Transição de Serviço
1.3.1 Meta
O objetivo desta publicação é auxiliar empresas que desejam planejar e
gerenciar serviço mudanças e serviços de implantação liberars para o ambiente
de produção com sucesso.
1.3.2 Âmbito
Esta publicação fornece orientação para a desenvolvimento e melhoria de
capacidades para a transição de serviços novos e modificados para a produção
ambiente, Incluindo a libertação de testes de planejamento, construção,
avaliação e desenvolvimento. A orientação se concentra em como garantir a
exigênciaEstratégias s de serviço, estabelecidas em Design de Serviço, são
efetivamente realizados em Operações de Serviço ao controlar a riscos de falha
e ruptura.
Consideração é dada para:
• Gerir a complexidade associada com alterações nos serviços e gestão de
serviços processoes
• Permitindo a inovação, minimizando as consequências não intencionais
de mudança
• A introdução de novos serviços
• Mudanças nos serviços existentes, por exemplo, redução da expansão, a
mudança de fornecedor, Aquisição ou alienação de seções de usuário
base ou fornecedores, mudança de requisitos ou a disponibilidade de
competências
• De-comissionamento e supressão de serviços, aplicaçãos ou outro
serviço componentes
• Transferência de serviços.
Orientação sobre a transferência do controlar de serviços inclui a transferência,
nas seguintes circunstâncias:
• Para um novo fornecedor, E.g. terceirização, Off-shore
• De um fornecedor para outro
• Voltar a partir de um fornecedor, por exemplo, insourcing
• Ou a partir de um prestador de serviços externo
• Passando para um compartilhada serviço provisão (por exemplo,
terceirizar parcial de alguns processoes)
• Vários fornecedores, por exemplo, inteligente-sourcing
• Joint venture / destacamento
• Parceria
• Down-sizing, up-dimensionamento (direita-dimensionamento)

• Fusão e aquisição.
Na realidade, as circunstâncias gerar uma combinação de várias das opções
acima, em qualquer altura e em qualquer situação.
O escopo inclui também a transição de mudanças fundamentais na provedor de
serviços"Gestão de Serviços s capacidade que vai mudar as formas de trabalho,
o organização, Pessoas, projetos e terceiros envolvidos em Serviço de Gestão
de.

1,4 Uso
1.4.1 Público-alvo
Esta publicação é relevante para as organizações envolvidas no
desenvolvimento, Entrega ou suporte de serviços, incluindo:
• Prestadores de serviços, tanto internos e externos
• Organizações que visam melhorar os serviços através da aplicação
efectiva do Serviço de Gestão de e serviço ciclo de vida processos para
melhorar seu serviço qualidade
• Organizações que requerem uma abordagem consistente conseguiu em
todos os prestadores de serviços em um cadeia de suprimentos
• Organizações que vão a concurso para os seus serviços.
A publicação é relevante para Gerente de TI serviços e para todos aqueles que
trabalham em Transição de Serviço ou zonas de suporte do objetivos da
Transição de Serviço, incluindo:
• O pessoal que trabalha em programas e projetos que são responsáveis
pela prestação de serviços novos ou alterados e os serviços ambiente
• Gerentes e funcionários de transição
• Testando gestores e profissionais de teste, incluindo ambiente de teste e
teste gerentes de dados e bibliotecários
• Garantia de qualidade gerentes
• Ativos e Gerenciamento da Configuração pessoal
• Gestão da Mudança pessoal
• Solte e desenvolvimento pessoal
• Equipe de aquisição
• Relação gerentes e fornecedor gerentes
• Fornecedores entrega de serviços, suporte, treinamento etc
1.4.2 Benefícios desta publicação
Selecionar e adotar o melhores práticass nesta publicação vai ajudar as
organizações a entregar benefícios significativos. Adopção e implementação de
abordagens padronizadas e consistentes para a Transição de Serviço irá:
• Viabilizar projetos para estimar o custar, Tempo, recurso exigência e
riscos associados com o Transição de Serviço encenar mais precisão
• Resultar em volumes mais elevados de sucesso mudar
• Ser mais fácil para as pessoas a adotar e seguir
• Ativar Transição de Serviço ativoss para ser compartilhado e reutilizado
em projetos e serviços
• Reduzir os atrasos de confrontos inesperados e dependências, por
exemplo, em ambientes de teste

• Reduzir o esforço gasto no gerenciamento da Transição de Serviço teste
e piloto ambientes
• Melhorar o estabelecimento de expectativa para todos das partes
interessadass envolvido em Transição de Serviço incluindo clientes,
usuários, fornecedores, parceiros e projetos
• Aumentar a confiança de que o novo serviço ou alterados podem ser
entregues aos especificação inesperadamente, sem afetar outros serviços
ou partes interessadas
• Assegurar que os serviços novos ou alterados será sustentável e
rentável.
A publicação vai ajudar os seus leitores a criação de Transição de Serviço e do
processoes que apoiá-lo, e de fazer uso efetivo desses processos para facilitar a
transição eficaz de novo, alterado ou desativado serviços.
Estabelece orientações sobre a criação e operação de Transição de Serviço e
aborda especificamente os processos que estão substancialmente focados no
apoio Transição de Serviço. Especificamente, além de introdução deste capítulo
de alto nível para o assunto, capítulos subseqüentes no endereço publicação os
seguintes tópicos.
Capítulo 2 - Gerenciamento de Serviços como uma prática
Este capítulo introduz o conceito de Serviço de Gestão de como prática. Aqui
Service Management está posicionada como uma estratégica e profissional
componente de qualquer organização. Ela ilustra os elementos do Transição de
Serviço ciclo de vida fases. A meta e escopo do tema são apresentados
juntamente com as medidas-chave de sucesso. Interfaces com outros ITIL
Tópicos principais são descritas e os processos que suportam transição são
listados, colocada no contexto e descrito em termos da sua gama de
aplicabilidade em todo o ciclo de vida e a sua relevância para a interface e de
transição.
Capítulo 3 - Princípios Transição de Serviço
Este capítulo estabelece os princípios e conceitos-chave dentro de Transição de
Serviço, terminologia específica e uso.
Capítulo 4 - processos de transição de serviços
Uma secção separada é dedicada a cada uma das processoes que Transição de
Serviço apoio.
Alguns destes processos são quase inteiramente contido dentro da área de
transição, por exemplo, desenvolvimento. Outros são os processos do ciclo de

vida de forma eficaz toda que suportam o pleno serviço ciclo de vida: Gestão da
Mudança, por exemplo (ver parágrafo 2.4.6).
Capítulo 5 - Transição de Serviço atividades de operação comuns
Atividades, informações e outros assuntos relevantes para a Transição de
Serviço, incluindo a gestão de mudança organizacional durante a transição.
Capítulo 6 - Organizador Transição de Serviço
Papéis e responsabilidades, juntamente com outras opções apropriadas
organizacionais são considerados com referência às adaptações relevantes para
o tamanho do setor da indústria, etc,
Capítulo 7 - Considerações de serviços de tecnologia de transição
Todos os aspectos da IT Service Management dependem, em maior ou menor
grau, no apoio tecnológico adequado. Este capítulo estabelece os requisitos
tecnológicos típicos de Transição de Serviço eficaz e como a tecnologia pode
oferecer apoio construtivo.
Capítulo 8 - Transição de Serviço Implementação
Este capítulo considera os elementos necessários e adequados abordagens de
uma organização de implementação Transição de Serviço.
Capítulo 9 - Desafios, fatores críticos de sucesso e riscos
A fim de assegurar Transitions Serviço de sucesso, eficaz e eficiente, é
essencial ser capaz de estabelecer o atuação contra alvos e custos contra
orçamentos de transição de serviços e de todo o processo.
Posfácio
Apêndice A: Descrição dos tipos de ativos
Outras informações
Este apêndice referências externas (a ITIL) Conceitos e abordagens que são
relevantes para a Transição de Serviço. Incluem-se:
• Formal padrãos, como a ISO / IEC 20000 e ISO / IEC 27000
• Melhores práticas orientações como COBIT
• Processoes e métodos tais como a projeto e programa gestã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 aos clientes na forma de serviços. As capacidades
de assumir a forma de funçãos e processos para gestão 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
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, a serviço organização é apenas um conjunto de recursos
que por si só tem relativamente baixo valor intrínseco para os clientes.
Serviço de Gestão de
"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. A Toyota desenvolveu novas
capacidades de 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 (Magretta 2002). Os recursos 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:
• A natureza intangível da produção e produtos intermediários de
processos de serviços, o que é difícil de medir, controlar e validar (ou
provar).
• A demanda está intimamente ligado com cliente ativoss; usuários e ativos
dos clientes, tais como processos, aplicaçãos, documentos e transaçãos
chega com a demanda e estimular a serviço produção.
• Alto nível de contato para os produtores e consumidores de serviços, há
pouco ou nenhum amortecedor entre o cliente, o front-office e back-office.
• ele perecibilidade da produção de serviços e de 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.
Gestão de Serviços, no entanto, é 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 influenciam a sua
qualidade. Indústria melhores práticass, a pesquisa acadêmica e os padrões
formais contribuir para o seu capital intelectual e tirar dele.
As origens da Serviço de Gestão de estão em serviço tradicional negócioes 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 gerenciamento de aplicações de TI, infra-estrutura e
processoes. Soluções para os negócios problemas e suporte para negócios
modelos, estratégias e operações são cada vez mais na 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 Gerenciamento
de Serviços e, ao mesmo tempo impôs desafios maiores sobre ele.

2.2 O que são serviços?
2.2.1 O valor proposição
Serviço
"Um meio de entregar valor aos clientes, facilitando resultados clientes querem
alcançar, sem a posse de custos e riscos específicos. "
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 específicos e riscos.
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).
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 para assegurar 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 meios de estruturar as organizações para implementar o princípio
da especialização. Funções tipicamente definir papéis e autoridade associadas e
responsabilidade para um desempenho específico e os resultados. Coordenação
entre funções através compartilhada processoes é um padrão comum em
organização projeto. Funções tendem a otimizar seus métodos de trabalho
localmente para se concentrarem nos resultados atribuídos. Má coordenação
entre as funções combinadas com um foco interno leva a silos funcionais que
impedem o alinhamento e feedback crítico para o sucesso da 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
transformação em direção a um objetivo, e usar o feedback para a auto-reforço e
auto-corretiva ação (Figura 2.2). É importante levar em consideração todo o
processo, ou como um processo encaixa outra.
Figura 2.2 Um processo básico
Processo definições descrevem ações, dependências e seqüência. Processos
de ter as seguintes características:

• Eles são mensuráveis. Nós somos capazes de medir o processo de uma
maneira relevante. É o desempenho conduzido. Os gerentes querem
medir custar,qualidade e as outras variáveis enquanto praticantes estão
preocupados com a duração e a produtividade.
• Eles têm 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 balcão de atendimentos foram concluídas.
• Eles entregam aos 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.
• Eles respondem a um determinado 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 de capacidade ser um Serviço
de Gestão de processo. Primeiro, gestão da capacidade organizacional é um
capacidade com processos especializados e métodos de trabalho. Se é ou não é
uma função ou de um processo depende inteiramente o projeto de organização.
É um erro supor que a gestão de capacidade só pode ser um processo. É
possível medir e controlar capacidade e para determinar se ele é adequado para
um determinado fim. Assumindo que é sempre um processo discreto com
contáveis 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 no ciclo de vida é o
progresso sequencial a partir de Estratégia de Serviço (SS) através de
Prestação de Serviços (SD) -Transição de Serviço (ST) - Operação de Serviço
(SO) e de volta a SS por meio de Melhoria de Serviço Continuada (CSI). Que, no
entanto, não é o único padrão de acção. Cada elemento do ciclo de vida fornece
pontos de feedback e controlar.
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 gerenciamento de
serviços pode adotar uma perspectiva de controle baseada em processos. Para
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 Transição fundamentos Serviço
2.4.1 Objetivo, metas e objetivos
O objetivo da Transição de Serviço é:
• Planejar e gerenciar a capacidade e recursos exigido para embalagem,
construir, Testar e implantar uma liberar em produção e estabelecer o
serviço especificado no cliente e das partes interessadas requisitos
• Fornecer um quadro coerente e rigoroso para avaliar o serviço
capacidade e risco perfil antes de um serviço novo ou alterado é liberado
ou implantado
• Estabelecer e manter o integridade de todos identificados serviço ativos e
configurações à medida que evoluem através do estágio de Transição de
Serviço
• Fornecer a boa-qualidade conhecimentos e informações para que a
mudança, Gerenciamento de Liberação e Implantação pode acelerar
decisões efetivas sobre a promoção de um comunicado através do
ambiente de testes e em produção
• Fornecer construção repetível eficiente e mecanismos de instalação que
podem ser usados para implantar liberações para o teste e ambiente de
produçãos ser reconstruída e, se necessário para restaurar serviço
• Garantir que o serviço pode ser gerenciado, operado e apoiadas em
conformidade com o exigências e restrições especificadas dentro do
Design de Serviços.
Os objetivos da Transição de Serviço são os seguintes:
• Definir as expectativas dos clientes sobre como o atuação e à utilização
dos novos ou alterados serviço pode ser usado para permitir negócio
mudar
• Permitir a alteração de negócios projeto ou cliente para integrar um liberar
na sua processo de negócioes e serviços
• Reduzir as variações na previsto e real atuação dos serviços transitou
• Reduzir o erro conhecidos e minimizar o riscos com a transição dos
serviços novos ou alterados em produção
• Garantir que o serviço pode ser utilizado de acordo com os requisitos e as
limitações especificadas dentro dos requisitos de serviço.
O objetivos são os seguintes:

• Planejar e gerenciar a recursos para estabelecer com sucesso um serviço
novo ou alterado em produção dentro do previsto custar,qualidade e
estimativas de tempo
• Garantir que há imprevisto mínimo impacto sobre os serviços da
produção, operações e organização de suporte
• Aumentar o cliente, usuário e Serviço de Gestão de satisfação pessoal
com o Transição de Serviço práticas, incluindo desenvolvimento do
serviço novo ou alterado, comunicações, documentação de liberação,
treinamento e transferência de conhecimento
• Aumentar a utilização adequada dos serviços e subjacentes aplicaçãos e
soluções de tecnologia
• Fornecer clara e abrangente planos que permitem que os projetos de
mudança de clientes e de negócios para alinhar suas atividades com os
planos de transição de serviço.
2.4.2 Âmbito
O escopo de Transição de Serviço inclui a gestão e coordenação dos processos,
sistemas e funçãos para o pacote, construir, Testar e implementar um
lançamento em produção e estabelecer o serviço especificado no cliente e das
partes interessadas requisitos.
O escopo da Transição de Serviço ciclo de vida fase é mostrada na Figura 2.3.
Actividades de Transição de serviço são mostrados nas caixas brancas. As
caixas pretas representam as actividades na outra ITIL publicações do núcleo.
Pode haver situações em que algumas atividades não se aplicam a um
determinado transição. Por exemplo, a transferência de um conjunto de serviços
de um organização para outro não pode envolver liberação planejamento,
Construir, teste e aceitação.

Figura 2.3 O âmbito de Transição de Serviço
Os processos de ciclo de vida a seguir nesta publicação suportar todas as fases
do ciclo de vida:
• Gestão da Mudança
• Ativo de Serviço e Gerenciamento de Configuração
• Gestão do Conhecimento.
Transição de Serviço utiliza todos os processos descritos na outra ITIL
publicações como é responsável por testar esses processos, seja como parte de
um novo ou alterado serviço ou como parte de testar as alterações no Serviço
de Gestão de processos. Gerenciamento de nível de serviço é importante para
garantir que as expectativas dos clientes são gerenciados durante a Transição
de Serviço. Incidente e gestão de problemas são importantes para o tratamento
de incidentes e problemas durante os testes, piloto e desenvolvimento
actividades.
As seguintes atividades estão excluídos da escopo de Transição de Serviço
melhores práticass:
• Pequenas modificações para os serviços de produção e meio ambiente,
por exemplo, substituição de um PC ou uma impressora falhou, a

instalação de software padrão de um computador ou servidor, Ou um
novo usuário
• Contínuo Melhoria de Serviço Continuadas que não afetar
significativamente os serviços ou provedor de serviços'S capacidade para
realizar os serviços, como por exemplo pedido cumprimento acções
levadas a cabo a partir de Operação de Serviços.
2.4.3 Valor para os negócios
Transição de Serviço eficaz pode melhorar significativamente a capacidade de
um provedor de serviços para lidar com grandes volumes de mudar e liberars
em toda a sua base de clientes. Ele permite que o prestador de serviços:
• Alinhe o novo ou alterado serviço com o cliente negócio requisitos e
operações comerciais
• Garantir que os clientes e os usuários podem usar o serviço novo ou
alterado de uma forma que maximiza o valor para as operações
comerciais.
Especificamente, Transição de Serviço agrega valor ao negócio melhorando:
• A capacidade de se adaptar rapidamente a novas necessidades ea
evolução do mercado ('vantagem competitiva')
• Gestão da transição de fusões, de-fusões, aquisições e transferência de
serviços
• A taxa de sucesso de mudanças e liberações para o negócio
• As previsões de nível de serviços e garantias para serviços novos e
modificados
• Confiança no grau de observância com as empresas e governo requisitos
durante mudança
• A variação do real contra estima e aprovado recurso planos e orçamentos
• A produtividade de negócios e pessoal ao cliente, pois de melhor
planejamento e uso de serviços novos e modificados
• Oportuna cancelamento ou alterações a manutenção contratos de
hardware e software quando componentes são eliminados ou
desactivadas
• Compreensão do nível de risco durante e depois da mudança, e.g.
interrupção de interrupção do serviço, e re-trabalho.
2.4.4 Otimização do desempenho Transição de Serviço
Transição de Serviço, A fim de ser eficaz e eficiente, deve se concentrar em
entregar o que o negócio requer como uma prioridade e isso dentro financeiros e
outros recurso restrições.
2.4.4.1 Medidas para o alinhamento com o negócio e planeja

A Transição de Serviço ciclo de vida palco e liberar planos precisa estar alinhado
com o Gerenciamento de Serviços de negócio, e estratégias de TI e planos.
Medidas típicas que podem ser utilizados para medir o alinhamento são:
• Maior porcentagem de planos de serviço de transição que estão
alinhados com o negócio, TI, Serviço de Gestão de estratégias e planos
• Percentagem de clientes e das partes interessadas organizações ou
unidades que têm uma compreensão clara da Transição de Serviço
prática e as suas capacidades
• Percentagem de orçamento ciclo de vida de serviços destinados a
actividades de Transição de Serviço
• Índice de qualidade dos planos, incluindo a adesão a abordagem
estruturada, observância com os modelos do plano e completude dos
planos
• Percentual de planejamento reuniões onde as partes interessadas
participaram
• Percentual de planos de serviço de transição que estão alinhados com a
Transição de Serviço política
• Percentual de estratégico e tático projetos que adotam a Transição de
Serviço serviço práticas
• Percentagem de planejamento de liberação documentos que são de
qualidade assegurada pela Transição de Serviço função ou papel.
2.4.4.2 Medidas de Transição de Serviço
Medição e monitoramento o atuação do estágio do ciclo de vida Transição de
Serviço deve incidir sobre a prestação do serviço novo ou alterado em relação
aos níveis previstos de garantia,nível de serviço, Recursos e limitações do
Design de Serviços ou a liberação do pacote. As medições devem ser alinhadas
com as medidas de design de serviço, e pode incluir a variação de medidas
previstas versus reais por:
• Utilização de recursos contra capacidade
• Capacidades
• Garantias
• Os níveis de serviço
• Custar contra orçamento aprovado
• Tempo
• Qualidade de serviço, por exemplo, os níveis de satisfação classificação
ou serviço conheceu, violada e quase acidentes
• Valor
• Erros e incidentes
• Riscos.

Exemplos de outras medidas para otimizar o atuação de Transição de Serviço
são os seguintes:
• Custo dos testes e avaliação vs custo de incidentes ao vivo
• Atrasos causados por Transição de Serviço, por exemplo, falta de
Transição de Serviço recursos
• Operacional problemas que poderiam ter sido identificados pelos
processos de Transição de Serviço
• Stakeholder satisfação com o transição etapa
• Redução de custos por meio de testes alvo de mudanças no Design de
Serviços
• Redução de mudanças urgentes ou tarde e liberars - para reduzir o
trabalho não planejado
• Redução do custo de transição de serviços e lançamentos - por tipo de
• Aumento da produtividade da equipe
• O aumento da reutilização e compartilhamento de serviço ativos e
Transição de Serviço processo ativos
• Equipe mais motivada e satisfação com o trabalho melhor
• A melhoria das comunicações e da equipe de trabalho inter-(IT,
cliente,usuários e fornecedors)
• Aprimorada atuação dos processos de Transição de Serviço.
2.4.5 Interfaces para estágios do ciclo de vida de serviços de
outros
Transição de Serviço "fica entre" Design de Serviços e Operação de Serviços no
serviço ciclo de vida e os grandes do dia-a-dia são interfaces com essas etapas.
No entanto, não é a interface com todas as etapas do ciclo de vida de outros
serviços, delineada por as entradas e saídas que fluem entre eles.
2.4.5.1 Entradas para a Transição de Serviço
Entradas de Estratégia de Serviço influenciar a abordagem global, as estruturas
e as restrições que se aplicam a Transitions Serviço e incluem:
• Portfólio de Serviços
• Carteira de clientes
• Carteira de contratos
• Serviço Lifecycle modelo
• Políticas
• Estratégias
• Restrições
• Arquiteturas
• Transição de Serviço exigências
• Serviço de Gestão de Plano (como exigido pela ISO / IEC 20000).

Design de Serviços é a principal fonte dos gatilhos que iniciam elementos de
trabalho dentro da Transição de Serviço ciclo de vida fase, ou seja, a entrada
dos pacotes de serviços de design que precisam ser transferida. O Pacote
Service Design inclui:
• Definição de serviço
• Estrutura de serviços (incluindo núcleo e serviços de apoios)
• Financeira / econômica /custar modelo (Com Custo Total de
Propriedade/Custo Total de Utilização)
• Capacidade/recurso modelo - combinado com atuação e disponibilidade
• Serviço de Gestão integrada processo modelo (como na norma ISO / IEC
20000)
• Operação de ServiçoO modelo (inclui recursos de suporte escalada
procedimentos e procedimentos de manuseio situação crítica)
• Projeto e interface especificaçãos
• Solte projeto
• Desenvolvimento plano
• Critérios de aceitação - em todos os níveis em que testes e aceitação
Foram previstas
• Pedidos para a Mudança (RFC) para instigar mudanças necessárias para
o ambiente dentro do qual a serviço funções ou funcionará.
A entrada principal, em termos de ação de iniciar, o que normalmente seria
canalizada através de Design de Serviços é a autorização para o início
Transição de Serviço (Por exemplo, RFC). No entanto, esta autorização pode vir
diretamente do empresa clientes, através de um estratégia mudar ou a partir de
auditar ou Melhoria de Serviço Continuada (CSI).
Melhoria de Serviço Continuada vai entregar insumos em termos de melhorias
sugeridas para a transição política, Práticas e processos, com base em auditoria
e exercícios de melhoria de outros, possivelmente em colaboração com o cliente
e outros das partes interessadass por meio de técnicas como um levantamento
de stakeholders.
Operação serviço irá fornecer entrada para testes e, especialmente, para a
aceitação de serviço em termos de estabelecer se as operações exigências
foram satisfeitos antes de entrega pode ser feita.
2.4.5.2 Saídas de Transição de Serviço
A mais clara conjunto de saídas de Transição de Serviço são para operações de
serviço e do cliente e usuário comunidade para quem os serviços são entregues
seguindo Transição de Serviço de sucesso. Estas saídas são:
• Aprovado pacote de lançamento de serviços e associados pacotes de
implantação

• Atualizado Pacote de serviços ou feixe de serviço que define a
extremidade-a-ponta serviço(S) oferecido aos clientes
• Atualizado Portfólio de Serviços e catálogo de serviços
• Atualizado carteira de contratos
• Documentação para um serviço de transferência ou desactivado.
Saídas para Melhoria de Serviço Continuada será composta por sugestões e
observações sobre as mudanças necessárias para melhorar processos,
especialmente aqueles dentro de Design de Serviços e Transição de Serviço,
Mas possivelmente também dentro Estratégia de Serviço e em processo de
negócioes e relação gestão.
2.4.6 Processos dentro de Transição de Serviço
Existem dois tipos de significativa Serviço de Gestão de processo que são
descritos nesta publicação, tal como indicado abaixo.
2.4.6.1 Processos que suportam o ciclo de vida do serviço
O primeiro grupo é serviço de todo ciclo de vida processos que são críticos
durante o transição fase, mas influenciar e apoiar todas as fases do ciclo de
vida. Estes compreendem:
2.4.6.2 Processos dentro de Transição de Serviço
Os seguintes processos são fortemente focado dentro do Transição de Serviço
fase:
• Planejamento de transição e suporte
• Gerenciamento de Liberação e Implantação
• Teste de serviço e Validação
• Avaliação.
3 Transição princípios do serviço

Esta seção descreve alguns dos princípios fundamentais da Transição de
Serviço que permitirá que os provedores de serviços para planejar e
implementar a Transição de Serviço melhores práticass. Estes princípios são os
mesmos, independentemente do organização, No entanto, a abordagem pode
ter de ser adaptado às circunstâncias, incluindo o tamanho, a distribuição,
cultura e recursos.

3.1 Princípios de Transição serviço de apoio
Transição de Serviço é suportado por princípios subjacentes que evoluem a
partir Estratégia de Serviço considerações e sustentam as práticas de Transição
de Serviço e abordagem. Estes princípios, em torno de entender o que um
serviço é e como ele agrega valor ao negócio, Fornecem a base para Transição
de Serviço.
3.1.1 Definir um serviço
O Estratégia de Serviço publicação descreve o enquadramento para a definição
de um serviço. O valor de um serviço é definida dentro do contexto de clientes e
contratos dentro de um eco-sistema que é comumente referido como o negócio
ambiente. Figura 3.1 ilustra a provedor de serviços ativosé usado para prestar
serviços para a empresa e clientes.
Figura 3.1 ativos de serviços necessários à prestação de serviços para a empresa
Recursos são ativos tangíveis e intangíveis que pertencem ou são controladas
pelo prestador do serviço ou o organização para conversão em produtos finais
ou serviços que são utilizados pelos clientes. Os recursos são convertidos em
bens e serviços, utilizando conhecimentos, habilidades, experiência, processos,
sistemas e tecnologias, que são por si só um especial categoria de ativos
intangíveis chamado capacidades. Este é descrito adiante na Estratégia de
Serviço.
O ativo termo é usado para se referir tanto a capacidade ou recursos, ou ambos,
dependendo do contexto envolvente.

Os serviços são um meio para fornecer valor aos clientes, como mostrado na
figura 3.2. Eles são um meio pelo qual um unidade de negócios agrega valor a
uma ou mais unidades de negócio, ou para sub-unidades dentro de si. Nesta
publicação, as unidades de negócios que prestam serviços são comumente
referido como prestadores de serviços ou unidades de serviço e aqueles que
usam serviços são chamadas de clientes ou simplesmente negócio unidades.
Figura 3.2 Serviços de fornecer o valor, aumentando o desempenho dos ativos
dos clientes e remoção de riscos
3.1.2 utilitários de serviços e garantias
O utilidade de um serviço é definida em termos da actividade resultados que os
clientes esperam que o serviço de apoio e as restrições que irá remover. Esta
utilidade é, sob a forma de melhorar ou facilitar o atuação dos ativos dos clientes
e contribuindo para a realização de resultados de negócios.
No caso da divisão de empréstimo de um banco (cliente), a utilidade de um
serviço de verificação de crédito é que ele permite que o empréstimo processo
(Ativos dos clientes) para determinar a capacidade de crédito dos mutuários
para que pedidos de empréstimo pode ser aprovado em tempo hábil depois de
calcular todos os riscos associados com o mutuário (resultado suportado).
Agarantia é uma garantia de que um produto ou serviço será fornecido ou vai
atender a certos especificaçãos. Três características de garantia são de que:
• são fornecidas em termos de disponibilidade e capacidade de serviços
• garante que os ativos dos clientes continuam a receber utilidade, Mesmo
se no degradada nível de serviços, através de grandes rupturas ou
desastres
• garante a segurança para o potencial de criação de valor dos ativos dos
clientes.

É importante compreender que os três aspectos de garantia são válidas para
todos os serviços embora um aspecto pode ser mais crítico do que o outro. Na
verdade, a proposta de valor principal em alguns serviços é de alta
disponibilidade, continuidade e segurança.

3.2 Políticas de Transição de Serviço
Os seguintes aspectos constituem princípios fundamentais da Transição de
Serviço. A sua aprovação e apoio visível da alta administração contribui para a
total eficácia. Cada princípio é explicitamente declarado e sua aplicação
sugerido e abordagem é ilustrada por princípios aplicáveis e melhores práticass
que ajudam um organização para entregar esse princípio.
3.2.1 Definir e implementar uma política formal de Transição de
Serviço
Política:
• A política formal de Transição de Serviço devem ser definidas,
documentadas e aprovadas pela equipe de gestão, que asseguram que é
comunicada por toda a organização e para todos os relevantes
fornecedors e parceiros.
Princípios:
• As políticas devem indicar claramente a objetivos e qualquer não-
observância com a política deve ser remediado.
• Alinhar as políticas com o geral governo quadro organizativo e Serviço de
Gestão de políticas.
• Patrocinadores e tomadores de decisão envolvidos no desenvolvimento
da política deve demonstrar seu compromisso com a adaptação e
implementação da política. Isso inclui o compromisso de entregar previsto
resultados a partir de qualquer mudar nos Serviços.
• Usar processos que integram as equipes; competências mistura,
mantendo linhas claras de prestação de contas e responsabilidade.
• Entregar mudanças no liberars.
• Endereço desenvolvimento no início da libertação projeto e liberação
planejamento fases.
O melhor prática:
• Obter aprovação formal-off da equipe de gestão, patrocinadores e
tomadores de decisão envolvidos no desenvolvimento da política.
3.2.2 Implementar todas as alterações aos serviços através de
Política:

• Todas as mudanças no Portfólio de Serviços ou catálogo de serviços são
implementadas através de Gestão da Mudança e as mudanças que são
gerenciados pelo Transição de Serviço ciclo de vida etapa são definidos e
acordados.
Princípios:
• Um único ponto focal para as alterações aos serviços de produção
minimiza a probabilidade de alterações em conflito e ruptura potencial
para o ambiente de produção.
• As pessoas que não têm autoridade para fazer uma mudança ou liberar
na ambiente de produção devem ser impedidos de ter acesso.
• Familiaridade com o Operação de Serviçosorganização aumenta a
mobilização e permite organizacional mudar.
• Aumentar o conhecimento e experiência dos serviços e ambiente de
produção melhora eficiência.
• Cada pacote de lançamento será projetado e regido por um Requisição
de Mudança levantadas através da Gestão da Mudança processo para
garantir a efectiva controlar e rastreabilidade.
• Métodos padronizados e procedimentos são utilizadas para o tratamento
rápido e eficiente de todas as alterações, de modo a minimizar o impacto
de mudança relacionada incidentes sobre continuidade de negócios,
serviço de qualidade e re-trabalho.
• Todas as atualizações para mudanças e lançamentos são registrados
contra serviço ativos e / ou item de configuraçãos no Sistema de
Gerenciamento da Configuração.
Melhores práticass:
• A definição de uma mudança é claramente definida.
• Mudanças internas e externas são diferenciadas.
• As alterações são justificadas por meio do desenvolvimento de um claro
Business Case.
• Alterações aos serviços são definidos em um Pacote de Desenho de
Serviço que Transição de Serviço pode usar para medir o real vs previsto
progresso e atuação.
• O actual Gestão da Mudança processo pode precisar de ser normalizada
e aplicada.
• Compromisso de gestão para cumprir a processo é essencial, e deve ser
claramente visível para todos das partes interessadass.
• Auditoria de configuração visa identificar alterações não autorizadas.
• Não aceite pedidos atrasados para alterações que não podem ser
devidamente geridos.

3.2.3 Adoptar um quadro comum e normas
Política:
• Base Transição de Serviço relativa a um quadro comum de padrão
reutilizáveis processos e sistemas para melhorar a integração das partes
envolvidas na Transição de Serviço e reduzir as variações nos processos.
Princípios:
• Implementar as melhores práticas da indústria, como a base de
padronização para permitir a integração entre o cadeia de suprimentos.
• Controlar o quadro Transição de Serviço e padrãos em Alterar e
• Garantir que os processos são adotadas de forma consistente pelo
agendamento normal revers e auditars da Serviço de Gestão de
processos.
Melhores práticas:
• Publicar padrões e melhores práticas para a Transição de Serviço.
• Fornecer um quadro para o estabelecimento de processos consistentes
para garantir e avaliar o serviço capacidade e risco perfil, antes e depois
de um liberar é implantado.
• Fornecer sistemas de suporte para automatizar processos padrão, a fim
de reduzir a resistência à adoção.
• Certifique-se de que há conhecimento de gestão da necessidade de
formas padrão de trabalho de desenvolvimento e fornecimento de
melhoramentos baseados em um som Business Case.
• Estabelecer o nível de gestão e das partes interessadas compromisso e
tomar medidas para colmatar eventuais lacunas.
• Planejar continuamente como melhorar o buy-in a adopção de um quadro
comum e padrões.
3.2.4 Maximizar a reutilização de processos e sistemas
consagrados
Política:
• Processos de transição de serviços estão alinhados com os processos da
organização e relacionado sistemas para melhorar eficiência e eficácia e
onde novos processos são necessários, eles são desenvolvidos com a
reutilização em mente.
Princípios:

• Re-uso de processos e sistemas estabelecidos, sempre que possível.
• Captura de dados e informações da fonte original para reduzir erros e
eficácia da ajuda.
• Desenvolver reutilizável Transição de Serviço padrão modelos para
construir experiência e confiança nas atividades de Transição de Serviço.
• Implementar indústria padrãos e melhores práticass como a base de
normalização, para permitir a integração de entregas de muitos
fornecedors.
Melhores práticas:
• Integrar o Transição de Serviço processos para a sistema de gestão da
qualidade.
• Usar o organização'S programa e projeto práticas de gestão.
• Utilizar os canais existentes de comunicação para comunicação
Transição de Serviço.
• Siga humana recursos, treinamento, finanças e gestão de instalações
processos e práticas comuns.
• Projetar a Transição de Serviço modelos que permitem uma fácil
personalização para atender às circunstâncias específicas.
• Modelos de estrutura de tal forma que uma abordagem consistente é
repetido para cada unidade de serviço alvo ou ambiente com variação
local, conforme necessário.
3.2.5 Alinhar os planos de transição de serviços com as
necessidades do negócio
Política:
• Alinhe Transição de Serviço planos e novos ou alterados serviço com a
cliente e negócio organizaçãoRequisitos 's, de modo a maximizar o valor
entregue pelo mudar.
Princípios:
• Definir cliente e usuário expectativas durante transição em como a
atuação e a utilização do serviço novo ou modificado pode ser utilizado
para permitir a mudança de negócios.
• Fornecer informações e estabelecer processos para permitir que os
projectos empresariais de mudança e clientes para integrar um liberar na
sua processo de negócioes e serviços.
• Certifique-se de que o serviço pode ser utilizado de acordo com a
exigências e as restrições especificadas dentro dos requisitos de serviço,
a fim de melhorar o cliente e das partes interessadas satisfação.

• Comunicar e transferir conhecimento para os clientes, usuários e das
partes interessadas, a fim de aumentar a sua capacidade para maximizar
o uso do serviço novo ou alterado.
• Monitorar e medir a utilização dos serviços e subjacentes aplicaçãos e
soluções de tecnologia durante desenvolvimento e apoio início da vida a
fim de assegurar que o serviço está bem estabelecida antes da transição
fecho.
• Comparar o desempenho real dos serviços após uma transição em
relação ao desempenho previsto definido no Design de Serviços com o
objectivo de reduzir as variações na capacidade de serviço e de
desempenho.
Melhores práticas:
• Adotar programas e gerenciamento de projetos de melhores práticas para
planejar e gerir o recursos exigido para embalagem, construir, Testar e
implementar um lançamento em produção com sucesso dentro do
previsto custar,qualidade e estimativas de tempo.
• Fornecer clara e abrangente planos que permitem que o cliente e negócio
mudar projetos para alinhar suas atividades com os planos de transição
de serviços.
• Gerir das partes interessadas compromisso e de comunicações.
3.2.6 Estabelecer e manter relações com as partes interessadas
Política:
• Estabelecer e manter relaçãos com clientes, representantes do cliente,
usuários e fornecedors ao longo Transição de Serviço a fim de definir as
suas expectativas sobre o serviço novo ou alterado.
Princípios:
• Defina expectativas das partes interessadas sobre a forma como o
atuação e a utilização do serviço novo ou modificado pode ser utilizado
para permitir o negócio mudar.
• Comunicar as alterações a todos os interessados, a fim de melhorar a sua
compreensão e conhecimento do serviço novo ou alterado.
• Fornecer a boa qualidade do conhecimento e informações para que os
interessados podem encontrar informações sobre a Transição de Serviço
facilmente, por exemplo liberar e desenvolvimento planos e
documentação de liberação.

• Verifique com as partes que o serviço novo ou modificado pode ser
utilizado de acordo com a exigências e restrições especificadas no
serviço requisitos.
• Transição de Serviço e compartilhar planos de lançamento e todas as
alterações com as partes interessadas.
• Trabalhar com gestão de relacionamento de negócios e gerenciamento
de nível de serviço para construir relacionamentos com clientes e partes
interessadas durante a Transição de Serviço.
3.2.7 Estabelecer controles eficazes e disciplinas
Política:
• Estabelecer adequado controlars e disciplinas de todo o serviço ciclo de
vida para permitir o bom transição de mudanças e liberações de serviços.
Princípios:
• Estabelecer e manter o integridade de todos identificados serviço ativos e
configurações à medida que evoluem através do estágio de Transição de
Serviço.
• Automatizar auditar actividades, se for vantajoso, a fim de aumentar o
detecção de alterações não autorizadas e discrepâncias nas
configurações.
• Definir claramente "quem faz o quê, quando e onde" a todos pontos de
entrega para aumentar a prestação de contas para entrega contra os
planos e processos.
• Definir e comunicar papéis e responsabilidades para entrega e aceitação
através da Transição de Serviço (por exemplo, actividades construir,
Teste liberar e desenvolvimento) Para reduzir erros resultante de mal-
entendidos e falta de propriedade.
• Estabelecer transaçãoBaseados em processos para a mudança de
configuração, e gestão de problemas para fornecer um auditar trilha e do
gestão da informação necessária para melhorar a controlars.
Melhores práticas:
• Garantir papéis e responsabilidades são bem definidos, mantido e
compreendido por aqueles que estão envolvidos e mapeados para todos
os processos relevantes para as circunstâncias atuais e previstas.
• Atribuir pessoas a cada papel e manter a atribuição na serviço de sistema
de gestão do conhecimento (SGCS) ou Sistema de gerenciamento de
configuração (CMS) para fornecer visibilidade da pessoa responsável
para determinadas atividades.
• Implementar integrado incidente,problema, A mudança, os processos de
gerenciamento de configuração com gerenciamento de nível de serviço

para medir a qualidade de item de configuraçãos durante o serviço ciclo
de vida.
• Garantir que o serviço pode ser gerenciado, operado e apoiadas em
conformidade com o exigências e restrições especificadas dentro do
Design de Serviços pela provedor de serviços organização.
• Garantir que apenas o pessoal competente pode implementar mudanças
para teste controlado ambientes e serviços de produção.
• Realizar auditorias de configuração e processo auditorias para identificar
discrepâncias de configuração e não-conformidade que podem impactar
Transições de Serviço.
3.2.8 Oferecer sistemas de transferência de conhecimento e
apoio à decisão
Política:
• Transição de Serviço desenvolve sistemas e processos de transferência
de conhecimento para a efetiva operação do serviço e permitir que as
decisões sejam tomadas na hora certa pelos tomadores de decisão
competentes.
Princípios:
• Fornecer dados de qualidade, informação e conhecimento no momento
certo para as pessoas certas para reduzir o esforço gasto à espera de
decisões e consequentes atrasos.
• Verifique se há formação adequada e transferência de conhecimento para
usuários para reduzir o número de chamadas que a formação balcão de
atendimento alças.
• Melhorar a qualidade das informações e dados para melhorar usuário e
das partes interessadas satisfação, otimizando o custar de produção e de
manutenção.
• Melhorar a qualidade da documentação para reduzir o número de
incidentes e problemas causados pela baixa qualidade documentação do
usuário, lançamento, implantação, suporte ou operacional documentação.
• Melhorar a qualidade de libertação e desenvolvimento documentação
para reduzir o número de incidentes e problemas causados pela má
qualidade documentação do usuário, ou o tempo de documentação de
suporte operacional entre mudanças que estão sendo implementadas e
da documentação que está sendo atualizado.
• Facilitar o acesso a informação de qualidade para reduzir o tempo gasto
na busca e localização de informações, particularmente durante as
atividades essenciais, como manusear um incidente grave.
• Estabelecer a fonte definitiva de informações eo compartilhamento de
informações em todo o serviço ciclo de vida e com as partes interessadas

por forma a maximizar o qualidade de informação e de reduzir o despesas
gerais na manutenção de informações.
• Fornecer informação consolidada para permitir a mudança,
Gerenciamento de Liberação e Implantação para agilizar decisões
efetivas sobre a promoção de uma liberar através da ambiente de testes e
em produção.
Melhores práticas:
• Fornecer ferramentas fáceis de apresentação, acesso e informação para
o SKMS e CMS em ordem.
• Proporcionar qualidade usuário interfaces e ferramentas para o SKMS e
CMS para pessoas diferentes e papéis para tomar decisões em
momentos apropriados.
• Resumir e publicar os efeitos previstos e imprevistos de mudar, Desvios
vs real previsto capacidade e atuação em conjunto com o risco perfil.
• Garantir Ativo de Serviço e Gerenciamento de Configuração informação é
exata para acionar aprovação e notificação transaçãos para tomada de
decisão através de ferramentas de fluxo de trabalho, por exemplo,
alterações, aceitação de entregas.
• Proporcionar conhecimento, informação e dados para
desenvolvimento,balcão de atendimento, Operações e equipes de apoio
para resolver os incidentes e erros.
3.2.9 Plano de liberação e implantação de pacotes
Política:
• Pacotes de lançamento são planejado e projetado para ser construído,
testado, entregues, distribuído e implementado no viver ambiente de
maneira que fornece os níveis acordados de rastreabilidade, de uma
forma rentável e eficiente.
Princípios:
• A política de liberação é acordado com o negócio e todas as partes
relevantes.
• Lançamentos são planejadas com antecedência.
• Recurso utilização é otimizard em Transição de Serviço actividades para
reduzir custos.
• Os recursos são coordenados durante a liberação e implantação.
• Mecanismos de liberação e distribuição são planejadas para garantir a
integridade de componentes durante a instalação, manuseamento,
embalagem e entrega é mantida.
• Lançamentos de emergência são geridas de acordo com o mudança de
emergência procedimento.

• O riscos de recuar ou remediar uma falha liberar são avaliados e geridos.
• O sucesso ea falha do liberarpacotes s é medida com o objectivo de
melhorar eficácia e eficiência além de otimizar os custos.
Melhores práticas:
• Todas as atualizações para versões são registrados no Sistema de
• Definitivo versãos de meios eletrônicos, incluindo software, são
capturados em um Biblioteca de Mídia Definitiva antes da liberação para a
preparação de operações de serviço ambiente de teste.
• Gravar a liberação planejada e desenvolvimento datas e entregas com
referências a relacionada mudar pedidos e problemas.
• Procedimentos comprovados para o manuseio, distribuição, entrega de
lançamento e implantação de pacotes, incluindo verificação.
• Pré-requisitos e co-requisitos para um lançamento são documentados e
comunicados às partes relevantes, por exemplo, técnico exigências para
o ambiente de teste.
3.2.10 Antecipar e gerenciar correções de curso
Correções de curso
Ao traçar uma rota longa para um navio ou aeronave, hipóteses será feita sobre
ventos, clima e outros fatores, e planos preparados para a jornada. Verificações
ao longo do caminho - observações com base nas condições reais vividas -
exigirá (geralmente menor) alterações para garantir o destino seja alcançado.
Bem sucedido transição é também uma viagem - a partir do 'como é' Estado
dentro de um organização para o "como obrigatório 'estado. No mundo dinâmico
em que IT Service Management funções, é muitas vezes o caso de que fatores
surgir entre inicial projeto de um serviço alterado ou novo e sua transição. Isso
significa a necessidade de 'correções de curso"Para que a jornada de Transição
de Serviço, alterar o original Design de Serviços planejado curso de ação para o
destino que o cliente precisa para chegar.
Política:
• Treinar os funcionários para reconhecer a necessidade de correções de
rumo e capacitá-los a aplicar variações necessárias dentro dos limites
estabelecidos e compreendidos.
Princípios:
• Construir das partes interessadas expectativa de que as alterações
planos são necessárias e incentivadas.

• Aprenda com anterior correções de curso para predizer os do futuro e
voltar a usar abordagens de sucesso.
• Debrief e propagar conhecimento através de fim-de-transição sessões de
esclarecimento e tirar conclusões disponível através do serviço de
sistema de gestão do conhecimento.
• Gerenciar correções de curso através de adequada Gestão da Mudança e
linha de base procedimentos.
Melhores práticas:
• Usar projeto práticas de gestão e gestão da mudança processo para
gerenciar correções de rumo.
• Documento e mudanças de controle, mas sem fazer o processo
burocrático (que deve ser mais fácil de fazê-lo direito do que lidar com as
consequências de fazê-lo errado).
• Fornecer informações sobre as alterações que foram aplicadas após a
linha de base de configuração foi estabelecida.
• Envolver das partes interessadass sobre muda quando apropriado, mas
gerenciar as questões e riscos dentro Transição de Serviço quando
apropriado.
3.2.11 proativamente gerenciar recursos através Transitions
Serviço
Política:
• Fornecer e gerenciar compartilhada e especialista recursos em todas as
actividades Transição de Serviço para eliminar os atrasos.
Princípios:
• Reconhecer o recursos, habilidades e conhecimentos necessários para
entregar Transição de Serviço dentro do organização.
• Desenvolver uma equipe (incluindo os recursos provenientes
externamente) capaz de implementação bem sucedida da Transição de
Serviço estratégia,Pacote Service Design e liberar pacote.
• Estabelecer recursos dedicados para executar atividades críticas para
reduzir os atrasos.
• Estabelecer e gerenciar recursos compartilhados para melhorar a eficácia
e eficiência de Transição de Serviço.
• Automatizar processos repetitivos e propenso a erros para melhorar a
eficácia e eficiência das atividades-chave, por exemplo, distribuição,
construir e instalação.
Melhores práticas:

• Trabalhar com recursos humanos (RH), gestão de fornecedores etc, para
identificar, gerenciar e fazer uso dos recursos competentes e disponíveis.
• Reconhecer e usar recursos competentes e especialista de fora da equipe
ITSM núcleo para entregar Transição de Serviço.
• Gerenciar proativamente compartilhada recursos para minimizar a
impacto que os atrasos em um transição ter em outra transição.
• Medir o impacto do uso de recursos dedicados vs não dedicado sobre os
atrasos, por exemplo, usando a equipe de operações que são desviados
para corrigir incidente graves, com problemas de agendamento teste
instalações.
3.2.12 garantir a participação precoce no ciclo de vida do
serviço
Política:
• Estabelecer adequado controlars e disciplinas para verificar na fase mais
precoce possível no serviço ciclo de vida que um novo ou modificado
serviço será capaz de proporcionar o valor requerido.
Princípios:
• Usar uma variedade de técnicas para maximizar culpa detecção no início
do ciclo de vida de serviço, a fim de reduzir o custar de retificação. (O
mais tarde no ciclo de vida do que uma erro for detectado, maior o custo
de rectificação.)
• Identificar as alterações que não vai entregar os benefícios esperados e
quer mudar o serviço exigências ou parar o mudar antes que os recursos
são desperdiçados.
• Envolver os clientes ou representantes de clientes em serviço aceitação
teste planejamento e teste projeto para entender como para validar que o
serviço irá agregar valor ao cliente da processo de negócioes e serviços.
• Envolver usuários em planejamento de testes e design, sempre que
possível. Base de testes de como os usuários realmente trabalhar com
um serviço - e não apenas como os designers pretendia que fosse
utilizado.
• Usar a experiência anterior para identificar erros na Design de Serviços.
• Construir em - na fase mais precoce possível - a capacidade de verificar e
demonstrar que um serviço novo ou alterado será capaz de fornecer o
valor que lhe é exigido.
• Use um independente avaliação do Design de Serviços e internos
auditars para determinar se a riscos de progredir são aceitáveis.

3.2.13 Garantir a qualidade do serviço novo ou alterado
Política:
• Verificar e validar que as alterações propostas para o operacional
serviços definidos no serviço e liberar definições de serviço, modelo e
Pacote de Desenho de Serviço pode entregar os requisitos de serviço
necessários e negócio benefícios.
Princípios:
• Transição de Serviço é responsável por assegurar que as alterações
propostas para o operacional serviços podem ser fornecidos de acordo
com a acordos, especificaçãos e planos dentro de níveis de confiança
acordados.
• Garantir que as equipes de transição de serviços entender o que os
clientes e negócio realmente necessitam de um serviço para melhorar a
cliente e usuáriosatisfação s '.
• Garantia de qualidade e práticas de teste fornecem um método
abrangente para assegurar a qualidade e riscos de serviços novos ou
alterados.
• Ambiente de testes precisam refletir a viver ambiente para o maior grau
possível, a fim de otimizar os esforços de teste.
• Teste projeto e execução devem ser geridos e entregues de forma
independente do serviço de designer e desenvolvedor, a fim de aumentar
a eficácia de testes e atender qualquer tipo de "segregação do dever"
exigências.
• Realize independente avaliaçãos da Design de Serviços eo serviço novo
ou alterado para identificar os riscos que precisam ser gerenciados e
mitigados durante construir,teste,desenvolvimento e uso do serviço - ver
secção 4.6.
• Executar problema e Gerenciamento da Configuração processos em todo
o serviço ciclo de vida de modo a medir e reduzir o erro conhecidos
causados por aplicação liberars em produção.
Melhores práticas:
• Entenda o de negócios processo e prioridades - isso muitas vezes requer
uma compreensão de sua cultura, Língua, costumes e clientes.
• Compreensivo das partes interessadas envolvimento é importante tanto
para o teste eficaz e para construir a confiança dos stakeholders, e assim
deve ser visível em toda a comunidade interessada.
• Compreender as diferenças entre a construção de teste, e ambiente de
produçãos, a fim de gerir as diferenças e melhorar a capacidade de
prever o comportamento de um serviço.

• Ambientes de teste são mantidos sob Change and Configuration
Management, e sua relevância é considerado diretamente como parte de
qualquer mudar.
• Estabelecer o serviço atual linha de base e a Design de Serviços linha de
base antes de avaliação da mudança.
• Avaliar o previsto capacidade, A qualidade e os custos do Design de
Serviços tendo em conta os resultados da experiência anterior e feedback
das partes interessadas antes do lançamento e implantação.
• Considere as circunstâncias que vai realmente estar no local quando
Transição de Serviço é completa, e não apenas o que era esperado na
fase de concepção.
3.2.14 proativamente melhorar a qualidade durante a Transição
de Serviço
Política:
• A planejar e melhorar a qualidade do serviço novo ou alterado durante
transição.
Princípios:
• Detectar e resolver incidentes e problemas durante transição para reduzir
a probabilidade de erros que ocorrem durante o operacional fase e
directamente afectar adversamente operações comerciais.
• Gerenciar de forma proativa e reduzir incidentes, problemas e erros
detectados durante Transição de Serviço para reduzir custos, retrabalho e
os impacto no usuárioAs atividades empresariais.
• Alinhar a gestão de incidentes, problemas e erros durante a transição
com os processos de produção, a fim de medir e gerenciar o impacto e
custar de erros de todo o serviço ciclo de vida facilmente.
Melhores práticas:
• Compare vs real previu serviço capacidade,atuação e custos durante
pilotos e apoio início da vida a fim de identificar quaisquer desvios e
riscos que podem ser removidos antes de Transição de Serviço fecho.
• Executar uma independente avaliação dos novos ou alterados serviço
para identificar o risco perfil e priorizar a riscos que precisam ser
mitigados antes do encerramento de transição, por exemplo, riscos de
segurança que podem afetar as garantias.
• Utilizar o perfil de risco a partir da avaliação do Design de Serviços para
desenvolver com base em risco testes.
• Fornecer e testar as ferramentas de diagnóstico e ajudas com o balcão de
atendimento, Operações e pessoal de apoio para garantir que, se algo
der errado em testes ou viver uso em produção, é relativamente simples

de obter informação chave que ajuda a diagnosticar o problema sem
impactar muito no usuário.
• Incentivar a fertilização cruzada de conhecimentos entre transição e
operação estágios para melhorar diagnósticos de problemas e resolução
tempo, e.g. solução alternativas e correções.
• Estabelecer transição incidente, Erro de problema, e resolução
procedimentoe s medidas que reflictam os utilizados no viver ambiente.
• Fixar erro conhecidos e resolver incidentes, de acordo com a sua
prioridade para resolução.
• Documentar qualquer resolução, por exemplo, soluções alternativas, de
modo que a informação possa ser analisada.
• Proativamente analisar o causa raiz de alta prioridade e incidentes
repetidos.
• Registrar, classificar e mensurar o número eo impacto de incidentes e
problemas uns contra os liberar no teste, desenvolvimento e etapas de
produção, a fim de identificar oportunidades iniciais para corrigir erros.
• Comparar o número eo impacto de incidentes e problemas entre
implementações, a fim de identificar melhorias e corrigir quaisquer
problemas subjacentes que irão melhorar a usuário experimentar para
implementações posteriores.
• Atualize incidente e Gerenciamento de Problemas com soluções e
correções identificadas em transição.

4 de Transição de Serviço processos
Este capítulo estabelece os processos e atividades em que efetiva Transição de
Serviço Depende. Estes compreendem tanto ciclo de vida processos e os quase
inteiramente contido dentro Transição de Serviço. Cada um é descrito em
detalhes, que estabelece os elementos-chave de que processo ou atividade.
Os processos e atividades e de seus relaçãos são apresentados na Figura 2.3, e
os temas abordados especificamente neste capítulo são:
• Planejamento de transição e suporte
• Gerenciamento de Liberação e Implantação
• Serviço de validação e teste
• Avaliação
Alguns destes processos são utilizados em todo o ciclo de vida de serviço, mas
são contempladas na presente publicação, uma vez que são fundamentais para
a eficaz Transição de Serviço.
Os outros processos e atividades são mais contidos dentro da fase de Transição
de Serviço do ciclo de vida, mas também são feitas de utilização em outras
fases, por exemplo, avaliação de projeto, E atuação testes nas operações.
O escopo, Objetivos, propósitos e visão de Transição de Serviço como um todo
são definidas no ponto 2.4.

4.1 Planejamento de Transição e Suporte
4.1.1 Finalidade, objetivos e metas
A finalidade do Planejamento de transição e suporte atividades é:
• Plano adequado capacidade e recursos para embalar um comunicado,
construir, Lançamento, teste, Implantar e estabelecer o serviço novo ou
alterado em produção
• Fornecer suporte para as equipes de serviço de transição e as pessoas
• Planejar as mudanças necessárias de forma que garanta a integridade de
todos os clientes identificados ativoss, serviço ativos e configurações
podem ser mantidas como eles evoluem através de Transição de Serviço
• Garantir que as questões de Transição de Serviço, riscos e os desvios
são relatados para o adequado das partes interessadastomadores de
decisão e s
• Coordenar as atividades em projetos, fornecedors e equipes de serviço
quando necessário.
Os objetivos do planejamento de transição e suporte são:
• Planejar e coordenar a recursos para garantir que os requisitos da
Estratégia de Serviço codificado em Design de Serviços são efetivamente
realizados em Operação de Serviços
• Identificar, gerenciar e controlar o riscos de falha e perturbação através
transição actividades.
O objetivo de Planejamento de transição e suporte é a seguinte:
• Planejar e coordenar os recursos para estabelecer com sucesso um novo
ou alterado serviço em produção dentro do previsto custar,qualidade e
estimativas de tempo
• Assegurar que todas as partes adotar o quadro comum de padrão
reutilizáveis processos e apoiar sistemas, a fim de melhorar a eficácia e
eficiência do integrado planejamento e actividades de coordenação
• Fornecer clara e abrangente planos que permitem que o cliente e negócio
mudar projetos para alinhar suas atividades com a Transição de Serviço
planos.
4.1.2 Âmbito
O escopo do Serviço Planejamento de transição e suporte atividades inclui:
• Projeto e incorporando operação requisitos para os planos de transição
• Gestão e operação de planejamento de transição e suporte as atividades

• Manutenção e integração Transição de Serviço planeja através do cliente,
serviço e carteira de contratoss
• Progresso da transição Serviço de Gestão, mudanças, problemas, riscos
e desvios
• Qualidade rever de todos Transição de Serviço, liberar e desenvolvimento
planos
• Sistemas de gestão e operação dos processos de transição, apoio e
ferramentas
• Comunicação com os clientes, usuários e das partes interessadass
• Monitoramento e melhorar Transição de Serviço atuação.
Planejamento de transição e suporte eficaz pode melhorar significativamente a
provedor de serviçosCapacidade é para lidar com grandes volumes de mudar e
libera toda a sua base de clientes. Uma abordagem integrada de planejamento
melhora o alinhamento da Transição de Serviço planeja com o cliente,
fornecedor e planos de negócios projeto de mudança.
4.1.4 Políticas, princípios e conceitos básicos
Esta seção apresenta conceitos básicos dentro de que o apoio para a efetiva
planejamento de Transição de Serviço.
Design de Serviços vai - em colaboração com os clientes, fornecedores externos
e internos e outras partes interessadas - desenvolver o Design de Serviços e
documentá-lo em um Pacote de Desenho de Serviço (SDP). A SDP inclui a
seguinte informação que é exigido pela Transição de Serviço equipe:
• O aplicável pacote de serviçoss (por exemplo, Pacote de serviços do
núcleo,Pacote de Nível de Serviço)
• O serviço especificaçãos
• O serviço modelos
• A arquitectura projeto obrigado a entregar o serviço novo ou modificado,
incluindo restrições
• A definição e concepção de cada liberar pacote
• O projeto detalhado de como o serviço componentes será montado e
integrado a um pacote de lançamento
• Solte e desenvolvimento planos
• O Critérios de aceitação de serviços.
4.1.4.1 política de Transição de Serviço
Políticas de apoio Transição de Serviço são fornecidos no Capítulo 3.

A Mudança, Configuração e Gestão do Conhecimento políticas também apoiar
Transição de Serviço e mais exemplos destes são fornecidos nas seções 4.2,
4.3 e 4.7.
4.1.4.2 política de Lançamento
O lançamento política devem ser definidos para um ou mais serviços e incluem:
• A identificação única, numeração e convenções de nomenclatura para os
diferentes tipos de liberação juntamente com uma descrição
• Os papéis e responsabilidades de cada etapa no lançamento e
implantação processo
• A frequência esperada para cada tipo de libertação
• A abordagem para aceitar mudanças e agrupamento em um comunicado,
por exemplo, como melhorias são priorizados para a inclusão
• O mecanismo para automatizar os processos de distribuição de
instalação de construção e liberação para melhorar a reutilização,
repetibilidade e eficiência
• Como a configuração linha de base para a libertação é captada e
verificada contra os conteúdos, por exemplo, de libertação reais
hardware, software, documentação e conhecimento
• Critérios de entrada e saída e autoridade para aceitação de colocação em
cada etapa Transição de Serviço e na controlada teste, Desastre,
formação recuperação e ambiente de produçãos
• Critérios e de autorização para sair apoio início da vida e entrega de
Operação de Serviços.
Um comunicado que consiste em muitos tipos diferentes de serviço ativos pode
envolver muitas pessoas, muitas vezes, de diferentes organizações. As
responsabilidades típicas de entrega e aceitação de um comunicado deve ser
definido e, em seguida, eles podem ser modificados conforme necessário para
transições específicas. As principais funções e responsabilidades nos pontos de
entrega devem ser definidos para garantir que todos entendam a sua papel e
nível de autoridade e dos outros envolvidos no liberar e desenvolvimento
processo.

Um exemplo de uma matriz da responsabilidade de um organização que suporta
cliente-servidor aplicaçãos é mostrada na Tabela 4.1. Essa matriz vai ajudar a
identificar lacunas e sobreposições e funções típicas pode ser planejado para o
futuro.
Desenvolvimento Teste
controlado
Liberação para a
produção
Produção
Classe de
objeto
Liberado Aceito por Autoridade para
liberar a viver
Aceito e apoiado
por
Pacote
comprado
Aplicação
desenvolvimento
gerente
Teste gerente Mudar gerente Gerente de
operações
Módulos
customizados
Gerente de
desenvolvimento
de aplicativo
Test Manager Alterar gerente Gerente de
operações
Alterações de
dados físicos
Gerente de
desenvolvimento
de aplicativo
Administrador
de banco de
dados
Alterar gerente Administrador
de banco de
dados
Servidor Servidor construtor O gestor do
servidor
Alterar gerente O gestor do
servidor
Área de
trabalho
construir (Por
exemplo, a
aplicação de
um novo)
Área de trabalho
gerente de
desenvolvimento
Test Manager Alterar gerente Gerente de
suporte de
desktop
Aplicação
desktop (já
construído e
dentro
operacional
restrições)
Área de trabalho
gerente de
desenvolvimento
Gerente de
suporte de
desktop
Área de trabalho
gerente de suporte,
gerente de
mudança
Gerente de
suporte de
desktop
Computadores
desktop
Logística Suporte de
desktop
Área de trabalho
gerente de suporte,
gerente de
mudança
Gerente de
suporte de
desktop
Área de
trabalho do
serviço
Serviço
desenvolvimento
Suporte de
desktop
Gerenciamento de
nível de serviço,
Gerente de suporte
de desktop, mudar
gerente
Gerenciamento
de nível de
serviço, gerente
de suporte de
desktop
Lançamento /
Alterar
autorização
Gerente de
desenvolvimento
de
Test Manager Gerente de
lançamentos,
gerente de teste,
gerente de
Balcão de
atendimento
usuários

operações, área de
trabalho de serviços
de apoio, mesa
usuário em cada
local do cliente, das
partes interessadas,
Gerente de
mudança
Tabela matriz de responsabilidades 4,1 Exemplo de pontos de lançamento durante a
Todos os lançamentos devem ter um identificador exclusivo que pode ser usado
por Gerenciamento da Configuração e documentação padrãos. Os tipos de
liberar deve ser definido como o que ajuda a definir cliente e das partes
interessadas expectativas sobre as liberações planejadas. Um exemplo típico é
o seguinte:
• Grandes lançamentos, Normalmente contendo grandes áreas de uma
nova funcionalidade, alguns dos quais podem eliminar correções
temporárias problemas. Uma grande atualização ou liberação geralmente
substitui todas as atualizações anteriores menores, lançamentos e
correções de emergência.
• As versões menores, Normalmente com pequenas melhorias e
correções, alguns dos quais podem já ter sido emitido como correções de
emergência. Uma pequena atualização ou a liberação geralmente
substitui todas as correções de emergência anteriores.
• Lançamentos de emergência, Contendo normalmente as correcções
para um pequeno número de erro conhecidos ou, por vezes, um
aprimoramento para atender uma exigência do mercado de alta
prioridade.
Um comunicado política Pode-se dizer, por exemplo, que apenas estritas
"correções de emergência" será emitido entre versões formalmente planejadas
de melhorias e não urgentes correções.

Um extracto de uma política de libertação é apresentado na Tabela 4.2, que
mostra como os diferentes tipos de libertação pode ser definido.
SERVIÇO Lançamento *
definição
Nomeando /
Numeração
Frequência /
Ocorrência
Janela de lançamento
Loja de
serviço
Tipo A
Tipo B ou C
Emergência
SS_x
SS_1.x ou
SS_1.1.x
SS_1.1.1.x
Anual
(fevereiro)
Trimestral
Conforme
requerido
Quarta-feira 01.00-
04.00 horas
Nem finais de semana
de férias
Não 1 setembro - 31
janeiro
e-store
serviço web
Tipo A
Tipo B e C
Emergência
ESWnnn_x
ESWnnn_1.x
ESWnnn_1.1.x
6 meses
Mensal
Conforme
requerido
01.00-02.00 horas
Nem finais de semana
de férias
Não 1 outubro - 10
janeiro
e-loja serviço
de entrega
Tipo A
Tipo B
Tipo C
Emergência
ESDnnn_x
ESDSnnn_1.x
ESDnnn_1.1.x
ESDnnn_1.1.1.x
6 meses
Trimestral
Mensal
Conforme
requerido
01.00-02.00 horas
Mais alto nível de
autorização requerida
durante a semana de
férias
* Definições de Lançamento
Tipo A Algo que afeta a todo sistema/ Serviço
Tipo B A libertação que irá impactar parte do sistema, por exemplo, sub-sistema único
ou sub-serviço
Tipo C Correção para um único função
Emergência Amudar necessária para restaurar ou continuar a assegurar o serviço Acordo
de Nível de Serviço (SLA) é mantida
Extrato Tabela 4.2 a partir de uma política de liberação de serviços para uma
organização de varejo

4.1.5 as atividades de processo, métodos e técnicas
4.1.5.1 estratégia de transição
O organização deve decidir a abordagem mais adequada para Transição de
Serviço com base no tamanho e da natureza do núcleo e serviços de apoios, o
número e frequência de liberars necessário, e todas as necessidades especiais
do usuários - por exemplo, se uma implantação em fases é geralmente
necessária durante um período prolongado de tempo.
A Transição de Serviço estratégia define a abordagem geral para a organização
e alocação de Transição de Serviço recursos. Os aspectos a considerar são:
• Propósito, metas e objetivos da Transição de Serviço
• Contexto, por exemplo, serviço cliente,carteira de contratoss
• Escopo - Inclusões e exclusões
• Aplicável padrãos, acordos, legais, regulamentares e contratuais
exigências:
• Normas internas e externas
• Interpretação da indústria legislação, diretrizs e outros requisitos
impostos externamente
• Acordos e contratos que se aplicam a Transição de Serviço
• Organizações e das partes interessadass envolvidas em transição:
• Terceiros, parceiros estratégicos, fornecedors e provedor de
serviçoss
• Os clientes e usuários
• Serviço de Gestão de
• Provedor de serviços
• Organização de transição (ver secção 6.2)
• Quadro para a Transição de Serviço:
• Políticas, processos e práticas aplicáveis a Transição de Serviço
incluindo processo interface do provedor de serviços (SPI)
• Papéis e responsabilidades
• Recurso de transição planejamento e estimativa
• Preparação de transição e requisitos de formação
• A liberação e mudar autorização
• Re-utilizando o organizaçãoExperiência 's, perícia, ferramentas,
conhecimentos e dados históricos relevantes
• Recursos compartilhados e serviço para apoiar a Transição de
Serviço
• Critérios:
• De entrada e saída critérios para cada liberar etapa
• Critérios para parar ou re-iniciar transição atividades
• Sucesso e falha critérios
• Identificação de exigências e conteúdo do serviço novo ou alterado:

• Serviços a transição com locais-alvo, clientes e unidades
organizacionais
• Definições de libertação
• SDP aplicável, incluindo arquitectura projeto
• Requisitos para ambientes para ser usado, locais, organizacionais
e técnicos
• Planejamento e gestão de ambientes, por exemplo,
comissionamento e descomissionamento
• Pessoas:
• Atribuição de funções e responsabilidades, incluindo aprovações
• Atribuir e agendar treinamento e transferência de conhecimento
• Abordagem:
• Transição modelo incluindo Transição de Serviço ciclo de vida
estágios
• Planos para as mudanças de gestão, ativoss, configurações e
conhecimentos
• Linha de base e avaliação pontos
• Configuração auditar e verificação pontos
• Pontos onde RFCs devem ser levantadas
• Utilização de mudar de janelas
• Transição estimativa,recurso e custar planejamento
• Preparação para a Transição de Serviço
• Avaliação
• Embalagens de lançamento, construir,desenvolvimento e apoio
início da vida
• Erro correcção de manuseamento, e controlar
• Gestão e controlo - Gravação de progresso, monitoramento e
elaboração de relatórios
• Serviço atuação e medição sistema
• Indicador chave de desempenhos e metas de melhoria
• Deliverables a partir de transição actividades, incluindo a documentação
obrigatória e opcional para cada fase:
• Transição planos
• Alterar e Gerenciamento da Configuração Plano
• Solte política, Ea documentação
• Teste planos e relatórios
• Construir planos e documentação
• Avaliação plano e relatório
• Desenvolvimento planos e relatórios
• Transição fecho denunciar
• Cronograma de marcos
• Financeiro exigências - orçamentos e financiamento.
Serviço estágios do ciclo de vida de transição

O SDP deve definir o ciclo de vida fases para uma Transição de Serviço, Por
exemplo:
• Adquirir e testar entrada item de configuraçãos (IC) e componentes
• Construir e testar
• Serviço de teste de libertação
• Serviço operacional teste de prontidão
• Desenvolvimento
• Apoio início da vida
• Comente e transição de serviço perto.
Para cada fase, haverá saída e critérios de entrada e uma lista de obrigatório
entregas do palco.
4.1.5.2 Prepare-se para a Transição de Serviço
As atividades de preparação de Transição de Serviço incluem:
• Rever e aceitação de entradas das fases do ciclo de vida de serviços de
outros
• Analisar e verificar a entrada entregas, por exemplo, SDP, Critérios de
aceitação de serviços e avaliação relatório (ver parágrafo 4.6.6)
• Identificação, criação e programação de RFCs
• Verificando que a configuração linha de bases são registadas em
Gerenciamento da Configuração antes do início da Transição de Serviço
(ver parágrafo 4.3.4.2)
• Verificar a disponibilidade de transição.
As linhas de base de configuração ajudar a fixar um ponto na história em que as
pessoas podem referenciar e aplicar as alterações de uma maneira que é
compreensível. Qualquer variação ao proposto serviço escopo,Estratégia de
Serviço exigências e Design de Serviços linha de base deve ser solicitada e
conseguiu através do Gerenciamento de Mudança.
No mínimo, deve ser aceite (por projeto,transição e das partes interessadass)
que o projeto do serviço e todos os unidade de liberaçãos pode ser operado e
apoiado dentro dos limites previstos e ambiente. A avaliação atividade descrito
na seção 4.6 realiza a avaliação dos critérios de aceitação SDP e Serviço e
fornece um relatório de Gestão da Mudança com recomendações sobre se a
RFC deve ser autorizada.
4.1.5.3 Planejamento e coordenação Transição de Serviço
Planejamento de um indivíduo Transição de Serviço

O liberar e desenvolvimento atividades devem ser planejadas em etapas como
detalhes da implantação não pode ser conhecido em detalhes inicialmente.
Cada Transição de Serviço plano deve ser desenvolvido a partir de uma
Transição de Serviço comprovada modelo sempre que possível. Apesar de
Design de Serviços fornece o plano inicial, o planejador alocar específica
recursos para as atividades e modificar o plano de se encaixar com quaisquer
novas circunstâncias, por exemplo, um teste especialista pode ter deixado a
organização.
Um plano de Transição de Serviço descreve as tarefas e atividades necessárias
para liberar e implantar uma liberação para o ambiente de testes e em produção,
incluindo:
• Ambiente de trabalho e infra-estrutura para a Transição de Serviço
• Cronograma de marcos, entrega e prazos de entrega
• Atividades e tarefas a serem executadas
• Pessoal, as necessidades de recursos, orçamentos e escalas de tempo
em cada fase
• Questões e riscos para ser gerido
• Os prazos e de contingência.
Alocação de recursos para cada atividade e factoring em recursos
disponibilidade permitirá que o planejador Transição de Serviço para descobrir
se a transição pode ser implantado na data exigida. Se os recursos não estão
disponíveis, pode ser necessário rever outros compromissos de transição e
considerar a mudança de prioridades. Essas mudanças precisam ser discutidas
com a mudança e gerenciamento de liberação como isso pode afetar outras
mudanças que podem ser dependentes ou pré-requisitos do lançamento.
Planejamento integrado
Bom planejamento e gestão são essenciais para implantar uma liberação
através distribuídos ambientes e locais para a produção com sucesso. Um
conjunto integrado de transição planos, deve considerar-se que estão
relacionados com os planos de nível mais baixo, tais como libertação, construir e
teste de planos. Estes planos devem ser integrados com o alteração de horárioE
liberação de planos de implantação. Estabelecer boaqualidade planos no início
permite Transição de Serviço para gerenciar e coordenar os recursos Transição
de Serviço, por exemplo, alocação de recursos, utilização, orçamentação e
contabilidade.
Um plano abrangente de Transição de Serviço deve incluir as atividades de
marco para adquirir a liberação componenteO pacote, a liberação, construir,
Testar, implantar, avaliar e melhorar de forma proativa o serviço através apoio
início da vida. Ele também irá incluir as atividades de construir e manter os

serviços e Infra-estrutura de TI,sistemas e ambientes e o sistema de medição
para suportar as actividades de transição.
Adotar programas e práticas de projeto de manejo
É melhores práticas para gerenciar vários liberars e desenvolvimentos como um
programa, Com cada execução desenvolvimento significativo como um projeto.
A implantação real pode ser realizada por pessoal dedicado, como parte de
responsabilidades mais amplas, tais como operações ou através de uma equipe
reuniu para o efeito. Elementos da implantação pode ser entregue através
externo fornecedors, e os fornecedores podem fornecer a maior parte do esforço
de implantação, por exemplo, na aplicação de um off-the-shelf sistema como
uma ferramenta de apoio ITSM.
Implementações importantes serão projetos complexos em seu próprio direito.
Os passos a serem considerados na planejamento incluir a gama de elementos
que compõem esse serviço, por exemplo, pessoas, aplicação, Hardware,
software, documentação e conhecimento. Isto significa que a instalação irá
conter sub-implementações para cada tipo de elemento que compreende o
serviço.
Revisão dos planos de
O planejamento papel deveria qualidade rever todos Transição de Serviço,liberar
e implantação de planos. Sempre que possível, os prazos devem incluir um
elemento de contingência e basear-se na experiência e não apenas fornecedor
afirmação. Isto aplica-se ainda mais para os fornecedores internos onde não há
formais contrato. Prazos de entrega, normalmente variam sazonalmente e
devem ser tidos em conta o planejamento, especialmente para longas
calendários transições, onde os prazos de entrega pode variar entre os estágios
de um transição, Ou entre diferentes usuário locais.
Antes de iniciar o lançamento ou implantação, o serviço de função planejamento
da transição devem verificar os planos e fazer perguntas adequadas, tais como:
• São estes Transição de Serviço e liberar planos atualizado?
• Já os planos foi acordado e autorizado por todas as partes relevantes, por
exemplo, clientes, usuários, operações e pessoal de apoio?
• Será que os planos de incluir as datas de liberação e entregas e referem-
se relacionado mudar pedidos, erro conhecidos e problemas?
• Tem o impactos sobre os custos, aspectos organizacionais, técnicos e
comerciais foram considerados?
• Tem o riscos para os serviços e as operações globais capacidade foi
avaliado?

• Houve uma verificação de compatibilidade para garantir que o item de
configuraçãos que estão a ser libertados são compatíveis uns com os
outros e com item de configuraçãos nos ambientes-alvo?
• Tem circunstâncias mudaram de tal forma que a abordagem tem que
altera?
• Eram as regras e orientações sobre como aplicá-la relevante para o
serviço atual e pacotes de lançamento?
• Será que as pessoas que precisam usá-lo compreender e têm as
habilidades necessárias para usá-lo?
• É o lançamento do serviço dentro do SDP e escopo do que a transição
modelo endereços?
• Tem o Design de Serviços significativamente alterado de tal forma que
não é mais apropriada?
• Já possíveis mudanças nas circunstâncias de negócios foram
identificados? Veja o exemplo abaixo.
Antecipando circunstâncias de negócios alterados
Um novo versão de varejo organizaçãoPonto 's de venda sistema foi concebido
e preparado para transição ao operacional ambiente. Embora a nova versão
oferece recursos adicionais, a maioria das melhorias relacionadas com a
facilidade de uso, facilidade de suporte e manutenção do software. A transição
foi originalmente agendado para a instalação em setembro, mas atrasos na
terceiro fornecedors significava o serviço não está pronto para teste e
subsequente desenvolvimento no final de novembro, devido a instalação de
duas semanas após o teste de aceitação começa. A abordagem inicialmente
previsto de envolver 20% da usuário pessoal em testes de aceitação e
interrupção loja toda a base de usuários já não era apropriado. Com o boom de
vendas de Natal iminente, tal ruptura não era apropriado, e teria sido impedido
pelo anual mudar congelar. Em vez disso, um longo, lento, mas menos
recursoIntensivo abordagem de teste de aceitação foi selecionado com
lançamento para as lojas remarcada para o final de janeiro.
Em que a abordagem de transição exige repensar e alteração provável, este
deverá ser entregue através do formal Gestão da Mudança processo, Uma vez
que a consideração de alternativas e acordo da abordagem de transição revista
deve ser devidamente documentadas. No entanto, para os cenários previsíveis,
onde o caminho da ação está documentada como uma reação aceitou as
circunstâncias, a autoridade para gravar e prosseguir com uma mudança pode
ser delegada a Transição de Serviço ou outra parte apropriada para aprovação,
por exemplo, cliente ou projeto. Por exemplo, onde o serviço de datas marco de
transição, liberar datas pode ser conseguido com a mesma custar e recursos
sem impacto sobre a definição de serviço.

4.1.6 Fornecer suporte ao processo de transição
4.1.6.1 Orientação
Transição de Serviço devem dar suporte a todas das partes interessadass para
compreender e ser capaz de seguir o quadro Transição de Serviço de processos
e apoio sistemas e ferramentas. Embora o planejamento e equipe de apoio pode
não ter os recursos especializados para lidar com alguns aspectos, é importante
que eles podem identificar um recurso relevante para ajudar os projectos, por
exemplo, especialistas para configurar Gerenciamento da Configuração ou testar
ferramentas.
Os projetos devem implementar atividades de Transição de Serviço e tarefas de
acordo com Transição de Serviço aplicável padrãos, políticas e procedimentos.
No entanto, os gerentes de projeto nem sempre estão conscientes da
necessidade de adoptar estas normas, políticas e procedimentos. Quando novos
projetos começam a Transição de Serviço e planejamento e apoio papel deve
procurar activamente oportunidades para estabelecer os processos de transição
de serviços para o projeto rapidamente - antes de métodos alternativos são
adotadas. Outra abordagem é trabalhar em estreita colaboração com o
programa ou Projeto de Suporte e apoio a projetos oferta por esta via.
4.1.6.2 Administração
O Serviço Planejamento de transição e suporte papel deve proporcionar
administração por:
• Gestão de mudanças Transição de Serviço e ordens de serviço
• Questões de gestão, riscos, desvios e renúncias
• Apoio a gestão de ferramentas e Transição de Serviço processos
• As comunicações com das partes interessadass - e.g. logística e
desenvolvimento planos precisam ser comunicadas a todos os
interessados
• Monitoramento a Transição de Serviço atuação para fornecer informações
para Melhoria de Serviço Continuada.
Alterações que afetam o acordado linha de base item de configuraçãos são
controlados através de Gerenciamento de Mudanças.
Planos e progresso deve ser comunicada e disponibilizados para os
interessados. O das partes interessadas lista é definido na pacote de serviços
recebido projeto e Transição de Serviço deve estabelecer a continuidade da
relevância dessa lista, e atualizá-lo quando necessário.
4.1.6.3 monitoramento e geração de relatórios de progresso

Atividades de transição de serviços necessitam de um acompanhamento contra
as intenções estabelecidas na transição modelo e plano. Medir e monitorar o
liberar e de implantação (no final) estabelecer se a transição está ocorrendo de
acordo com o plano.
Manter uma supervisão das transições reais contra a Transição de Serviço
integrado de planos de lançamento, e alteração de horários é essencial. Ele
inclui o monitoramento do progresso de cada transição periodicamente e em
pontos de marco ou linha de base, bem como receber e correndo atrás de
atualizações.
Relatórios gerenciais sobre a situação de cada transição ajudará a identificar
quando há significativa variaçãos do plano, por exemplo, para projeto gestão e
Serviço de Gestão de organização para tomar decisões e agir.
Em muitos casos, os planos de transição devem ser alteradas para trazê-los em
consonância com uma realidade que mudou desde design. Isso não é sinônimo
de má concepção ou erro na seleção de modelos de transição, mas apenas um
reflexo de uma dinâmica ambiente.
4.1.7 Triggers interfaces de entrada e saída, e entre processos
O gatilho é uma RFC autorizado para uma Transição de Serviço. As entradas
são:
• Autorizado RFC
• Pacote Service Design
• Definição de liberação do pacote e design especificação
• Critérios de aceitação de serviços (SAC).
Saídas:
• Transição estratégia
• Conjunto integrado de planos de Transição de Serviço.
4.1.8 Principais indicadores de desempenho e métricas
Primário indicador chave de desempenhos (KPIs) para Planejamento de
transição e suporte incluem:
• O número de liberars implementado que conheceu o cliente concordou
exigências, em termos de custar,qualidade,escopoE liberação da
programação (expresso como uma percentagem de todas as versões)
• Variação reduzida de real vs previsto escopo, custo, qualidade e tempo

• De clientes aumentou e usuário satisfação com planos e comunicações
que permitem que o negócio a alinhar suas atividades com a Transição
de Serviço planos
• Redução do número de questões, riscos e atrasos causados por
inadequada planejamento.
Outros KPIs para uma eficaz transição e apoio processo incluem:
• Serviço melhor taxa de sucesso de Transição através âmbito melhoria e
integração da planejamento atividades
• Melhor gestão da informação no vs previu real atuação e custo de
• Melhorado eficiência e eficácia dos processos e de apoio sistemas,
ferramentas, informações, conhecimentos e dados que permitam a
transição de serviços novos e modificados, por exemplo,
compartilhamento de licenças de ferramentas
• Redução de tempo e recursos para desenvolver e manter planos
integrados e actividades de coordenação
• Projeto e satisfação da equipe de serviço com as práticas de Transição
de Serviço.

4.2 Gestão de Mudança
Alterações ocorrer devido a uma variedade de razões:
• Proativamente, por exemplo, na procura de vantagens comerciais, tais
como redução de custos ou melhoria dos serviços ou aumentar a
facilidade ea eficácia do apoio
• Reativa como um meio de resolução de erros e adaptação às novas
circunstâncias.
As mudanças devem ser gerenciadas para:
• Otimizar exposição ao risco (apoiar a risco perfil exigido pela empresa)
• Minimizar a gravidade de qualquer impacto e perturbações
• Ser bem sucedido na primeira tentativa.
Essa abordagem vai entregar benefício direto para a linha de fundo para o
negócio, oferecendo realização antecipada de benefícios (ou remoção de risco),
com uma economia de tempo e dinheiro.
Para dar uma resposta adequada a todas as solicitações de mudança implica
uma abordagem considerada avaliação de risco e negócio continuidade, mudar
impacto, recurso requisitos, mudar de autorização e, especialmente, para o
benefício do negócio realização. Esta abordagem considerada é essencial para
manter o equilíbrio necessário entre a necessidade de mudança eo impacto da
mudança.
Esta seção fornece informações sobre o Gestão da Mudança processo e fornece
orientações que é escalável para:
• Diferentes tipos e tamanhos de organizações
• Pequenas mudanças e grandes necessários em cada ciclo de vida etapa
• Alterações com impacto maior ou menor
• Mudanças em um prazo exigido
• Diferentes níveis de orçamento ou financiamento disponível para gerar a
mudança.
4.2.1 Finalidade, objetivos e metas
O objetivo do processo de Gerenciamento de Mudança é assegurar que:
• Métodos padronizados e procedimentos são usados para a manipulação
eficiente e imediata de todas as mudanças
• Todas as alterações serviço ativos e item de configuraçãos são
registadas na Sistema de Gerenciamento da Configuração
• Global de negócios risco é otimizard.

Os objetivos da gestão da mudança são:
• Responder a negócios em constante mudança do cliente exigências
enquanto maximiza o valor e reduzindo incidentes ruptura, e re-trabalho
• Responda à negócio TI e pedidos de mudança que irá alinhar os serviços
com as necessidades do negócio.
O objetivo da Gestão da Mudança processo é garantir que as mudanças sejam
registradas e então avaliadas, autorizadas, priorizadas, planejadas, testadas,
implementadas, documentadas e revisadas de uma maneira controlada.
4.2.2 Âmbito
A mudança pode ser definida de várias maneiras. A definição de um serviço
mudança é:
Mudança de serviço
'A adição, modificação ou remoção de autorizado, planejado ou serviço
suportado ou componente de serviço e sua documentação associada.
O escopo de Gestão da Mudança introduz alterações linha de baseativos de
serviços e d item de configuraçãos em todo o serviço inteiro ciclo de vida.
Cada organização deve definir as alterações que se encontram fora do âmbito
da sua serviço mudar processo. Normalmente, estes podem incluir:
• Mudanças com significativamente mais amplo impactos do que as
mudanças de serviços, por exemplo, organização departamental, políticas
e operações comerciais - Estas mudanças produzem RFCs para gerar
mudanças no serviço conseqüentes
• Mudanças em uma operacional nível, como reparação de impressoras ou
serviços de outra rotina componentes.
Figura 4.1 mostra um típico escopo para a Gestão da Mudança serviço processo
por um departamento de TI e como ele interage com o negócio e fornecedors
em estratégico,tático e os níveis operacionais. Abrange interfaces para interno e
prestador de serviços externos onde há bens comuns e itens de configuração
que precisam estar sob Gestão da Mudança. Gestão da Mudança serviço deve
interagir com Gestão de Negócios Mudança (à esquerda na figura 4.1), e com a
Gestão de Mudança do fornecedor (à direita na figura). Este pode ser um
fornecedor externo com uma gestão de mudança formal sistema, Ou com a
projeto mudar os mecanismos dentro de uma interna desenvolvimento projeto.

Figura 4.1 Volume de mudança e gerenciamento de liberação para serviços
O Portfólio de Serviços fornece uma definição clara de toda a corrente,
planejado e aposentarserviços d. Compreender o portfólio de serviços ajuda a
todas as partes envolvidas na Transição de Serviço compreender o impacto
potencial do serviço novo ou alterado em serviços atuais e outros serviços novos
ou alterados.
Mudanças estratégicas são trazidos via Estratégia de Serviço e a Gestão de
Relacionamento com Empresas processos. Mudanças para um serviço serão
trazidos via Design de Serviços,Melhoria de Serviço Continuada e a
gerenciamento de nível de serviço processo. Mudança corretiva, resolvendo
erros detectados em serviços, será iniciada a partir de Operação de Serviços, e
pode rota através de apoio ou de fornecedores externos em um RFC formal.
Exclusões
Este capítulo não compreende estratégica planejamento para negócio
transformação ou mudança organizacional, embora os interfaces para esses
processos precisam ser gerenciados. Orientação sobre a mudança
organizacional é abordada no capítulo 5. Transformação de negócios é o tema
de muitas publicações que visam o gerente geral de negócios.
Confiança e continuidade de negócios são essenciais para o sucesso ea
sobrevivência de qualquer organização. Mudanças de serviços e infra-estrutura
pode ter um impacto negativo impacto sobre o negócio através da interrupção do
serviço e demora na identificação negócio requisitos, mas Gestão da Mudança
permite que o provedor de serviços para adicionar valor ao negócio através de:

• Priorizar e responder aos negócios e cliente alterar propostas
• Mudanças de execução que atendam aos requisitos dos clientes de
serviços acordados, otimizando custos
• Contribuindo para atender governo, Os requisitos legais, contratuais e
regulamentares
• Reduzir mudanças falharam e, portanto, interrupção do serviço, defeitos e
re-trabalho
• Materializar a mudança imediatamente para atender prazos de negócios
• Acompanhando alterações através do serviço ciclo de vida e para o
ativoss dos seus clientes
• Contribuir para o melhor estimativas da qualidade, O tempo e custar de
mudança
• Avaliar os riscos associados com a transição de serviços (introdução ou
eliminação)
• Ajudando a produtividade dos funcionários através de interrupções
minimizando devido aos níveis elevados de não planejada ou
"emergência" e, consequentemente, maximizar a mudança de serviço
disponibilidade
• Reduzindo o Tempo médio para restaurar o serviço (MTR), através de
implementações mais rápidas e mais bem-sucedido de mudanças
corretivas
• Ligação com a mudança em negócios processo para identificar
oportunidades de melhoria dos negócios.
Exemplo de serviço de TI iniciou a mudança em negócios
No setor de varejo, bar-codificação das mercadorias, juntamente com código de
barras leitores no momento do check-out foi inicialmente introduzido para
oferecer economia, eliminando a necessidade de rotular a cada item,
automatizando estoque controlar, Cliente excesso de velocidade todo e redução
de check-out pessoal. Sugestões de TI para o negócio resultou em fazer uso
desta facilidade aos conceitos de energia inovadoras, tais como comprar um
obter um livre e captura de dados sobre os hábitos de compra de cada indivíduo.
A dependência De serviços de TIs e subjacente tecnologia da informação agora
é tão complexo que um tempo considerável pode ser gasto em:
• Avaliando a impacto dos negócios mudar em TI
• Analisando o impacto de um serviço de TI ou mudar no negócio
• Notificando as partes afetadas (do que é proposto, planejado e
implementado)
• Gravar e manter as alterações precisas, configuração liberar e
desenvolvimento registros
• Gestão e resolução incidentes causados pela mudança
• Identificando o problemas que surgem continuamente que requerem mais
mudança

• Apresentando as novas idéias e tecnologias que causam a mudança
ainda mais.
Existem, por conseguinte, considerável custar economia e eficiência para ser
adquirida a partir de mudanças bem estruturados e planejados e lançamentos.
Como existe hoje tanto se concentrar em empresa gestão de risco,Gestão da
Mudança é uma tecla processo que vem sob o escrutínio dos auditores. O
Instituto de Auditores Internos, Global Technology Audit Guia de Mudança, e
Controles Patch Management: críticos para o sucesso organizacional, fornece
orientação sobre a avaliação de Gerenciamento de Mudanças capacidade de
um organização. Identifica risco indicadores de Gestão da Mudança pobres que
se aplicam ao negócio e de TI mudar:
"Ao gerenciar mudanças, você gerencia a maior parte do risco potencial que as
mudanças podem introduzir"
Os cinco principais indicadores de risco de Gestão da Mudança pobres são:
• Alterações não autorizadas (acima de zero é inaceitável)
• Interrupções não planejadas
• A baixa taxa de sucesso mudança
• Um número elevado de mudança de emergências
• Atrasado projeto implementações.
O parágrafo a seguir é extraído do guia:
O que todos os de alto desempenho das organizações de TI têm em comum? Eles
têm um cultura de Gestão da Mudança que previne e impede alteração não
autorizada. Eles também "confiar, mas verificar" usando controles de detecção
independentes para reconciliar as alterações de produção com mudanças
autorizadas, e por exclusão de primeira mudança na reparar ciclo durante
interrupções. Por fim, elas também têm a mais baixa tempo médio para reparo
(MTTR). Auditores irão apreciar que nestes alto desempenho das organizações de
TI, Gerenciamento de Mudanças não é visto como burocrático, mas é, ao invés da
rede de segurança só impedindo-os de se tornar um artista de baixa. Em outras
palavras, a gestão de TI possui os controles para alcançar o seu próprio objetivo
de negócios, de forma eficiente e eficaz. Alcançar uma taxa de sucesso de 70 por
cento sobre a mudança só é possível com preventiva e controles de detecção.
Nota: Tempo médio para restaurar o serviço (MTR) deve ser usado para evitar a
ambiguidade do tempo médio de reparo (MTTR). Embora MTTR é um termo da
indústria amplamente aceito, em 'reparação' algumas definições inclui apenas o
tempo de reparo, mas em outros inclui recuperação tempo. O tempo de
inatividade em MTRS abrange todos os fatores contribuintes que fazem o
serviço, componente ou CI indisponíveis. MTRS é uma medida de quão
rapidamente e efetivamente um serviço, componente ou pode ser CI restaurard

ao normal de trabalho depois de um falha e deve ser calculada usando a
seguinte fórmula:
O tempo de inatividade total (horas)
MTRS (horas) = -------------------------------
Número de quebras de serviço
Esta seção apresenta conceitos básicos dentro Gestão da Mudança que
suportam a sua efetiva execução.
4.2.4.1 Políticas
Aumentar a taxa de sucesso das mudanças e liberars requer suporte executivo
para a implementação de uma cultura que define das partes interessadas
expectativas sobre as mudanças e liberações e reduz o trabalho não planejada.
A pressão vai ser aplicado para reduzir prazos e cumprir prazos; cortar
orçamentos e os custos de funcionamento e de comprometer o teste. Isso não
deve ser feito sem a devida diligência para governo e risco. O Transição de
Serviço equipe de gestão será chamado de vez em quando para fazer uma
decisão 'go não' e não implementar uma mudança necessária. Deve haver
políticas e padrãos definido que deixar claro para os fornecedores internos e
externos que deve ser feito e que a conseqüência da não-adesão ao política
será.
Que as políticas de Gestão da Mudança suporte incluem:
• Criar uma cultura de Gestão de Mudanças em todo o organização onde
há tolerância zero para a alteração não autorizada
• Alinhando o Gerenciamento de Mudança serviço processo com o
negócio, projeto e os processos de gestão de stakeholders Alterar
• Priorização da mudança, por exemplo, inovação vs preventiva vs detetive
mudança vs corretiva
• Estabelecimento de prestação de contas e responsabilidades para as
mudanças através do serviço ciclo de vida
• Segregação de controles dever
• O estabelecimento de um ponto único de contacto para as mudanças, a
fim de minimizar a probabilidade de alterações em conflito e ruptura
potencial para a produção ambiente
• Impedir que as pessoas que não estão autorizadas a fazer uma mudança
de ter acesso ao ambiente de produção

• Integração com outros Serviço de Gestão de processos para estabelecer
a rastreabilidade de mudança, detectar e identificar a alteração não
autorizada mudar relacionado incidentes
• Alterar janelas - fiscalização e autorização para exceções
• Atuação e risco avaliação de todas as mudanças que o serviço de
impacto capacidade
• Medidas de desempenho para o processo, E.g. eficiência e eficácia.
4.2.4.2 Design e considerações de planejamento
O Gestão da Mudança processo deve ser planejado em conjunto com o
lançamento e Gerenciamento da Configuração. Isto ajuda a provedor de
serviços para avaliar a impacto da mudança sobre os serviços atuais e
planejadas e lançamentos.
O exigências e projeto para os processos de Gerenciamento de Mudanças
incluem:
• Requisitos, por exemplo, em conformidade com a legislação pertinente,
códigos da indústria de prática, Normas e práticas organizacionais
• Abordagem para eliminar a alteração não autorizada
• Identificação e classificação:
• Mudar documento identificadores
• Alterar os tipos de documentos, mudar modelos de documentação
e de conteúdo esperado
• Impacto, urgência, As prioridades
• Organização, funções e responsabilidades:
• Responsabilidades e as responsabilidades de todos das partes
interessadass
• Abordagem de testes independente e avaliação de mudança
• Alterar autorização - os níveis de autorização e normas que regem
a tomada de decisões e ações, por exemplo, escalada
• Composição dos Conselhos Consultivos, por exemplo, o Alterar
Conselho Consultivo (CAB) eo CAB Emergência (ECAB)
• Partes interessadas:
• Planejamento de mudanças e liberars para permitir às partes
interessadas para fazer a sua própria preparação e planejamento
de suas atividades
• Comunicar mudanças, alteração de horário e liberação planos
• Agrupando e relacionando alterações:
• Em um comunicado, construir ou linha de base
• Ao ligar RFCs criança vários a um RFC mestre
• Procedimentos:
• Mudar as políticas de autorização, regras e procedimentos
• Para levantar uma RFC, incluindo a preparação e apresentação de
proposta de mudança

• Como mudar pedidos são acompanhados e gerenciados, ou seja,
alterar o registros
• Como as solicitações de mudança são impacto determinada e
avaliada prontamente
• Dependências de identificação e incompatibilidades entre as
mudanças
• Para verificar a implementação de uma mudança
• Supervisionar e avaliar entregas de mudança e implementação de
liberação
• Para rever mudanças regularmente para identificar tendências e
melhorias, por exemplo, no sucesso ou falha de mudanças e
liberações
• Interfaces com outros Serviço de Gestão de processos, por exemplo,
gerenciamento de nível de serviço e gerenciamento de capacidade para o
impacto avaliação e revisão
• Abordagem à mudança de interface, lançamento e Gerenciamento da
Configuração com a problema e gerenciamento de incidentes processos
para medir e reduzir as mudanças relacionadas incidentes
• Gestão de interfaces de configuração:
• Para fornecer qualidade informações para a avaliação de impacto
e relatórios, por exemplo, comparação de como estão para As-
planejada configuração
• Para identificar altarisco, CIs de alto impacto
• Para capturar configuração cis, linha de bases e liberars
• Para capturar entregas relacionadas, por exemplo, Critérios de
aceitação, teste e avaliação relatórios.
4.2.4.3 Tipos de solicitação de mudança
Um pedido de mudança é uma comunicação formal buscando uma alteração em
uma ou mais item de configuraçãos. Isso pode assumir diversas formas, por
exemplo, 'Requisição de Mudança'documento,balcão de atendimento
chamar,Projeto Documento de Iniciação. Diferentes tipos de mudar pode exigir
diferentes tipos de solicitação de mudança. Um organização necessidades para
garantir que apropriado procedimentos e formulários estão disponíveis para
cobrir os pedidos antecipados. Evitando uma abordagem burocrática para
documentar uma pequena alteração remove algumas das barreiras culturais
para adotar a Gestão da Mudança processo.
Como o uso tanto quanto possível, deve ser feita de autorização delegada, tanto
através da mudança padrão procedimento (ver parágrafo 4.2.4.4) e por meio da
autorização de pequenas alterações por Gestão da Mudança pessoal.

Durante o planejamento de diferentes tipos de solicitações de mudança, cada
um deve ser definido com uma convenção de nomenclatura única (ver parágrafo
4.3.5.3). Tabela 4.3 fornece exemplos de diferentes tipos de solicitação de
mudança de todo o serviço ciclo de vida.
Tipo de mudança com
exemplos
Documentados
procedimentos de
trabalho
Estratégia
de Serviço
Design
de
Serviços
Transição
de Serviço
Operação
de Serviço
Melhoria de
Serviço
Continuada
Pedido para que a
mudança Portfólio de
Serviçoss
Gestão da Mudança
serviço
- Novo item de linha
portfolio
- Para predito
escopo,Business
Case,linha de base
-Pipeline de serviço
Requisição de
Mudança para a
definição de serviço
ou serviço
Gestão da Mudança
serviço
- Para o serviço
existente ou prevista
atributos
-Projeto mudar que os
impactos Design de
Serviços, E.g. garantias
previstas
- Melhoria de Serviço
Proposta de mudança
do projeto
Gestão da Mudança
projeto procedimento
- Mudança de Negócios
- Nenhum impacto no
serviço ou projeto linha
de base
Solicitação de acesso
de usuário
Usuário acessar
procedimento
Operacional atividade
-Afinação (Dentro
especificação/
Restrições)
Procedimento local
(muitas vezes pré-
autorizado - ver o
ponto 4.2.4.4)
- Hardware Re-boot
falha se não impacto
em outros serviços
- Manutenção planejada
Tabela 4.3 Exemplo de tipos de pedido de serviço de estágio do ciclo de vida

Para tipos diferentes de mudança muitas vezes há procedimentos específicos,
por exemplo, para avaliação de impacto e autorização mudança.
4.2.4.4 Mudança de modelos de processos e fluxos de trabalho
Organizações irão achar útil predefinir mudança processo modelos - e aplicá-los
às mudanças adequadas quando eles ocorrem. Um modelo de processo é uma
forma de predefinir os passos que devem ser tomadas para lidar com um
processo (neste caso, um processo para tratar um tipo particular de mudança)
de uma forma acordado. Ferramentas de suporte pode então ser utilizado para
administrar o processo desejado. Isto irá assegurar que tais alterações são
tratadas em um caminho predefinido e de prazos predefinidos.
As alterações que requerem um tratamento especializado pode ser tratado desta
forma, como mudança de emergências que podem ter autorização diferente e
pode ser documentado retrospectivamente.
O modelo de processo de mudança inclui:
• Os passos que devem ser tomadas para lidar com a mudança, incluindo
questões de manuseio e inesperados eventos
• 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 limites para a conclusão das ações
• Escalada procedimentos; que deve ser contactado e quando.
Estes modelos são geralmente de entrada para o Gestão da Mudança
ferramentas de apoio em uso e as ferramentas então automatizar a
manipulação, gerenciamento, relatórios e escalada da processo.
4.2.4.5 Mudanças padrão (pré-autorizado)
Amudança padrão é uma mudança para um serviço ou infra-estrutura para que a
abordagem é pré-autorizada pelo Gerenciamento de Mudanças, que tem um
procedimento aceito e estabelecido para fornecer uma mudança específica
exigência.
Os exemplos podem incluir uma atualização de um PC, a fim de fazer uso de
norma específica e software pré-orçamentado, novas entradas dentro de uma
organização, Ou um movimento de desktop para um único usuário. Outros
exemplos incluem baixo impacto, Mudança de aplicação de rotina para lidar com
variação sazonal.
Aprovação de cada ocorrência de uma mudança padrão será concedida pela
autoridade delegada para que a mudança padrão, por exemplo, pelo orçamento

terra arrendada cliente para a instalação de software de uma lista aprovada em
um PC registrado para sua unidade organizacional ou pelo terceiro engenheiro
para a substituição de uma impressora de mesa com defeito.
Os elementos cruciais de uma mudança de padrão são:
• Existe um gatilho definido para iniciar a RFC
• As tarefas são bem conhecidos, documentado e comprovado
• Autoridade é efetivamente dado antecipadamente
• Aprovação orçamental será tipicamente predeterminado ou dentro do
controlo do solicitador mudança
• O risco geralmente é baixa, e sempre bem compreendida.
Uma vez que a abordagem para gerenciar mudanças de padrão que foi
acordado, os processos de mudança padrão e fluxos de trabalho de mudança
associados devem ser desenvolvidos e comunicados. A alterar modelo seria
normalmente associado com cada mudança padrão para garantir a consistência
do método.
Mudanças de padrão deve ser identificada no início, quando a construção do
Gestão da Mudança processar a promover eficiência. Caso contrário, uma
implementação de Gerenciamento de Mudanças pode criar desnecessariamente
elevados níveis de administração e de resistência ao processo de
Gerenciamento de Mudança.
Todas as alterações, incluindo alterações de padrão, terá detalhes da alteração
registada. Para algumas mudanças de padrão que pode ser de natureza
diferente do normal alterar o registros.
Algumas mudanças de padrão para item de configuraçãos podem ser
acompanhados no ativos ou item de configuração ciclo de vida, Especialmente
quando há um CMS abrangente que fornece relatórios de mudanças, sua atual
estado, Os itens relacionados a configuração eo status do IC relacionado
versãos. Nestes casos, a mudança e Gerenciamento da Configuração
comunicação integrada e Gerenciamento de Mudanças pode ter 'supervisão' de
todas as alterações ao serviço de CIs e liberar IC.
Algumas mudanças de padrão será acionado pelo pedido cumprimento
processar e ser diretamente registrados e transmitidos para a acção da balcão
de atendimento.
4.2.5 planejamento Remediação
Não mudar deve ser aprovado sem ter abordou expressamente a questão de o
que fazer se não for bem sucedida. Idealmente, haverá um back-out plano, que
será restaurar o organização à sua situação inicial, muitas vezes através da

recarga de um conjunto de itens de configuração baseline, especialmente
software e dados. No entanto, nem todas as alterações são reversíveis, caso em
que uma abordagem alternativa para remediação é necessária. Esta
recuperação pode exigir uma revisitação da mudança na própria evento de falha,
Ou pode ser tão grave que requer invocando o da organização plano de
continuidade de negócios. Apenas considerando que opções estão disponíveis
antes de remediação instigar uma mudança, e ao estabelecer que a remediação
é viável (por exemplo, é bem sucedido quando testado), pode a risco da
mudança proposta ser determinada e as decisões apropriadas.
Esta seção apresenta abordagens para mudanças serviço de gestão eficaz,
abordando as tarefas realizadas para alcançar e realizar uma mudança
controlada.
Atividades de gestão global mudança incluem:
• Planejamento e controlar as mudanças
• Alterar e liberar agendamento
• Comunicações
• Alterar a tomada de decisão e de mudança autorização
• Assegurando existem remediação planos
• Medição e controlar
• Relatórios de gestão
• Compreender o impacto de mudança
• Melhoria contínua.
As atividades típicas de gestão de mudanças individuais são:
• Criar e gravar o RFC
• Comente RFC e proposta de mudança:
• Trocas de filtros (por exemplo, alterações incompletas ou mal
encaminhado)
• Analisar e avaliar a mudança:
• Estabelecer o nível adequado de autoridade mudança
• Estabelecer áreas relevantes de interesse (ou seja, quem deve
estar envolvido no CAB)
• Analisar e avaliar a negócio justificação, impacto,custar, Benefícios
e riscos das mudanças
• Pedir independente avaliação de uma alteração (ver 4.2.6.4)
• Autorizar a mudança:
• Obter autorização / rejeição
• Comunicar a decisão com toda a das partes interessadass, em
particular, o iniciador da Requisição de Mudança
• Atualizações de planos

• Coordenar a implementação mudança
• Comente e perto mudar:
• Cotejar a documentação mudança, por exemplo, linha de bases
relatórios e avaliação
• Reveja a mudança (s) e documentação mudança
• Fechar a mudança documento quando todas as ações estão
concluídas.
Ao longo de todo o processo atividades listadas acima descrito e dentro desta
seção, a informação é recolhida, gravada no CMS e relatados.
A Figura 4.2 mostra um exemplo de uma alteração na provedor de serviços'S
serviços, aplicaçãos ou infra-estrutura. Exemplos de estados da RFC são
mostrados em itálico. Mudança e informações de configuração é atualizado todo
o caminho através das atividades. As figuras 4.3 e 4.4 mostram o equivalente
processo fluxo para alguns exemplos de mudança padrão fluxos de processos.

Figura 4.2 Exemplo de fluxo de processo para uma mudança normal

Figura 4.3 Exemplo de fluxo de processo para solicitação de implantação padrão

Figura 4.4 Exemplo de fluxo de processo para solicitação de mudança de padrão
operacional
4.2.6.1 Procedimento de mudança normal
O texto nesta secção define detalhadamente os aspectos seguidos dentro de
uma mudança normal. Os princípios gerais enunciados se aplicam a todas as
alterações, mas onde mudança normal procedimento pode ser modificado, isto
é, por norma, ou mudança de emergências, este é definido após a explicação do
processo de mudança normal.
4.2.6.2 Criar e registrar pedidos de mudança
A mudança é criada por uma solicitação do iniciador - o indivíduo, grupo ou
organização que requer a mudança. Por exemplo, este pode ser um unidade de
negócios que requer instalações adicionais, ou Gerenciamento de Problemas
equipe instigar um erro resolução de muitas outras fontes.
Para uma grande mudança com implicações organizacionais e / ou financeira,
uma proposta de mudança pode ser necessária, que irá conter uma descrição

completa da mudança, juntamente com uma justificativa comercial e financeiro
para a mudança proposta. A proposta de mudança irá incluir sign-off por níveis
adequados de gestão de negócios.
A Tabela 4.4 mostra um exemplo de informação gravada, para variar, o nível de
detalhe depende do tamanho e impacto da mudança. Algumas informações são
registradas quando o documento é iniciada e algumas informações podem ser
atualizados conforme o documento mudança progride por meio de sua ciclo de
vida. Algumas informações são registadas directamente no Requisição de
Mudança forma e os detalhes da mudança e ações podem ser registrados em
outros documentos com a referência do RFC, por exemplo, Business Case,
Impacto avaliação relatar.
Atributo no registro da mudança RFC Proposta de
mudança (se
for o caso)
Ativos
relacionados / CIS
Número único
Trigger (por exemplo, a ordem de
compra, número do relatório problema
de erro, registros, a necessidade de
negócios, legislação)
Descrição Resumo Descrição
completa
Identidade do item (s) a ser alterado -
Descrição da alteração pretendida
Resumo Descrição
completa
Serviço (por
aumento) ou IC
com erros
(mudanças de
correcção)
Motivo da alteração, por exemplo,
Business Case
Resumo Plena
justificação
Efeito de não implementar a mudança
(de negócios, técnica, financeira, etc)
Item de configuraçãos e linha de base
versãos para ser mudado
Linha de base
afetado
/liberar
Detalhes de IC em
linha de base /
release
De contato e detalhes de pessoa que
propõe a mudança
Data e hora em que a mudança foi
proposta
Mudar categoria, E.g. menor,
significativo, importante
Proposto
Prazo previsto, recursos, os custos e
qualidade de serviço
Resumo /
referência
Completo

Mudar prioridade Proposto
Avaliação de risco e gestão de risco
plano
Resumo /
referência
Completo
Voltar-out ou remediação plano Possivelmente Completo
Impacto avaliação e avaliação -
Recursos e capacidade,custar,
Benefícios
Provisório Impacto inicial
Será que a mudança exige consequente
alteração de Gerenciamento da
Continuidade do Serviço (ITSCM) plano,
plano de capacidade,segurança plano,
teste plano
Planos afetados
Mudar o corpo de decisão
Decisão e recomendações que
acompanha a decisão
Assinatura de autorização (pode ser
eletrônico)
Data da autorização e do tempo
Baseline alvo ou liberar para incorporar
a mudança em
Plano alvo mudança (s) para a mudança
deve ser incorporada
Tempo de implementação agendada
(mudar de janela,janela de lançamento
ou a data e hora)
Localização / referência ao lançamento /
implementação do plano
Detalhes do implementador mudança
Alterar detalhes de implementação
(sucesso / fracasso /remediação)
Data de implementação real e tempo
Comente data (s)
Os resultados das análises (incluindo
referência cruzada ao novo RFC
quando necessário)
Resumo
Fecho Resumo
Exemplo Tabela 4.4 do conteúdo da documentação mudança

O alterar o registro contém a história completa do mudar, Incorporando a
informação a partir da RFC e, subsequentemente, a gravação concordou
parâmetros como prioridade e autorização, implementação e revisão da
informação. Pode haver muitos tipos diferentes de registos de mudança
utilizados para gravar os diferentes tipos de alterações. A documentação deve
ser definido durante o processo projeto e planejamento fase.
Diferentes tipos de mudança documento terá diferentes conjuntos de atributos
para ser atualizado através do ciclo de vida. Isto pode depender de vários
factores, tais como o processo de mudança modelo e mudança categoria mas
recomenda-se que os atributos são padronizados, sempre que possível para
ajudar relatórios.
Alguns sistemas usar as ordens de serviço para o progresso da mudança como
este permite a rastreabilidade completa da mudança. Por exemplo ordens de
trabalho podem ser emitidos para indivíduos ou equipes para fazer uma impacto
avaliação ou para completar o trabalho necessário para uma mudança que está
prevista para uma hora específica ou onde o trabalho é para ser feito
rapidamente.
Como um RFC procede por meio de seu ciclo de vida, o documento mudança,
os registros relacionados (como ordens de serviço) e relacionado item de
configuraçãos são actualizados no CMS, de modo que haja visibilidade da sua
estado. Estimativas e reais recursos, os custos e resultado (Sucesso ou falha)
São gravadas para habilitar o relatório de gestão.
Alterar registro
O procedimentos para registrar e documentar RFCs, deve ser decidido. RFCs
pode ser capaz de ser apresentadas em formulários de papel, através de e-mail
ou através de uma interface baseada na web, por exemplo. Quando uma
ferramenta de suporte baseado em computador é usado, a ferramenta pode
restringir o formato.
Todos os RFCs recebidos devem ser registrados e atribuído um número de
identificação (em ordem cronológica). Onde mudar pedidos são apresentados na
sequência de um gatilho, tais como um resolução para uma registro de problema
(PR), que é importante que o número de referência do disparo documento é
mantido para permitir a rastreabilidade.
Recomenda-se que o registo de RFCs é feito por meio de um sistema integrado
Serviço de Gestão de ferramenta, capaz de armazenar tanto os dados relativos
a todos ativoss e IC, e também, de forma importante, a relaçãos entre eles. Isso
vai ajudar muito na avaliação do provável impacto de uma alteração em um
componente do sistema em todos os outros componentes. Todas as acções
devem ser registados, como eles são realizados, dentro do Gestão da Mudança

registrar. Se isso não for possível, por qualquer razão, então eles devem ser
manualmente gravado para inclusão na próxima oportunidade possível.
Procedimentos vai especificar os níveis de acesso e quem tem acesso ao
registro sistema. Embora qualquer pessoal autorizado pode criar ou adicionar
relatórios de progresso para, um RFC (embora a ferramenta de suporte deve
manter Gestão da Mudança ciente de tais ações) só Alterar equipe de Gestão
terão permissão para fechar um RFC.
4.2.6.3 analisar a solicitação para a Mudança
O procedimentos deve estipular que, como as mudanças são registradas,
Change Management deve considerar brevemente cada pedido e filtrar qualquer
que parecem ser:
• Totalmente impraticável
• Repetições de RFCs anteriores, aceito, rejeitado ou ainda em
consideração
• Inscrições incompletas, por exemplo descrição inadequada, sem
aprovação do orçamento necessário.
Estes devem ser devolvidos para o iniciador, juntamente com uma breve
descrição do motivo da rejeição, eo registro deve registrar este fato. Um direito
de recurso contra a rejeição deve existir, através de canais normais de gestão, e
devem ser incorporadas dentro dos procedimentos.
4.2.6.4 Avaliar e avaliar a mudança
O potencial impacto sobre os serviços de mudanças fracassadas e seu impacto
na serviço ativos e configurações necessitam de ser considerados. Questões
genéricas (por exemplo o "sete Rs ') fornecem um bom ponto de partida.
Os sete Rs de Gestão da Mudança
As seguintes perguntas devem ser respondidas para todas as alterações. Sem
essas informações, a avaliação de impacto não pode ser concluída, eo saldo de
risco e tirar o viver serviço não será compreendido. Isto poderia resultar na
alteração não entregar todo o possível ou esperada negócio benefícios ou até
mesmo de ele ter um efeito prejudicial sobre o inesperado viver serviço.
• Quem levantou a mudança?
• Qual é a razão para a mudança?
• Qual é o retorno exigido a partir da mudança?
• Quais são os riscos envolvidos na mudança?
• Que recursos são necessários para entregar a mudança?
• Quem é responsável pela construir,teste e implementação da mudança?

• Qual é a relação entre esta mudança e outras mudanças?
Muitas organizações desenvolvem específica impacto avaliação formas para
fazer aparecer os avaliadores de impacto sobre tipos específicos de mudança.
Isso pode ajudar com a aprendizagem processo, Especialmente para serviços
novos ou na implementação de um passo formal de avaliação de impacto para a
primeira vez.
Responsabilidade de avaliar mudança importante deve ser definido. Não é uma
questão de melhores práticas, pois as organizações são tão diferentes em
estrutura, tamanho e complexidade que não existe uma solução universal
apropriado para todas as organizações. É, no entanto, recomendou que a
mudança principal é discutido desde o início com todos das partes
interessadass, a fim de chegar a limites razoáveis de responsabilidade e para
melhorar a comunicação.
Embora Gestão da Mudança é responsável por assegurar que as mudanças são
avaliados e, se autorizado, posteriormente desenvolvidas, testadas,
implementadas e revistas responsabilidade, claramente final para o De serviços
de TI - Incluindo alterações a ele - vai descansar com a gerente de serviço e a
proprietário do serviço. Eles controlam o financiamento disponível e terá sido
envolvido no processo de mudança através da participação direta ou delegada
do CAB.
Ao conduzir o impacto e recurso avaliação para RFCs refere a eles, Change
Management, CAB ECAB, ou quaisquer outros (nomeado pelo Gerenciamento
de Mudanças ou membros do CAB), que estão envolvidos neste processo deve
considerar itens relevantes, incluindo:
• o impacto que a mudança terá sobre os negócios do cliente operação
• o efeito sobre a infra-estrutura de serviços e cliente, tal como definido no
serviço exigênciaslinha de bases, serviço modelo, SLA e no capacidade e
atuação,confiança e resiliência, Contingência planos, e segurança
• o impacto sobre outros serviços que são executados na mesma infra-
estrutura (ou em projetos)
• o impacto sobre a não-Infra-estrutura de TIs no interior da organização -
Por exemplo, segurança, serviços de escritório, transporte de clientes,
help desks
• o efeito de não implementar a mudança
• o negócio de TI, e outros recursos necessários para implementar a
mudança, cobrindo os custos, o número ea disponibilidade de pessoas
necessárias, o tempo decorrido, e todos os elementos de infra-estrutura
necessários novos
• a actual alteração de horário (CS) e interrupção do serviço projetado
(PSO)
• recursos adicionais em curso necessário se a mudança é implementada

• impacto sobre o plano de continuidade, plano de capacidade, Plano de
segurança de regressão, teste scripts e dados e ambiente de
teste,Operação de Serviços pratica.
Nenhuma mudança é sem risco
Mudanças simples pode parecer inócua, mas pode causar danos fora de
proporção aparente a sua complexidade. Há vários exemplos nos últimos anos
de alto perfil e negócio caro impacto causado pela inclusão, exclusão ou
misplacing de um '.' no código do software.
É melhores práticas usar um riscoAvaliação baseada na avaliação de impacto
de uma mudança ou um conjunto de alterações. Por exemplo, o risco de:
• Uma mudança individual
• Um conjunto de mudanças implementadas em conjunto
• Impactando as escalas de tempo de mudanças autorizadas em mudança
e liberar horários.
O foco deve ser a identificação dos fatores que podem comprometer o negócio,
impedir a entrega de garantias de serviço ou de impacto corporativo objetivos e
políticas. As mesmas disciplinas utilizadas para empresas gestão de risco ou
projeto gestão pode ser adotada e adaptada.
Classificação dos riscos
A questão da risco para a empresa de qualquer mudar devem ser considerados
antes da autorização de qualquer alteração. Muitas organizações utilizam uma
matriz simples, como a mostrada na Tabela 4.5 para categorizar risco, e deste
nível de avaliação de mudança e de autorização necessário.
Alterar impacto Alterar impacto / matriz de risco categorização
Alto impacto
Baixa probabilidade
Risco categoria: 2
Alto impacto
Alta probabilidade
Categoria de risco: 1
Baixo impacto
Baixa probabilidade
Baixo impacto
Alta probabilidade
Probabilidade
Exemplo de tabela de 4,5 de um impacto de mudança e matriz de classificação dos
riscos

O risco relevante é o risco para a serviço de negócio e mudanças requerem
avaliação cuidadosa, a comunicação de largura, e devida autorização da pessoa
ou pessoas responsáveis por essa serviço de negócio. A Avaliação de risco a
partir do perspectiva de negócios pode produzir um curso correcto da acção
muito diferente do que o que teria sido escolhida a partir de uma perspectiva de
TI, especialmente dentro de indústrias de alto risco.
Alto risco indústria
Em um negócio volátil e competitivo ambiente, O fornecimento de telefonia
móvel negócio, Perguntou clientes de TI se eles agora são capazes de
implementar uma mudança muito necessária para o software de negócios. A
resposta foi que não poderia avançar para o próximo mudar de janela porque
não havia ainda um risco de 30% de falha. Reação negócio era insistir na
aplicação, pois em seus olhos uma chance de 70% de sucesso, e com a
vantagem de negócios concomitante, foi sem qualquer hesitação a decisão certa
e inteligente. Muito poucos de suas iniciativas de negócios que teve uma chance
de sucesso.
O ponto é que o risco ea aposta do ambiente de negócios (venda de telefones
móveis) não tinha sido compreendido dentro da TI, e inadequadas (isto é) as
regras foram aplicadas.
O risco dominante é a uma empresa e que deveria ter sido procurado,
estabelecido, compreendido e aplicado pelo provedor de serviços.
Sensatamente, é claro, isso pode muito bem ser acompanhado de
documentação da decisão baseada em risco, mas ainda assim permanece a
necessidade de compreender a perspectiva de negócio e agir em conformidade.
Avaliação das mudanças
Com base na impacto e avaliação de riscos, e os benefícios potenciais da
mudança, cada um dos avaliadores devem avaliar as informações e indicar se
apoiar a aprovação da mudança. Todos os membros da autoridade mudança
deve avaliar a mudança com base no impacto, urgência,risco, Benefícios e
custos. Cada um vai indicar se apoiar a aprovação e estar preparado para
defender o seu caso para quaisquer alterações que eles vêem como necessário.
Atribuição de prioridades
Priorização é usado para estabelecer a ordem na qual as alterações
apresentadas devem ser consideradas.
Cada RFC incluirá a do originador avaliação do impacto e da urgência da
mudança.

O prioridade de uma mudança é derivado do impacto combinado e urgência.
Impacto inicial e urgência serão sugeridas por um iniciador de mudança, mas
pode muito bem ser modificado na autorização mudança processo. A avaliação
de risco é de fundamental importância nesta fase. O CAB terá informações
sobre as consequências de negócios, a fim de avaliar efetivamente o risco de
implementação ou rejeitar a mudança.
Impacto baseia-se na alteração benéfica para a empresa que vai seguir de uma
aplicação bem sucedida da mudança, ou o grau de dano e custar para a
empresa, devido à erro que a mudança vai corrigir. O impacto não podem ser
expressas em termos absolutos, mas pode depender de a probabilidade de um
evento ou circunstância, por exemplo, um serviço Pode ser aceitável no normal
todo níveis, mas pode deteriorar-se em uso elevado, que pode ser
desencadeada por imprevisíveis itens externos.
A urgência da mudança é baseada em quanto tempo a execução pode dar ao
luxo de ser adiada.
Tabela 4.6 dá exemplos de prioridades de mudança de mudanças corretivas
(correção de erros identificados que estão sofrendo a empresa) e para melhorias
(que proporcionará benefícios adicionais). Outros tipos de alteração existem, por
exemplo, para permitir a continuação do benefício existente, mas estes dois são
usados para ilustrar o conceito.
Prioridade Mudança corretiva Mudança
Enhancement
Imediato
Tratar como mudança de
emergência (Ver 4.2.6.9)
Colocando a vida em
risco
Causando perda
significativa de receita ou
a capacidade de
entregar serviços
públicos importantes.
Ação imediata
necessária
Não é adequado para
mudanças de melhoria
Alto
Para ser dada a máxima
prioridade para testes de
mudança, construção e
implementação recursos
Afetando severamente
alguma chave usuários,
ou impacto sobre um
grande número de
utilizadores
Atende legislativo
exigências
Responde às
oportunidades de curto
prazo do mercado ou
exigências públicas
Novos suportes negócio
iniciativas que vão
aumentar a posição de

mercado da empresa
Médio Não grave impacto, Mas
a rectificação não pode
ser adiada até a próxima
agendada liberar ou
atualização
Mantém a viabilidade do
negócio
Apoia iniciativas
empresariais planejadas
Baixo A mudança é justificada
e necessária, mas pode
esperar até o próximo
lançamento agendado ou
atualizar
Melhorias na
usabilidade de um
serviço.
Adiciona novas
instalações
Exemplos da tabela 4,6 Alterar a prioridade
Alterar o planejamento e programação
Cuidadoso planejamento das mudanças irá garantir que não há ambiguidade
sobre que tarefas estão incluídas no Gestão da Mudança processo, Quais as
tarefas que são incluídos em outros processos e processos como interface com
qualquer fornecedors ou projetos que estão fornecendo um mudar ou a
liberação.
Muitas mudanças podem ser agrupados numa liberar e pode ser concebido,
testado e lançado em conjunto, se a quantidade de mudanças envolvidas podem
ser tratadas pela empresa, a provedor de serviços e seus clientes. No entanto,
se muitas mudanças independentes são agrupados em um comunicado, então
esta pode criar dependências desnecessárias que são difíceis de gerir. Se não
bastante mudanças são agrupados em um comunicado depois do despesas
gerais de gestão mais lançamentos pode ser demorado e resíduos recursos (ver
parágrafo 4.4.5.1 sobre a liberação e desenvolvimento planejamento).
Recomenda-se fortemente que as mudanças alteração de horário de gestão
para atender negócios em vez de necessidades de TI, por exemplo, evitando
períodos críticos de negócios.
Pré-acordado e estabeleceu a mudança e janela de lançamentos ajudar um
organização melhorar o planejamento e todo de mudanças e liberações. Por
exemplo, uma janela de libertação de um período de manutenção de uma hora
por semana pode ser suficiente para instalar versões menores apenas. Grandes
lançamentos podem ter de ser agendada com a empresa e das partes
interessadass em um tempo pré-determinado. Esta abordagem é
particularmente relevante na mudança elevada ambientes, onde um lançamento
é um gargalo ou em alta disponibilidade serviços onde o acesso à viver sistemas
para implementar versões é restrito. Em muitos casos, a mudança ou a sua

libertação pode ser necessário ajustar 'na mosca', e assim o uso eficiente de
libertação janelas exigirá:
• Uma lista de possíveis substitutos para fazer uso da ranhura
inesperadamente vago
• Poder de tomar e implementar decisões de liberação
• Métricas internas que monitoram a mudança (e refletir e incentivar o
melhor uso de) e de lançamento do Windows
• Um entendimento claro de quaisquer dependências seqüenciais e
impacto em usuários.
Sempre que possível, Gestão da Mudança deve agendar mudanças autorizadas
em versão alvo ou pacotes de implantação e recomendar a alocação de
recursos em conformidade.
Gestão da Mudança coordena a produção e distribuição de um alteração de
horário (CS) e interrupção do serviço projetado (PSO). O SC contém detalhes de
todas as mudanças autorizadas para a implementação e as respectivas datas de
execução propostos. O PSO contém detalhes das alterações ao acordado SLAs
e serviço disponibilidade por causa do SC actualmente planeado para além
tempo de inatividade planejado de outras causas, como a manutenção planejada
e dados apoio. Estes documentos são acordados com os clientes relevantes
dentro da empresa, com gerenciamento de nível de serviço, Com a balcão de
atendimento e com gerenciamento de disponibilidade. Uma vez acordado, o
service desk deve comunicar qualquer tempo de inatividade planejado adicional
para o usuário comunidade em geral, utilizando os métodos mais eficazes
disponíveis.
O mais recente versãos destes documentos estará disponível para as partes
interessadas dentro do organização, De preferência contido dentro de uma
internet comumente disponíveis ou intranet servidor. Isso pode ser útil reforçado
com uma consciência pró-ativa programa onde específica impacto pode ser
detectada.
Avaliando remediação
É importante desenvolver um remediação plano para tratar de uma mudança ou
não a liberar muito antes de sua implementação. Muitas vezes, a remediação é
a última coisa a ser considerada; riscos podem ser avaliados, planos de
mitigação expressos em pedra. Como chegar de volta ao ponto de partida
original é muitas vezes ignorado ou considerado apenas quando a regressão é a
última opção restante.
4.2.6.5 Autorizar a mudança

Formal autorização é obtida para cada alteração de uma autoridade de mudança
que pode ser um papel, Pessoa ou um grupo de pessoas. Os níveis de
autorização para um determinado tipo de mudança deve ser julgado pelo tipo,
tamanho ou risco da alteração, por exemplo, mudanças em uma empresa de
grande porte que afetam vários sites distribuídos pode precisar de ser autorizada
por uma autoridade mudança de nível superior, como um CAB global ou o
Conselho de Administração.
O cultura do organização ditames, em grande parte, a maneira pela qual as
alterações são autorizados. Estruturas hierárquicas podem muito bem impor
muitos níveis de autorização mudança, enquanto estruturas mais planas podem
permitir uma abordagem mais racionalizada.
Um certo grau de autoridade delegada pode muito bem existir dentro de um
nível de autorização, por exemplo, delegar autoridade a um gerente de mudança
de acordo com parâmetros pré-definidos relativos a:
• Antecipado negócio risco
• Implicações financeiras
• Escopo da mudança (por exemplo, efeitos internos apenas, no
financiamento serviço, Específicos serviços de terceiros).
Um exemplo de uma hierarquia de autorização variação é mostrada na Figura
4.5.
Figura 4.5 Exemplo de um modelo de autorização mudança
Se a mudança avaliação em níveis de 2, 3, ou 4 detecta os níveis mais elevados
de risco, o pedido de autorização é aumentada para o nível superior apropriado
para o nível de risco avaliado. O uso da autoridade delegada de níveis mais

elevados a nível local deve ser acompanhada de confiança no julgamento, o
acesso à informação adequada e apoiado pela administração. O nível em que a
mudança está autorizado deve descansar onde a responsabilidade para a
aceitação de riscos e remediação existir.
Caso de litígio sobre mudança autorização ou rejeição, não deve ser um direito
de recurso para o nível superior.
4.2.6.6 implementação da mudança de Coordenação
RFCs autorizados devem ser passados para os grupos técnicos relevantes para
a construção das mudanças. É melhores práticas para fazer isso de uma
maneira formal, que podem ser controlados, por exemplo, usando ordens de
serviço. Construção de mudanças é considerado na seção 4.4.5.3.
Gestão da Mudança tem a responsabilidade de garantir que as mudanças sejam
implementadas, como previsto. Isto é principalmente uma função de
coordenação, como a implementação real será da responsabilidade de outras
pessoas (por exemplo, especialistas técnicos de hardware irá implementar
mudanças de hardware).
Remediação procedimentos deve ser preparado e documentado com
antecedência, para cada autorizado mudar, De modo a que se erros ocorrer
durante ou após a implementação, estes procedimentos podem ser ativadas
rapidamente com o mínimo impacto em serviço qualidade. Autoridade e
responsabilidade para invocar remediação é especificamente mencionada na
documentação mudança.
Gestão da Mudança tem um descuido papel para garantir que todas as
alterações que podem ser são exaustivamente testados. Em todos os casos que
envolvem mudanças que não foram totalmente testadas, cuidado especial deve
ser tomado durante a implementação.
Os testes podem continuar em paralelo com início viver uso de um serviço - a
olhar para situações inusitadas, inesperado ou futuro, de forma que a ação
corrigindo ainda pode ser tomada antes de qualquer erro detectado tornar-se
evidente, ao vivo operação.
A implementação de tais mudanças devem ser agendadas quando o mínimo
impacto sobre os serviços ao vivo é provável. Pessoal de apoio deve estar na
mão para lidar rapidamente com qualquer incidentes que possam surgir.
4.2.6.7 Análise e registro de mudança perto
Após a conclusão da mudança, os resultados devem ser relatados para
avaliação aos responsáveis pela gestão de mudanças e, em seguida, apresenta-

se como uma mudança completa para das partes interessadas acordo (Incluindo
o fechamento relacionado incidentes, problemas ou erro conhecidos).
Claramente, para grandes mudanças haverá mais clientes e das partes
interessadas de entrada ao longo de todo processo.
Arever também deve incluir quaisquer incidentes que surjam como resultado da
mudança (se eles são conhecidos nesta fase). Se a mudança é parte de um
serviço gerido por um fornecedor externo, informações sobre as metas
contratuais de serviços será necessário (por exemplo, não prioridade 1
incidentes durante a primeira semana após a implementação).
Uma revisão de mudança (e.g. pós-implementação revisão, PIR) devem ser
realizados para confirmar que a alteração alcançou o seu objetivos, que o
iniciador e as partes interessadas estão satisfeitos com os resultados, e que não
houve efeitos colaterais inesperados. As lições aprendidas devem ser
alimentados de volta para mudanças futuras. Pequenas organizações podem
optar por usar ponto verificação de mudanças, em vez de grande escala PIR, em
organizações maiores, a amostragem terá um valor quando há muitas mudanças
semelhantes ocorrendo.
Existe uma abordagem muito diferente e perfil de entre:
• A revisão de uma mudança de serviço - imediatamente visível para o
cliente e agendado para discussão na próxima gerenciamento de nível de
serviço reunião de avaliação
• Uma mudança de infra-estruturas - preocupados com o modo como a TI
entrega em vez do que a TI entrega, que será (quase) invisível para o
cliente.
Gestão da Mudança deve analisar os serviços novos ou alterados após um
período predefinido tenha decorrido. Este processo irá envolver os membros do
CAB, uma vez que opiniões de mudança são um item de agenda padrão CAB. O
objetivo dessas análises é estabelecer que:
• A mudança teve o efeito desejado e encontrou seu objetivos
• Usuários, clientes e outras partes interessadas estão satisfeitos com os
resultados, ou para identificar eventuais deficiências
• Não existem inesperadas ou indesejáveis efeitos secundários para a
funcionalidade, nível de serviços, garantias, por exemplo,
disponibilidade,capacidade,segurança,atuação Custos
• O recursoé usado para implementar a mudança foram como o planejado
• A liberação e desenvolvimento plano funcionou corretamente (para incluir
comentários dos implementadores)
• A mudança foi implementada em tempo e custar
• A remediação plano funcionou correctamente, se necessário.

Mais detalhes da realização de uma formal avaliação são fornecidos na Seção
4.6. Todos os problemas e discrepâncias devem ser alimentados de volta para
os membros do CAB (onde eles foram consultados ou onde uma comissão foi
convocada), impacto assessores, autoridades de produtos e liberar As
autoridades, por forma a melhorar os processos para o futuro.
Sempre que uma mudança não atingiu os seus objectivos, Gerenciamento de
Mudanças (ou o CAB) deve decidir o seguimento é necessário, o que pode
envolver a levantar uma RFC revista. Se o rever é satisfatória ou a mudança
original é abandonado (por exemplo, as circunstâncias que exigiram a alteração
não são mais actual e a exigência desaparece) o RFC deve ser formalmente
fechado na exploração madeireira sistema.
4.2.6.8 Mudança Conselho Consultivo
O Alterar Conselho Consultivo (CAB) é um órgão que existe para apoiar a
autorização de mudanças e para auxiliar na Gestão da Mudança avaliação e
priorização de mudanças. Como e quando um táxi é convocada, os membros
devem ser escolhidos, que são capazes de assegurar que todas as mudanças
dentro da escopo do CAB são adequadamente avaliados tanto um negócio e um
ponto de vista técnico.
O CAB pode ser solicitado a considerar e recomendar a aprovação ou rejeição
de mudanças apropriadas para alto nível de autorização e, em seguida
recomendações serão apresentadas à autoridade mudança adequada.
Para conseguir isso, o CAB tem de incluir as pessoas com uma compreensão
clara em toda a gama de das partes interessadas necessidades. O gerente de
mudança irá normalmente cadeira do CAB, e os membros potenciais incluem:
• Cliente (s)
• Usuário gerente (s)
• Usuário grupo representativo (s)
• Aplicaçãodesenvolvedores s / mantenedores
• Especialistas / consultores técnicos
• Serviços e pessoal de operações, por exemplo, balcão de
atendimento,teste gestão, ITSCM, segurança, A capacidade
• Instalações / funcionários do escritório de serviços (onde as mudanças
podem afetar movimentos / alojamento e vice-versa)
• Empreiteiro ou representantes de terceiros, por exemplo, em terceirização
situações
• Outras partes como aplicável a circunstâncias específicas (como a polícia
se interrupções de tráfego de marketing, provavelmente se os produtos
públicos afetados).
É importante ressaltar que o CAB:

• Será composto de acordo com as mudanças que estão sendo
consideradas
• Pode variar consideravelmente em make-up, mesmo em toda a gama de
uma única reunião
• Deve envolver fornecedors quando que seria útil
• Deve refletir tanto dos usuários quanto dos clientes e pontos de vista
• É provável que inclua o problema gerente e nível de serviço gerente e
equipe de relações com clientes de pelo menos parte do tempo.
Quando a necessidade de mudança de emergência surge, ou seja, pode não
haver tempo para convocar o CAB completa, é necessário identificar um menor
organização com autoridade para tomar decisões de emergência. Este órgão é o
Emergency Change Advisory Board (ECAB). Mudar procedimentos deve
especificar como a composição do CAB e ECAB será determinado em cada
caso, com base nos critérios listados acima e quaisquer outros critérios que
podem ser adequados para o negócio. Este destina-se a assegurar que a
composição do CAB será flexível, a fim de representar adequadamente os
interesses comerciais quando grandes mudanças são propostas. Ela irá também
assegurar que a composição do ECAB irá fornecer a capacidade, quer de um
perspectiva de negócios e do ponto de vista técnico, de tomar decisões
apropriadas em qualquer eventualidade imaginável.
Uma dica prática vale a pena ter em mente é que o CAB deveria ter declarado e
acordado avaliação critérios. Isto assistirá na mudança avaliação atividades,
atuando como um modelo ou estrutura pela qual os membros podem avaliar
cada mudança.
Reuniões CAB
Muitas organizações estão executando CABs eletronicamente, sem freqüentes
face-a-face. Há benefícios e problemas de uma tal abordagem. Grande parte
das atividades de avaliação e encaminhamento podem ser tratados por via
electrónica através de ferramentas de apoio ou de e-mail. No complexo, de
altarisco ou de alto impacto casos, as reuniões CAB formais podem ser
necessários.
Manuseio eletronicamente é mais conveniente em termos de tempo para os
membros do CAB, mas também é altamente ineficiente quando as perguntas ou
preocupações são levantadas tal que muitas comunicações ir e voltar. Um
encontro face-a-face é geralmente mais eficiente, mas apresenta programação e
tempo de conflitos entre os membros do CAB, bem como custos significativos de
viagens e funcionários para as organizações dispersas.
A experiência prática mostra que as reuniões regulares combinadas com
automação eletrônica é uma abordagem viável para muitas organizações, e que
pode ser benéfico para agendar uma reunião regular, ou quando um grande

projetos devem-se a entregar liberars. As reuniões pode então ser usado para
fornecer um formal rever e cadastre-off de mudanças autorizadas, uma revisão
das alterações pendentes, e, claro, para discutir quaisquer mudanças iminentes
principais. Onde as reuniões são apropriadas, eles devem ter uma agenda
padrão.
Uma agenda CAB padrão deve incluir:
• Alterações não autorizadas, fracassados, com cópia de as mudanças, ou
mudanças aplicadas sem referência ao CAB gerenciamento de
incidentes,gestão de problemas ou Gestão da Mudança
• RFCs para ser avaliados por membros do CAB - em estruturado e
prioridade ordem
• RFCs que foram avaliados por membros do CAB
• Agendamento de mudanças e atualização de alteração de horário (CS) e
PSO
• Mudar opiniões
• A Gestão da Mudança processo, Incluindo quaisquer alterações feitas a
ele durante o período em discussão, assim como as mudanças propostas
• Alterar vitórias Gestão / realizações no período em discussão, ou seja,
uma revisão do negócio benefícios acumulados por meio do processo de
Gerenciamento de Mudança
• Alterações pendentes e mudanças em andamento
• O aviso prévio de RFCs esperado para análise em CAB próxima
• Comente de alterações não autorizadas detectados através de
Gerenciamento de Configuração.
CAB reuniões representam um grande potencial despesas gerais no tempo dos
membros. Portanto, todos os RFCs, juntamente com o SC e PSO, deve ser
distribuído com antecedência, e flexibilidade permitida aos membros do CAB
sobre a possibilidade de comparecer em pessoa, para enviar um deputado, ou
para enviar comentários. Documentos relevantes devem ser distribuídos com
antecedência para permitir que os membros do CAB (e outros que são
necessários pelo Gerenciamento de Mudanças ou membros do CAB) para
realizar impacto e recurso avaliações.
Em algumas circunstâncias, será desejável RFCs mesa em uma reunião CAB
para explicações mais detalhadas ou esclarecimentos antes de os membros do
CAB assumir os papéis de distância para a consideração, a tempo para uma
reunião posterior. A 'passo a passo' de grandes mudanças podem ser incluídos
em uma reunião CAB antes de apresentação formal do RFC.
Membros do CAB deve vir às reuniões preparados e capacitados para expressar
opiniões e tomar decisões em nome da área que eles representam em relação
às RFCs apresentados, com base na avaliação prévia dos RFCs.

O CAB deve ser informado de qualquer mudança de emergências ou mudanças
que foram implementadas como um solução alternativa para incidentes e deve
ser dada a oportunidade de recomendar medidas de acompanhamento para
eles.
Note-se que o CAB é um órgão apenas consultivo. Se o CAB não pode
concordar com uma recomendação, a decisão final sobre se autoriza mudanças,
e comprometer-se a despesa envolvida, é de responsabilidade da administração
(normalmente o diretor de TI ou o diretor de serviços, gerente de serviço ou
mudar gerente como seu representante delegado). O Gestão da Mudança plano
de autorização deve especificamente o nome da pessoa (s) autorizada a assinar
RFCs.
4.2.6.9 mudanças de emergência
Mudanças de emergência às vezes são necessários e devem ser projetados
com cuidado e testado antes do uso ou o impacto da emergência mudar pode
ser maior do que o incidente original. Mudanças de emergência podem
documentar alguns detalhes retrospectivamente.
O número de alterações propostas emergência devem ser mantidos a um
mínimo absoluto, porque eles são geralmente mais perturbador e propenso a
falha. Todas as alterações que possam ser necessárias devem, em geral, ser
prevista e planeada, tendo em conta o disponibilidade de recursos para construir
e teste as alterações. No entanto, ocasiões ocorrerá quando mudanças de
emergência são essenciais e assim procedimentos devem ser criados para lidar
com eles rapidamente, sem sacrificar a controles normais de gestão.
Mudança de emergência é reservada para as alterações destinadas a reparar
um erro num De serviços de TI que está impactando negativamente o negócio a
um alto grau. Alterações destinadas a introduzir melhorias de negócios
imediatamente necessárias são tratadas como mudanças normais, avaliado
como tendo o mais alto urgência.
Autorização mudança de emergência
Níveis de autorização definidos existirá para uma mudança de emergência, e os
níveis de autoridade delegada deve ser claramente documentados e
compreendidos. Em uma situação de emergência, pode não ser possível a
convocação de uma reunião CAB completa. Sempre que a aprovação CAB é
necessária, esta será fornecida pelo CAB Emergência (ECAB).
Nem todas as alterações de emergência exigirá o envolvimento ECAB, muitos
podem ser previsíveis, tanto na ocorrência e resolução e bem compreendido
alterações disponíveis, com autoridade delegada, por exemplo, para as equipes

de Operações que irá documentar ação e relatório sobre a mudança de
emergência.
Emergência mudança edifício, teste e implementação
Mudanças autorizadas são alocados para o grupo técnico relevante para a
construção. Onde prazos exigem, Gestão da Mudança, Em colaboração com o
gerente técnico adequado, garante que o pessoal suficiente e recursos (tempo
de máquina, etc) estão disponíveis para fazer este trabalho. Procedimentos e
acordos - aprovada e apoiada pela administração - devem estar no local para
permitir isso. Remediação também devem ser abordadas.
Como teste de grande parte da mudança de emergência como é possível, deve
ser realizado. Muda completamente não testados não deve ser implementado
em sua totalidade evitável. Claramente, se a mudança der errado, o custar é
geralmente maior do que a de um teste adequado. Deve ser dada atenção para
o quanto custaria para testar todas as mudanças totalmente contra o custo da
mudança não consignado pela probabilidade antecipada de sua falha.
Isto significa que, quanto menos a mudança é considerado susceptível de falhar,
mais razoável de que possa ser o de reduzir o grau de teste em caso de
emergência. (Lembre-se que ainda há mérito em testes, mesmo depois de uma
mudança passou viver.) Quando apenas um teste limitado é possível - e
presumindo que o desenvolvimento paralelo de mais robusto versãos continua
ao lado da mudança de emergência - em seguida, o teste deve ser dirigida a:
• Aspectos da serviço que será usado imediatamente (por exemplo,
características de entrada diário, e não de fim de mês-rotinas)
• Elementos que causam a maioria inconveniente de curto prazo.
A empresa deve estar ciente dos riscos associados e ser responsável por
finalmente aceitar ou rejeitar a mudança com base nas informações
apresentadas.
Gestão de mudança irá dar um aviso prévio, tanto quanto possível para o balcão
de atendimento e outros das partes interessadass, e mandar para a presença
técnica adequada para estar disponível, para apoiar Operação de Serviços.
Se uma mudança, uma vez implementado, não corrigir o erro urgente pendente,
pode haver necessidade de ser iterativo tentativas de correções. Gestão da
Mudança deve assumir a responsabilidade neste momento para garantir que
negócio necessidades permanecem a principal preocupação e que cada iteração
é controlada pela maneira descrita nesta secção. Gestão da Mudança deve
assegurar mudanças abortivos são rapidamente desistiu.

Se muitas tentativas em uma mudança de emergência são abortivos, as
seguintes perguntas devem ser feitas:
• Tem o erro foram corretamente identificados, analisados e
diagnosticados?
• Tem a proposta resolução foi adequadamente testado?
• Tem a solução foi corretamente implementado?
Em tais circunstâncias, pode ser preferível proporcionar um serviço parcial, com
alguns usuário instalações de retirada, de modo a permitir a alteração a ser
testados ou de suspender o serviço temporariamente e, em seguida, aplicar a
mudança.
Documentação mudança de emergência
Pode não ser possível atualizar todos Gestão da Mudança registros no momento
em que ações urgentes estão sendo concluídas (por exemplo, durante o
trabalho durante a noite ou fim de semana). É, no entanto, essencial que os
registos temporários são feitos durante esses períodos, e que todos os registos
são concluídas, retrospectivamente, a oportunidade mais cedo possível.
Incidente controlar operações de pessoal, informática e pessoal de
gerenciamento de rede pode ter delegado autoridade para contornar certos tipos
de incidente (Por exemplo, hardware falha) Sem autorização prévia por Change
Management. Contornadas deve ser limitado às ações que não alteram o
especificação de serviço ativos, e que não pretendem corrigir software erros. Os
métodos preferidos para contornar incidentes causados por erros de software
deve ser o de reverter para o estado anterior de confiança ou de versão,
conforme o caso, em vez de tentar uma mudança não planejada e
potencialmente perigoso. Aprovação de mudanças ainda é um pré-requisito.
Efetivamente, o mudança de emergência procedimento seguirá o procedimento
de mudança normal, exceto que:
• A aprovação será dada pelo ECAB invés de esperar por uma reunião
CAB
• Os testes podem ser reduzidas, ou em casos extremos, completamente
não cobrados, se considerado necessário um risco para proporcionar a
mudança imediatamente
• Documentação, ou seja, a atualização do alterar o registro e os dados de
configuração, pode ser adiada, normalmente até as horas normais de
trabalho.

Os pedidos de mudança pode ser desencadeada em todo o serviço ciclo de vida
e nas interfaces com outras organizações, por exemplo, clientes e fornecedors.
Haverá também outros das partes interessadass, como parceiros que possam
estar envolvidos com os processos de Gestão da Mudança.
Exemplos típicos de tipos de alterações que provocam a Gestão da Mudança
processo encontram-se descritos abaixo.
Mudanças estratégicas
Estratégias de serviço exigir mudanças a serem implementadas para alcançar
objetivos específicos objetivos, minimizando custos e riscos. Não há custo-livre e
livre de riscos estratégico planos ou iniciativas. Há sempre custos e riscos
associados com decisões como a introdução de novos serviços, entrando em
nova espaço de mercados, e servir novos clientes. Os seguintes são exemplos
de programas e iniciativas que implementam mudanças estratégicas:
• Legal / regulamentar mudança
• Mudança organizacional
• Política e padrãos mudanças
• Mudar depois de analisar negócios, cliente e usuário atividade padrões
• Adição de novos serviço ao espaço de mercado
• Atualizações para o Portfólio de Serviços,carteira de clientes ou carteira
de contratos
• Mudança de terceirização modelo
• Inovação tecnológica.
Mudar para um ou mais serviços
Alterações nos serviços previstos (na Carteira de Serviço) e alterações nos
serviços do catálogo de serviços irá acionar o Gestão da Mudança processo.
Estes incluem alterações:
• Catálogo de serviços
• Pacote de serviços
• Serviço de definição e características
• Solte pacote
• Capacidade e recurso exigências
• Exigência de nível de serviços
• Garantias
• Utilitários
• Custar de utilização
• Serviço de ativoss
• Critérios de Aceitação

• Prevista qualidade de serviço
• Prevista atuação
• Valor previsto
• Organizacional projeto
• Stakeholder e comunicações planos
• Mudança física no ambiente, E.g. edifício
• Medição sistema
• Planos, por exemplo, capacidade, ITSCM, mudança,
transição,teste,liberar e desenvolvimento planos
• Descomissionamento /aposentar serviços
• Procedimentos, manuais, balcão de atendimento scripts.
Mudança operacional
É importante saber a distinção entre diferentes tipos de solicitações que vai ser
iniciada por usuários. Estes tipos de solicitação vai depender da natureza do
organização e serviços e pode incluir pedidos como redefinição de senha,
solicitação de acesso ou solicitação para mover um ativo de TI.
Operação de Serviços pessoal também irá implementar mudanças corretivas e
preventivas, através do procedimento de mudança de padrão, que devem ser
gerenciados através de Gestão da Mudança, E.g. servidor re-boot, o que pode
afetar um serviço compartilhado.
Mudanças para entregar a melhoria contínua
Quando CSI determina que uma melhoria neste serviço não se justifica, uma
RFC deve ser submetida ao Gerenciamento de Mudanças. Alterações como
mudanças nos processos pode ter um efeito sobre a prestação de serviços e
também pode afetar outras iniciativas CSI.
Alguns estratégia e alterações de serviço será iniciado pelo CSI.
4.2.7.1 Entradas
Alterações podem ser apresentadas como um RFC, muitas vezes com um
associado mudar proposta, que prevê o detalhe de como a mudança vai
acontecer, por exemplo, abordar a implementação de uma alteração legislativa.
A proposta de mudança será baseada numa alterar modelo e fornecer mais
detalhes sobre a mudança específica proposta. As entradas são:
• Política e estratégias de mudança e liberar
• Requisição de Mudança
• Alterar proposta
• Planos - de mudança, transição, Lançamento,
desenvolvimento,teste,avaliação e remediação

• Atual alteração de horário e PSO
• Atual ativoss ou item de configuraçãos, por exemplo, linha de base,pacote
de serviços, Pacote de lançamento
• Como planejado configuração de referência
• Os resultados do teste, o relatório de teste e relatório de avaliação.
4.2.7.2 Saídas
As saídas do processo será:
• RFCs rejeitados
• RFCs aprovados
• Mude para o de serviços, serviço ou infra-estrutura resultante da RFCs
aprovados
• Novos, alterados ou eliminados ativos ou item de configuraçãos, por
exemplo, linha de base, pacote de serviços pacote de lançamento,
• Alteração de horário
• PSO revista
• Mudança autorizada planos
• Alterar as decisões e ações
• Mudar documentos e registros
• Gestão da Mudança relatórios.
4.2.7.3 Interfaces
A fim de ser capaz de definir limites claros, dependências e regras, de mudança
e gerenciamento de liberação devem ser integrados com os processos utilizados
para organizacional programas ou projetos, gestão de fornecedores e também
integrado com os processos dos fornecedores e procedimentos. Haverá
ocasiões em que uma mudança proposta irá, potencialmente, ter uma maior
impacto em outras partes do organização (Por exemplo, instalações ou
operações comerciais), Ou vice-versa, e do processo de mudança de serviço
deve interagir adequadamente com outros processos envolvidos.
Integração com os processos de mudança de negócios
Se necessário, a Gestão da Mudança deve ser envolvido com programa de
negócios e equipes de negócios de gerenciamento de projetos para garantir que
questões de mudança, objetivos, impactos e desenvolvimentos são trocados e
em cascata em toda a organização, quando aplicável. Isto significa que qualquer
alteração negócio ou projeto entregas que não serviços de impacto ou
componentes de serviço podem ser objecto de negócio ou projeto de Gestão da
Mudança procedimentos, em vez de o De serviços de TI Alterar os
procedimentos de gestão. No entanto, os cuidados devem ser tomados para
garantir que as mudanças de configuração do serviço linha de bases e liberars
fazer seguir o Gerenciamento de Mudança processo. A equipe de Gestão de

Mudanças, no entanto, espera-se que manter uma estreita ligação com os
projetos para garantir a boa execução e coerência no âmbito da gestão de
mudança ambientes.
Programa e gerenciamento de projetos
Programa e gerenciamento de projeto devem trabalhar em parceria para alinhar
todos os processos e pessoas envolvidas no serviço iniciativas de mudança.
Quanto mais perto estão alinhados, maior a probabilidade de que o esforço de
mudança será movido para a frente durante o tempo que demora a completar.
Alterar representantes de gestão podem participar nas suas reuniões relevantes
do projeto.
Terceirização e parcerias acordos devem definir claramente o nível de
autonomia pode ter um parceiro na implementação de mudanças dentro de seu
domínio de serviço, sem referência ao total provedor de serviços.
Uma chave componente é como mudar profundamente processos e ferramentas
são incorporados no fornecedor organização ou vice-versa e onde o veto
liberação ocorre. Se o fornecedor tem a responsabilidade pela disponibilidade do
operacional serviço, podem surgir conflitos.
Terceirização e parcerias
Terceirização e parcerias incluem fornecedores internos e externos e
fornecedores que estão fornecendo um novo ou existente serviço para a
organização. Práticas de mudança efetiva de gestão e princípios devem ser
postas em prática para gerenciar esses relaçãos de forma eficaz para garantir a
entrega suave de serviço. Esforço também deve ser colocado em descobrir o
quão bem os próprios parceiros gerir a mudança e escolha de parceiros e
relações de fornecimento em conformidade.
É importante assegurar que os prestadores de serviços (terceirizados ou em
casa) fornecer a Gestão da Mudança função e processos que atendam às
necessidades da empresa e clientes. Algumas organizações em terceirização
situações, consulte RFCs aos seus fornecedores para estimativas anteriores à
aprovação de mudanças. Para mais informações, consulte o ITIL Design de
Serviços publicação e orientação sobre gestão de fornecedores.
4.2.7.4 Interfaces no Gerenciamento de Serviços
O Serviço de Gestão de processos podem exigir mudanças e melhorias.
Muitos também estar envolvidos na impacto avaliação e implementação de
alterações de serviço, tal como discutido abaixo.

Ativos e Gerenciamento da Configuração
O Sistema de Gerenciamento da Configuração fornece acesso confiável e rápido
e fácil a informações sobre a configuração exata para permitir das partes
interessadass e pessoal para avaliar o impacto das mudanças propostas e para
acompanhar as mudanças de fluxo de trabalho. Esta informação permite que a
correta ativos e serviço componente versãos para ser liberado para a parte
apropriada ou para o correto ambiente. Como as mudanças são implementadas,
o Gerenciamento da Configuração informações são atualizadas.
O CMS também pode identificar relacionado CI / ativos que serão afetados pela
mudança, mas não incluídas no pedido inicial, ou de fato semelhante CI / activos
que se beneficiariam da mudança semelhante.
Uma visão geral de como a mudança e os processos de gerenciamento de
configuração trabalhar juntos para uma mudança individual é mostrado na figura
4.6.
Pedido Figura 4.6 para o fluxo de trabalho de Mudança e as principais interfaces
de gerenciamento de configuração
Gerenciamento de Problemas
Gerenciamento de Problemas é outra chave processo como as mudanças são
necessárias para implementar solução alternativas e fixar erro conhecidos.
Gerenciamento de Problemas é uma das principais fontes de RFCs e também
muitas vezes um contribuinte importante para a discussão CAB.
Continuidade do Serviço de TI
De serviços de TI Continuidade tem muitos procedimentos e planos deve ser
atualizado via Gestão da Mudança para garantir que elas são precisas,
atualizadas e que das partes interessadass estão cientes das mudanças.

Gestão de Segurança
Gestão de Segurança interfaces com o Gerenciamento de Mudanças desde
mudanças exigidas pela segurança vai passar por processo de Gerenciamento
de Mudança e segurança será um fator chave para a discussão CAB em muitos
serviços. Cada significativa mudar serão avaliados pelo seu impacto potencial
sobre o plano de segurança.
Capacidade e Gestão da Demanda
Capacidade e Gerenciamento da Demanda é um aspecto crítico da Gestão da
Mudança. Demanda mal gerenciado é uma fonte de custos e risco para provedor
de serviçoss, porque há sempre um grau de incerteza associado à demanda de
serviços. Gerenciamento da Capacidade tem um importante papel ao avaliar as
alterações propostas - não apenas as mudanças individuais, mas o impacto total
de alterações na capacidade de atendimento. Alterações decorrentes da gestão
de capacidade, incluindo as estabelecidas na plano de capacidade, Será iniciado
como RFCs através do processo de mudança.
Gestão da Mudança deve garantir que as medidas têm um significado
específico. Embora seja relativamente fácil de contar o número de incidentes
que, eventualmente, gerar mudanças, é infinitamente mais valioso de olhar para
a causa de tais mudanças, e para identificar tendências. Melhor ainda de ser
capaz de medir a impacto de mudanças e demonstrar perturbação reduzida ao
longo do tempo por causa da introdução de Gerenciamento de Mudança, e para
medir a velocidade e eficácia com o qual o provedor de serviços responde às
necessidades de negócio identificados.
As medidas tomadas devem estar ligados aos objetivos de negócio sempre que
possível - e custar, Serviço de disponibilidade, E confiança. Qualquer previsão
devem ser comparados com as medições reais.
O indicador chave de desempenhos para Gestão de Mudanças são:
• O número de mudanças implementadas aos serviços que conheceu o
cliente concordou exigências, por exemplo, qualidade/ Custo / tempo
(expresso como uma percentagem de todas as alterações)
• Os benefícios da mudança expressa como "valor de melhorias feitas '+'
negativo impactos impedido ou rescindido "em comparação com os
custos do processo de mudança
• Redução do número de interrupções de serviços, defeitos e re-trabalho
causados pela imprecisa especificação, Pobre ou incompleta impacto
avaliação
• Redução do número de alterações não autorizadas

• Redução no acúmulo de mudar pedidos
• Redução do número e porcentagem de mudanças não planejadas e
correções de emergência
• Taxa de variação sucesso (percentagem de mudanças considerado bem
sucedido em rever/ Número de RFCs aprovados)
• Redução do número de alterações em que remediação é invocado
• Redução do número de alterações falharam
• O tempo médio para implementar com base em urgência/prioridade/
Alteração do tipo de
• Incidentes atribuíveis a modificações
• Precisão percentual na estimativa mudança.
Naturalmente existe outra gestão da informação exigida em torno da mudança e
as estatísticas devem ser recolhidas e analisadas para garantir eficiente e eficaz
processo, Mas para organizações com um 'painel de instrumentos'Relatando
abordagem, estas são boas métricas para usar.
Medidas significativas são as de que a administração pode fazer oportunas e
precisas decisões acionáveis. Por exemplo, os dados sobre o número de
mudanças é insignificante. O relatório sobre a relação entre mudanças
implementadas contra RFCs recebidos fornece uma eficiência classificação. Se
essa avaliação é baixo, a gestão pode ver facilmente que as mudanças não
estão sendo processadas de forma eficiente e eficaz e, em seguida, tomar
medidas oportunas para corrigir as deficiências que causam isso.
4.2.8.1 Exemplos de tipos de medidas para a mudança
Alguns exemplos dos tipos de medidas utilizadas dentro das organizações são
listados aqui, os acumulação relevantes em cada circunstância diferente irá
variar entre as organizações e ao longo do tempo, como o processo de mudança
(e outros elementos de ITSM) maduro. A maioria das medidas mencionadas,
pode ser útil discriminadas por categoria, Divisão organizacional, geografia,
fornecedor, Etc
Medidas de saída
• Número de interrupções, incidentes, problemas /erros causada por
mudanças mal sucedidas e liberars
• Mudança imprecisa especificaçãos (por exemplo, técnicas, cliente,
negócio)
• Incompleto impacto avaliação
• Mudança negócio / cliente não autorizado por negócio / TI / cliente /
usuário ativos ou item de configuração tipo, por exemplo, dados de
aplicativos
• Redução percentual no tempo, esforço, custar para fazer mudanças e
liberações (por exemplo, serviço, tipo de alteração, tipo de ativos)

• Serviço ou aplicação re-trabalho provocado pela especificação mudança
inadequada
• O percentual de melhoria nas previsões para o tempo, qualidade, Custo,
risco,recurso e comercial impacto
• O percentual de melhoria na análise de impacto e programação de
mudanças de forma segura, eficiente e eficaz reduz o risco de mudanças
que afetam a viver ambiente
• Percentagem de redução alterações não autorizadas.
As cargas de trabalho
• Freqüência de troca (por serviço, área de negócio, etc)
• Volume de mudança.
Medidas de processo
• Satisfação das pessoas com a velocidade, a clareza, a facilidade de uso
• Número e porcentagem de mudanças que seguem formais Gestão da
Mudança procedimentos
• Razão de mudanças planejadas vs não planejada (urgência, emergência)
• Proporção de aceite rejeitado mudar pedidos
• Número de alterações registrados e monitorados usando ferramentas
automatizadas
• Tempo para executar uma mudança (de iniciação através de cada fase do
ciclo de vida de uma mudança, terminando em conclusão):
• Por estágio do ciclo de vida
• Pelo serviço
• Por plataforma de infra-estrutura
• Utilização do pessoal
• Custar contra orçamento.

4,3 Ativo de Serviço e Gerenciamento de Configuração
Esta seção aborda a processo de Ativo de Serviço e Gerenciamento de
Configuração (SACM) dentro IT Service Management. Não organização pode
ser totalmente eficiente ou eficaz, a menos que gere os seus bens bem,
especialmente aqueles ativos que são vitais para o funcionamento do cliente ou
da organização negócio. Este processo gere o serviço ativos, a fim de apoiar os
processos de Gerenciamento de Serviço outros.
Objetivo 4.3.1, finalidade e objectivo
O objectivo da SACM é:
• Identificar, controlar, Relatório, registo, auditar e verificar ativos de
serviços e item de configuraçãos, incluindo versãos, linha de bases
constituinte, componentes, o atributos, e relaçãos
• Conta para, gerenciar e proteger a integridade de bens de serviço e itens
de configuração (e, quando apropriado, dos seus clientes), através do
serviço ciclo de vida , assegurando que apenas os componentes
autorizados sejam utilizados apenas autorizada e as mudanças são feitas
• Proteger a integridade de serviço ativos e itens de configuração (e,
quando apropriado, dos seus clientes), através do ciclo de vida do serviço
• Assegurar a integridade do ativoss e configurações requeridas para
controlar os serviços e Infra-estrutura de TI por estabelecer e manter um
preciso e completo Sistema de Gerenciamento da Configuração.
Os objetivos da Gerenciamento da Configuração são os seguintes:
• Apoiar o negócio e controle de cliente objetivos e exigências
• Apoiar os processos de gestão eficiente e eficaz de serviço, fornecendo
informações sobre a configuração exata para permitir as pessoas a tomar
decisões no momento certo, por exemplo, para autorizar a mudança e
liberars, resolver incidentes e problemas mais rápido.
• Minimize o número de qualidade e observância problemas causados pela
configuração inadequada de serviços e bens
• Otimizar o serviço ativos, configurações, recursos e recursos.
O objetivo é definir e controlar os componentes de serviços e de infra-estrutura e
manter informações de configuração precisas sobre o estado histórico,
planejado e atual dos serviços e infra-estrutura.
4.3.2 Âmbito
Gestão de Ativos abrange os activos de serviços em todo o território serviço
ciclo de vida. Ele fornece um inventário completo dos bens e que é responsável
por seu controle. Ela inclui:

• Completo ciclo de vida gestão de TI e ativos de serviços, desde o ponto
de aquisição até à sua eliminação
• Manutenção do inventário de ativos.
Gerenciamento da Configuração garante que selecionado componentes de um
serviço completo, sistema ou produto (configuração) são identificados, linha de
based e mantidos e que as alterações deles são controlados. Ele também
garante que a libertação controlada em ambientes e operacional utilizar são
feitas com base em aprovações formais. Ele fornece uma configuração modelo
dos serviços, bens e infra-estrutura, registrando a relaçãos entre os ativos de
serviços e itens de configuração. SACM pode abranger não-ativos de TI,
produtos de trabalho utilizados para desenvolver os serviços e item de
configuraçãos necessária para suportar o Serviço que não são formalmente
classificados como ativos.
O escopo cobre interfaces interna e prestador de serviços externos em que são
activos e itens de configuração que precisam de ser controladas, por exemplo,
compartilhados ativos.
Otimizando o atuação de ativos de serviços e configurações melhora o
desempenho geral do serviço e otimizars os custos e riscos causados por ativos
mal gerenciados, por exemplo, interrupções de serviços, multas, taxas de
licenciamento corretas e auditorias falhou.
SACM fornece visibilidade de representações precisas de um serviço, liberação,
ou ambiente que permite:
• Uma melhor previsão e planejamento de mudanças
• Alterações e liberars para ser avaliado, planejado e entregue com
sucesso
• Incidentes e problemas para ser resolvida dentro do meta de nível de
serviços
• Nível de serviços e garantias a serem entregues
• Melhor adesão ao padrãos, obrigações legais e regulamentares (menos
não-conformidades)
• Mais oportunidades de negócios, capazes de demonstrar controle de
bens e serviços
• Alterações a rastreável de exigências
• A capacidade de identificar os custos de um serviço.
Em ambientes distribuídos e serviços compartilhados, os componentes de
serviços individuais existir dentro de diversos serviços e estrutura de

configuraçãos. Por exemplo, uma pessoa pode usar um computador de mesa
que está na rede para um edifício, mas pode estar executando um centro
financeiro sistema que está ligado a uma base de dados sobre o outro lado do
mundo. Uma mudança para a rede ou o sistema financeiro pode ter um impacto
sobre essa pessoa e seu / sua processo de negócio. Em serviços baseados na
web, pode haver feeds de dados e interfaces de e para serviços de propriedade
de outras organizações. Mudanças na essas interfaces têm de ser geridos e é
importante para identificar a interface de dados, tais como alimentos e o
proprietário / custodiante destes. Alterações em quaisquer itens de interface
precisa ser gerenciado através Gestão da Mudança.
4.3.4.1 Ativo de Serviço e políticas de gerenciamento de configuração
O primeiro passo é desenvolver e manter as políticas que definem o SACM
objetivos, escopo e princípios e fator crítico de sucessos (QCA) para o que deve
ser atingido pela processo. Essas políticas são muitas vezes considerados com
a mudança e Gerenciamento de Liberação e Implantação políticas como eles
estão intimamente relacionados. As políticas serão com base na organização do
negócio motoristas, contratuais e Serviço de Gestão de requisitos e em
observância de leis, regulamentos e normas.
Políticas de ativos pode ser aplicável para os tipos de ativos ou serviços
específicos, por exemplo, desktop.
Existem custos significativos e recursoimplicações s para implementar decisões
e, portanto, estratégica SACM precisam ser feitas sobre as prioridades a serem
abordadas. Muitos Provedor de serviços de TIs se concentrar inicialmente nas
básicos ativos de TI (hardware e software) e os serviços e bens que são
essenciais de negócios ou ao abrigo de conformidade legal e regulamentar, por
exemplo, Sarbanes-Oxley, de licenciamento de software.
Ativo de Serviço e os princípios de gerenciamento de configuração
O principal política define o enquadramento e os princípios-chave contra a qual
os ativos e configurações são desenvolvidas e mantidas. Princípios comuns
incluem:
• Garantir que Ativos e operações de Gerenciamento de Configuração
custos e recursos são compatíveis com os riscos potenciais para os
serviços
• A necessidade de cumprir corporativa governo requisitos, por exemplo,
software gestão de activos, Sarbanes-Oxley
• A necessidade de cumprir o capacidade, Recursos e garantias de
serviços definidas pela acordo de nível de serviços e contratos
• O exigência disponíveis, para serviços confiáveis e de baixo custo

• O requisito para o desenvolvimento econômico claro e atuação critérios
para intervenções que reduzam os custos ou otimizar prestação de
serviços, por exemplo, menor custo de manutenção
• A aplicação de toda vida custar Os métodos de avaliação
• A transformação de "encontrar e corrigir" manutenção reativa para "prever
e prevenir" gestão proativa
• A necessidade de manter adequada dos activos e informações de
configuração para interno e externo das partes interessadass
• O nível de controlar e requisitos de rastreabilidade e auditabilidade
• A aplicação de métodos de melhoria contínua para optimizar o nível de
serviços, ativos e configurações
• Prestação de ativos precisos e informações de configuração para outros
negócios e Serviço de Gestão de processos
• Integração de Ativos e Gerenciamento da Configuração com outros
processos
• A migração para um bem comum e CMS arquitetura
• Nível de automação para reduzir erros e custos.
4.3.4.2 Conceitos básicos
O modelo de configuração
Gerenciamento da Configuração proporciona um modelo dos serviços, bens e
infra-estrutura, registrando a relaçãos entre item de configuraçãos, como
mostrado na Figura 4.7. Isso permite que outros processos para acessar
informações valiosas, por exemplo:
• Para avaliar o impacto ea causa de incidentes e problemas
• Para avaliar o impacto das mudanças propostas
• Para planejar e projeto serviços novos ou modificados
• Para planejar atualização de tecnologia e atualizações de software
• Para planejar liberar e desenvolvimento pacotes e migram serviço ativos
para diferentes locais e centros de serviços
• Para otimizar utilização de recursos e custos, por exemplo, consolidar
data centers, reduzir as variações e reutilização de ativos.

Figura 4.7 Exemplo de um modelo de configuração lógico
O verdadeiro poder do modelo lógico de Gerenciamento de Configuração de
serviços e de infra-estrutura é que ela é o modelo - uma única representação
comum usado por todas as partes IT Service Management, E além, como RH,
finanças, fornecedor e clientes.
"Dinamarquês relógio '
Há um provérbio tradicional dinamarquesa que corre "Quando você tem um
relógio em sua casa, você sabe que o tempo -. Uma vez que você tem dois
relógios que não são mais determinados" SACM proporciona que um relógio
para todos os processos e assim cola-los juntos, proporciona consistência e
ajuda a alcançar um propósito comum. (De Hans Dithmar)
Os itens de configuração e informações de configuração relacionados, podem
estar em vários níveis de detalhe, por exemplo, uma visão geral de todos os
serviços, ou um nível detalhado para ver o especificação para um serviço
componente.
Gerenciamento de Configuração deve ser aplicado a um nível mais detalhado,
onde o provedor de serviços requer apertado controlar, Rastreabilidade e
acoplamento rígido de informações de configuração através do serviço ciclo de
vida.
Itens de configuração
Aitem de configuração (IC) é uma ativos, Serviço de componente ou outro item
que é, ou será, sob a controlar de Gerenciamento de Configuração. Os itens de
configuração podem variar muito em tamanho, complexidade e tipo, variando de
todo um serviço ou sistema incluindo todo o hardware, software, documentação
e pessoal de apoio para um módulo de software único ou um componente de
hardware menor. Os itens de configuração podem ser agrupados e geridos em
conjunto, por exemplo, um conjunto de componentes pode ser agrupado em

uma liberar. Os itens de configuração devem ser seleccionados com base em
critérios de selecção estabelecidos, agrupados, classificados e identificados de
tal modo que eles são controláveis e rastreáveis durante todo o serviço ciclo de
vida.
Haverá uma grande variedade de IC, as seguintes categorias podem ajudar a
identificá-los.
• Serviço de ciclo de vida de CIs tais como o Business Case,Serviço de
Gestão de Planos, serviços de ciclo de vida planos, Pacote de Desenho
de Serviço, Lançamento e planos de mudança, e teste planos. Eles
fornecem um quadro de serviços do prestador de serviços, como esses
serviços serão prestados, quais os benefícios que são esperados, o que
custar, E quando eles serão realizados.
• Serviço de CIs tais como:
• Serviço capacidade ativos: gestão, organização, Processos,
conhecimentos, pessoas
• Serviço recurso ativos: capital financeiro, os sistemas, aplicaçãos,
informações, dados, infra-estrutura e instalações, capital financeiro,
as pessoas
• Serviço modelo
• Pacote de lançamento
• Critérios de aceitação de serviços.
• Organização CIs - Alguns documentação vai definir as características de
um CI enquanto outra documentação será um CI em seu próprio direito e
precisam ser controlados, por exemplo, da organização negócio
estratégia ou de outras políticas que são internas à organização, mas
independente do provedor de serviços. Regulamentar ou estatutária
exigências também formar produtos externos que necessitam de ser
controladas, como fazem os produtos compartilhados entre mais de um
grupo.
• Interna CIs compreendendo aqueles fornecidos pelo indivíduo projetos,
incluindo activos tangíveis (centro de dados) e intangíveis, como software
que são obrigados a fornecer e manter o serviço e infra-estrutura.
• CIs externo tal como cliente externo exigências e acordos, liberars a
partir de fornecedors ou sub-empreiteiros e serviços externos.
• Interface de CIs que são necessários para proporcionar a extremidade-a-
ponta serviço através de um interface do provedor de serviço (SPI).
4.3.4.3 Sistema de Gerenciamento da Configuração
Para gerenciar grandes e complexos De serviços de TIs e infra-estruturas, Ativo
de Serviço e Gerenciamento de Configuração requer o uso de um suporte
sistema conhecido como o Sistema de Gerenciamento da Configuração (CMS).

O CMS tem todas as informações para CIs dentro do designado escopo. Alguns
desses itens têm relacionado especificaçãos ou ficheiros que contêm os
conteúdos do item, por exemplo, software, documento ou fotografia. Por
exemplo, um serviço de CI irá incluir os detalhes como fornecedor, custar, Data
da compra e data de renovação de licenças e manutenção contratos ea
documentação relacionada, como SLAs e subjacente contratos.
O CMS também é usado para uma variedade de propósitos, por exemplo dados
de ativos mantidos no CMS podem ser colocados à disposição financeira
externa Gestão de Ativos sistemas para executar processos de ativos
específicos de gerenciamento de relatórios fora do Gerenciamento da
Configuração.
O CMS mantém a relaçãos entre todos os serviços componentes e qualquer
relacionado incidentes, problemas, erro conhecidos mudanças, e documentação
de liberação e também poderá conter dados corporativos sobre os funcionários,
fornecedores, locais e unidade de negócioss, clientes e usuários.
Figura 4.8 mostra como o CMS abrange as camadas de dados e informações da
hierarquia conhecimento, informação / / conhecimento explicado na seção 4.7,
Gestão do Conhecimento.
No nível dos dados, o CMS pode levar os dados de vários CMDBs físicos, que,
juntos, constituem um CMDB federado. Outras fontes de dados também ligar
para o CMS, como as bibliotecas definitivas mídia. O CMS irá fornecer acesso a
dados em inventários de ativos sempre que possível, em vez de dados
duplicação.
Exemplo de gestão de bases de dados de configuração múltiplas
Na comumente encontrado parcialmente terceirizada provedor de serviços,
Alguns elementos do Serviço de Gestão de será terceirizada, enquanto outros
permanecerão em casa, e elementos diferentes podem ser terceirizados para
diferentes fornecedores externos. Por exemplo, o suporte de rede e hardware
pode ser manuseado por um fornecedor, ambiente e gestão de instalações pelo
fornecedor B, e vários fornecedores e aplicações gerenciamento de incidentes
tratado internamente. O balcão de atendimento terá acesso a informações para
auxiliá-los a partir do CMS, mas que sistema vai derivar sua entrada de dados a
partir de repositórios distintos - cada um de um CMDB - propriedade e mantido
pelos três partidos, mas trabalhando juntos para fornecer um conjunto de
informações única e consistente.
Informações de configuração evolui como o serviço é desenvolvido por meio do
serviço ciclo de vida. Muitas vezes, há mecanismos separados para a gestão do
ciclo de vida diferentes estágios de serviço, bem como diferentes meios de
gestão diferente aplicaçãos e plataformas.

Figura 4.8 Exemplo de um Sistema de Gestão de Configuração
O CMS geralmente contém dados de configuração e informações que
combinadas em um conjunto integrado de pontos de vista de diferentes das
partes interessadass através do ciclo de vida de serviço, tal como ilustrado na
Figura 4.8. É, portanto, precisa ser baseada em tecnologias apropriadas de
comunicação, web e banco de dados que fornecem visualização flexível e
poderoso e ferramentas de mapeamento, interrogatório e instalações de
comunicação.
Muitas organizações já estão usando alguns elementos de SACM, muitas vezes,
a manutenção registros em documentos, folhas de cálculo ou base de dados
local, e alguns deles podem ser usados no CMS em geral.
Processos automatizados para carregar e atualizar o Banco de dados de
gerenciamento de configuração devem ser desenvolvidas, sempre que possível,
de modo a reduzir erros e otimizar custos. Ferramentas de descoberta,
inventário e auditar ferramentas, a empresa sistemas e ferramentas de
gerenciamento de rede pode ser conectado ao CMS. Estas ferramentas podem
ser usados inicialmente para preencher um CMDB e, posteriormente, para

comparar o real 'viver"Configuração com as informações e registros
armazenados no CMS.
Bibliotecas seguras e lojas seguras
Uma biblioteca de seguro é uma coleção de software, eletrônica ou documento
IC de tipo conhecido e estado. Acesso a itens de uma biblioteca seguro é
restrito. As bibliotecas são usados para controlar e libertando componentes
durante o serviço ciclo de vida, E.g. em projeto, Construção, testes,
desenvolvimento e operações.
Uma loja de seguro é um local que armazéns de TI ativoss. É identificado dentro
SACM, e.g. lojas de seguros utilizados para a implantação de área de trabalho.
Lojas de seguros desempenham um importante papel na prestação de
segurança e continuidade - manter o acesso confiável aos equipamentos de
conhecido qualidade.
A Biblioteca de Mídia Definitiva
O Biblioteca de Mídia Definitiva (DML) é a biblioteca segura, em que a
autorização definitiva versãos de todos os itens de configuração de mídia são
armazenados e protegidos. Ele armazena cópias mestre de versões que
passaram cheques de garantia de qualidade. Esta biblioteca pode, na realidade,
consiste em uma ou mais bibliotecas de software ou áreas de armazenamento
de arquivos, separadas desenvolvimento,teste ou viver arquivo de
armazenamento de-áreas. Ele contém os originais de todos os softwares
controlada em um organização. O DML deve incluir cópias de software
definitivas comprado (juntamente com os documentos de licença ou de
informação), bem como software desenvolvido no local. Cópias mestre de
documentação controlada por um sistema também são armazenados no DML
em formato electrónico.
O DML também incluirá uma loja física para manter cópias master, por exemplo,
um cofre à prova de fogo. Mídia apenas autorizados deve ser aceito no DML,
estritamente controlado por SACM.
A DML é um alicerce para Gerenciamento de Liberação e Implantação (Ver
secção 4.4 sobre a libertação e desenvolvimento processo).
A configuração exata do DML é definida durante a planejamento actividades. A
definição inclui:
• Médio, a localização física de hardware e software a ser utilizado, se
mantido online - alguns Gerenciamento da Configuração ferramentas de
suporte incorporar documento ou bibliotecas de software, que pode ser
considerada como uma parte de uma lógica DML

• Convenções de nomenclatura para as áreas FileStore e meios físicos
• Ambientes com suporte, por exemplo, teste e viver ambientes
• Segurança arranjos para a apresentação de alterações e emissão de
documentação e software, além de apoio e recuperação procedimentos
• O escopo do LMG, e.g. código fonte de código de objeto, a partir de
controlada construirs e documentação associada
• Períodos de arquivamento e retenção
• Plano de capacidades para o DML e procedimentos para monitoramento
crescimento em tamanho
• Auditar procedimentos
• Procedimentos para assegurar que o DML está protegido contra mudança
errada ou não autorizado (por exemplo, a entrada e critérios de saída
para itens).
A Figura 4.9 mostra a relação entre o DML e CMDB.
Figura 4.9 A relação entre a Biblioteca de Mídia Definitiva e do Banco de Dados do
Gerenciamento da Configuração
Peças definitivas
Uma área deve ser reservada para o armazenamento seguro de peças de
hardware definitivas. Estes são de reposição componentes e conjuntos que são

mantidas no mesmo nível que o comparativo sistemas no teste controlado ou
viver ambiente. Detalhes desses componentes, seus locais e suas respectivas
construirs e conteúdo deve ser amplamente registrado no CMS. Estes podem,
então, ser usado de uma maneira controlada, quando necessário para sistemas
adicionais ou no recuperação de incidentes. Uma vez que o seu uso
(temporário) ter terminado, elas são devolvidas para o armazenamento de peças
sobressalentes ou substituições são obtidos.
Configuração de referência
Uma configuração linha de base é a configuração de um produto, serviço ou
infra-estrutura que tenha sido formalmente revistos e acordados, que depois
serve como base para outras actividades e que só pode ser alterado por meio
formal, mudar procedimentos. Ele captura a estrutura, o conteúdo e os detalhes
de uma configuração e representa um conjunto de item de configuraçãos que
são relacionados uns com os outros.
Estabelecimento de uma linha de base fornece a capacidade de:
• Um marco na desenvolvimento de um serviço, por exemplo, Design de
Serviços linha de base
• Construir um componente de serviço a partir de um conjunto definido de
entradas
• Alterar ou reconstruir uma específica versão posteriormente
• Montagem de todos os componentes relevantes em prontidão para uma
mudança ou liberar
• Fornecer a base para uma configuração auditar e de volta, por exemplo,
depois de uma mudança.
Instantâneo
Ainstantâneo do estado actual de um item de configuração ou de um ambiente,
por exemplo, a partir de uma ferramenta de descoberta. Esta foto foi gravada no
CMS e permanece como um histórico fixo registro. Às vezes isso é chamado de
uma pegada. Um instantâneo não é necessariamente formalmente revisados e
concordou com - é apenas uma documentação de um estado, que pode conter
culpas e CIs não autorizado. Um exemplo é quando um instantâneo é criado
após a instalação, talvez usando uma ferramenta de descoberta, e mais tarde
em relação à linha de base configuração original.
O instantâneo:
• Permite Gerenciamento de Problemas analisar dados referentes a uma
situação relativa à data incidentes realmente ocorreu
• Facilita sistema restaurar para suportar segurança software de
digitalização.

4.3.5.1 Ativos e atividades de gerenciamento de configuração
Atividades de alto nível de Ativos e Gerenciamento da Configuração são
mostradas em um exemplo de um atividade modelo na Figura 4.10.
Figura 4.10 Configuração Típica modelo actividade de Gestão
O modelo de atividade ilustrada na Figura 4.10 é frequentemente usado onde há
muitos partidos ou fornecedors e as atividades precisam ser estabelecidas para
obter as informações de configuração e dados de terceiros.
4.3.5.2 Gestão e planejamento
Não existe um modelo padrão para determinar a melhor abordagem para SACM.
A equipa de gestão e gerenciamento de configuração deve decidir qual o nível
de gestão de configuração é necessário para o serviço selecionado ou projeto
que está a produzir alterações e como esse nível seja atingido. Isso está
documentado em um Plano de Gerenciamento de Configuração. Muitas vezes,
haverá um Plano de Gerenciamento de Configuração para um projeto de
serviço, ou grupos de serviços, por exemplo, serviços de rede. Estes planos
definir as atividades de gestão específicos de configuração dentro do contexto
global da Ativo de Serviço e Gerenciamento de Configuração estratégia.

Um exemplo do conteúdo de um ativo ou de Plano de Gerenciamento de
Configuração é mostrada abaixo.
Exemplo de conteúdo de ativos e Plano de Gerenciamento de
Configuração
Contexto e propósito
Escopo:
• Serviços aplicáveis
• Ambientes infra-estrutura e
• Localizações geográficas.
Exigências:
• Vincular a política,estratégia
• Link para a empresa, Serviço de Gestão de e requisitos contratuais
• Resumir requisitos de responsabilidade, rastreabilidade auditabilidade
• Vincular a requisitos para a Sistema de Gerenciamento da Configuração
(CMS).
Políticas e normas:
• Políticas
• Indústria padrãos, por exemplo, ISO / IEC 20000, ISO / IEC 19770-1
• Padrões internos relevantes para Gerenciamento da Configuração, E.g.
padrões de hardware, padrões de desktop.
Organização para a Gestão de Configuração:
• Mudança e placas de controle de configuração
• Autorização - para estabelecer linha de base, Alterações e liberars.
Ativos e Configuração do Sistema de Gestão e ferramentas
Seleção e aplicação de processos e procedimentos para implementar atividades
de Ativos e Gerenciamento de Configuração, por exemplo:
• Identificação da configuração
• Versão gestão
• Gestão da interface
• Gestão de fornecedores
• Configuração Gestão da Mudança
• Solte e desenvolvimento

• Construir gestão
• Estabelecer e manter a configuração linha de bases
• Manter o CMS
• Revendo o integridade de configurações e da CMS (verificação e
auditoria).
Plano de implementação de referência, por exemplo, migração de dados e de
carregamento, formação e conhecimento plano de transferência.
Relação de gestão e controlo de interface, por exemplo:
• Com financeira Gestão de Ativos
• Com projetos
• Com desenvolvimento e teste
• Com clientes
• Com interface do provedor de serviços (SPI)
• Com operações, incluindo a balcão de atendimento.
Gestão de relacionamento e controlar de fornecedors e sub-empreiteiros.
4.3.5.3 identificação da configuração
Quando planejamento identificação da configuração é importante:
• Definir como as classes e tipos de ativos e item de configuraçãos devem
ser selecionados, agrupados, classificados e definidos por características
adequadas, por exemplo, garantias para um serviço, Para assegurar que
eles são controláveis e rastreáveis ao longo da sua ciclo de vida
• Definir a abordagem à identificação, excepcionalmente nomeação e
rotulagem de todos os bens ou serviços componentes de interesse em
todo o ciclo de vida do serviço e as relações entre eles
• Definir os papéis e responsabilidades do proprietário ou responsável para
o tipo de item de configuração em cada fase do seu ciclo de vida, por
exemplo, o proprietário do serviço para uma pacote de serviços ou liberar
em cada fase do ciclo de vida de serviço.
A identificação da configuração processo atividades são:
• Definir e documentar os critérios para a seleção de itens de configuração
e os componentes que compõem
• Selecione os itens de configuração e os componentes que os compõem
com base em critérios documentados
• Atribuir identificadores exclusivos para itens de configuração
• Especifique o relevante atributos de cada item de configuração
• Especificar quando cada item de configuração é colocado sob
Gerenciamento de Configuração

• Identificar o proprietário responsável por cada item de configuração.
Estruturas de configuração e seleção de itens de configuração
A configuração modelo deve descrever o relação e posição de CIs em cada
estrutura. Deve haver serviço estrutura de configuraçãos que identificam todos
os componentes de um determinado serviço (por exemplo, o retalhista serviço).
Uma parte importante da Gerenciamento da Configuração é decidir o nível em
que controlar deve ser exercida, com alto nível CIs dividido em componentes
que são elas próprias instituições, e assim por diante.
IC devem ser seleccionados através da aplicação de uma abordagem de cima
para baixo, considerando-se se é sensato para quebrar um IC em CIs
componente. A CI pode existir como parte de qualquer número de itens de
configuração diferente ou grupos CI, ao mesmo tempo. Por exemplo, um produto
de base de dados pode ser usado por muitos aplicaçãos. Ligações de uso para
componentes reutilizáveis e comum do serviço deve ser definido - por exemplo,
uma estrutura de configuração para um serviço de varejo vai usar CIs infra-
estrutura como servidors, rede e software CIs. A capacidade de ter múltiplas
visões através de estruturas diferentes de configuração melhora a
acessibilidade, impacto análise e relatórios.
Gerenciamento de Configuração de produtos de trabalho e componentes de
serviços do ciclo de vida do serviço pode ser realizada em vários níveis de
granularidade. Os itens colocados sob gerenciamento de configuração
normalmente incluem pacotes de serviços, pacote de serviçoss, componentes
de serviço, liberar embalagens e produtos que são entregues ao cliente, os
produtos de trabalho internos, serviços adquiridos, produtos, ferramentas,
sistemas e outros itens que são usados na criação e na descrição das
configurações requeridas para conceber, transição e operar o serviço.

Figura 4.11 (a) Repartição Exemplo de configuração para um serviço de
computação de usuário final

Figura 4.11 (b) quebra Exemplo de configuração para um sistema gerenciado
Virtual
Figura 4.11 (a) e (b) apresenta um exemplo de uma representação esquemática
de como uma estrutura de CI para um fim-usuário serviço de computação e um
sistema gerenciado Virtual pode ser quebrado.
Escolhendo o nível CI direito é uma questão de encontrar um equilíbrio entre as
informações disponibilidade, O nível adequado de controlar, E a recursos e
esforço necessários para apoiá-lo. Informação a um nível baixo não CI podem
ser valiosos - por exemplo, um teclado, embora seja normalmente trocados de
forma independente, o organização vê-lo como um produto de consumo,
portanto, não armazenam os dados sobre ele. Informações CI só tem valor se
facilitar a gestão da mudança, o controle de incidentes e problemas, ou o
controlo de ativoss que podem ser movidos de forma independente, copiados ou
alterados.
Fatores que influenciam o nível de gravação de itens de configuração
Os fatores que afetam a escolha do nível mais baixo IC não são apenas
financeiros. Como mencionado acima a maioria das organizações não
armazenam dados em teclados, porque consideram-los consumíveis, para ser

jogado fora quando não está trabalhando, como se fosse uma caneta quebrada.
No entanto, algumas organizações acham que vale a pena reter dados sobre
teclados - por exemplo, na Organização das Nações Unidas, que suporta várias
línguas diferentes dentro de seu prédio de escritórios, a gravação do teclado
linguagem específica utilizada é um fator importante no incidente rápida
resolução quando teclados falhar, ou seja, saber que tipo de substituição do
teclado para enviar a qualquer dado usuário.
A organização deve planejar para rever o nível CI regularmente - para confirmar
(ou não) que a informação a um nível baixo ainda é valioso e útil, e que o
tratamento de alterações e problemas e gestão de ativos não são deficientes
porque o CMDB não descer para um nível suficientemente baixo.
Cada activo e CI necessita ser singularmente identificado, se é gerado no
interior ou no exterior da organização. A identificação deve também diferenciar
entre sucessivos versãos e deve permitir que os itens sob controle a ser
inequivocamente rastreáveis a sua especificaçãos ou equivalente, descrições
documentadas. Descrições de configuração e de dados devem conformar-se,
sempre que possível, produto, serviço ou tecnologia padrãos. Os dados de
configuração deve permitir a rastreabilidade para frente e para trás para outros
estados de configuração baseline, quando necessário.
Nomeando itens de configuração
Convenções de nomenclatura devem ser estabelecidos e aplicados para a
identificação de IC, a configuração documentos e modificações, assim como a
linha de bases, construirs, liberars e montagens.
CIs indivíduo deve ser exclusivamente identificável por meio do identificador e
versão. A versão actualizada identifica um exemplo do que pode ser
considerado como o CI mesmo. Mais do que uma versão de um CI podem
coexistir em qualquer dado momento. As convenções de nomenclatura deve ser
original e ter em conta a empresa existente ou fornecedor nomeando /
numeração estruturas. As convenções de nomenclatura ou informações gestão
da informação deveria incluir a administração de:
• Hierárquica relaçãos entre CIs dentro de um estrutura de configuração
• Relações hierárquicas ou subordinado em cada CI
• As relações entre itens de configuração e seus documentos associados
• As relações entre itens de configuração e mudanças
• As relações entre itens de configuração, incidentes, os problemas e erro
conhecidos.
Gerenciamento de Configuração deve providenciar para uma convenção de
nomeação a ser estabelecido para todos os documentos, por exemplo, RFCs.
Modelos de documentos são um bom método para padronizar a documentação

de configuração. Sem modelos muitas vezes há documentos demasiadas
gerados com conteúdo sobreposição que pode fazer alterações execução
extremamente difícil.
Cada tipo de modelo e formulário deve ser unicamente identificável com um
número de versão. Um método típico de identificação é <Form <tipo _nnnn onde
nnnn é um número atribuído seqüencialmente para cada nova instância do
formulário.
Quando a convenção de nomenclatura está sendo planejado, é muito importante
que é levado suficientemente em conta o crescimento futuro possível.
Identificadores devem ser relativamente curta, mas significativa, e deve seguir
as convenções existentes sempre que possível. Para o hardware, se as
convenções de nomenclatura CI não se baseiam em fornecedors 'nomes de
dispositivos e modelos, um mecanismo deve ser criado para se relacionar
Gerenciamento da Configuração e identificadores dos fornecedores para o outro,
por exemplo, para a comodidade do pessoal das aquisições e engenheiros de
hardware. Padrão de terminologia e abreviaturas devem ser utilizados em todo o
organização , tanto quanto possível (por exemplo, em vez de NYC NY ou, por
vezes, N York). Falha a fazê-lo irá resultar em uma incapacidade para
corresponder comum incidentes, problemas etc Atributos que podem mudar
nunca deve ser usada como uma peça de nomenclatura CI.
Rotulagem itens de configuração
Todos os itens de configuração de dispositivo físico deve ser marcado com o
identificador de configuração, de modo que eles podem ser facilmente
identificados. Planos devem ser feitos para rotular IC e para manter a exactidão
das suas etiquetas.
Itens precisam ser distinguidos pela identificação única, durável, por exemplo,
rótulos ou as indicações que seguem relevante padrãos quando apropriado.
Físicas etiquetas não removíveis de ativos (etiquetas) deve ser anexada a todos
os itens de configuração de hardware; cabos / linhas devem ser claramente
identificados em cada extremidade e em quaisquer pontos de inspeção. É
aconselhável utilizar um formato padrão e cor para todas as tais rótulos, porque
este faz com que seja mais fácil para usuários para identificar e citá-los, por
exemplo, quando a telefonar balcão de atendimento para relatar um culpa.
Código de barras legíveis rótulos melhorar a eficiência de física auditars. Uma
norma política em hardware rotulagem é igualmente vantajoso no balcão de
atendimento, E.g. se todo o hardware está marcado no canto esquerdo inferior
do lado esquerdo, é muito mais rápido e mais fácil de explicar para o usuário,
onde encontrarão as informações necessárias.
Atributos para itens de configuração

Atributos descrever as características de um CI que são valiosas para gravar e
que irá suportar SACM e os processos de ITSM que ele suporta.
O SACM plano referências a informação de configuração e de dados arquitetura.
Isso inclui os atributos a serem registrados para cada tipo de ativos ou CI.
Atributos típicos incluem:
• Identificador único
• Tipo CI
• Nome / Descrição
• Versão (Por exemplo, arquivo, construir,linha de base,liberar)
• Localização
• Fornecimento data
• Detalhes de licença, por exemplo, data de validade
• Proprietário / custodiante
• Estado
• Fornecedor/ Fonte
• Relacionado documento mestres
• Relacionadas mestres de software
• Dados históricos, por exemplo, auditar trilha
• Relação tipo
• Aplicável SLA.
Estes atributos definem específicas características funcionais e físicas de cada
tipo de ativo e CI, por exemplo, tamanho ou capacidade, Juntamente com toda a
documentação ou especificaçãos.
Definindo documentação de configuração
As características de um CI são muitas vezes contidas nos documentos. Por
exemplo, a definição de serviço, exigênciasespecificação e acordo de nível de
serviço para um serviço de descrever as características de um CI de serviço.
Muitas organizações especificar documentos obrigatórios e opcionais que
descrevem um CI e utilizar modelos de documentos para assegurar informações
consistentes está inscrita. Tabela 4.7 é uma RACI (Responsável, responsável,
Consultado, Informado) gráfico, que ilustra os tipos de documentação de serviço
ativos ou item de configuraçãos que são da responsabilidade do serviço
diferente ciclo de vida etapas e documentação típica.
Coleta de dados de atributos CI pode facilitar a utilização / reutilização /
referência aos documentos existentes, dados, arquivos, registros, planilhas etc
Isto irá ajudar os usuários a execução do presente para determinar um bom
método para coleta de dados.
Serviço
fase do
Exemplos de ativos
de serviços de ciclo
Estratégia
de
Design
de
Transição
de
Operação
de
Melhoria de
Serviço

ciclo de
vida
de vida e CIs
impactado
Serviço Serviços Serviço Serviço Continuada
Estratégia
de Serviço
Carteiras - contrato
de serviço, Cliente
Estratégia de
requisitos de
serviço
Serviço de ciclo de
vida modelo
A C C R C
Design de
Serviços
Pacote de serviços
(Incluindo SLA)
Pacote Service
Design, E.g.
modelo de serviço,
contrato,
fornecedor'S
Serviço Plano de
Gestão,processo
interface de
definição, o
envolvimento do
cliente plano
Solte política
Solte definição do
pacote
Eu A C R C
Transição
de Serviço
Modelo de
Transição de
Serviço
Teste plano
Controlado
ambientes
ConstruirPlano /
instalação
Construir
especificação
Solte plano
Desenvolvimento
plano
CMS
SKMS
Pacote de
lançamento
Solte linha de base
Documentação de
liberação
Avaliação
denunciar
Relatório de ensaio
Eu C A R C
Operações
de Serviço
Operação de
ServiçoO modelo
de
Eu C C A / R R

Modelo de suporte
de serviços
Balcão de
atendimento
Usuário ativos
Documentação do
usuário
Documentação de
Operações
A documentação
de suporte
Melhoria de
Serviço
Continuada
CSI modelo
Plano de melhoria
do serviço
Serviço de relatório
processo
A / C A / C A / C R A
R = Responsável, A = Responsável, C = Consultado, I = Informado
Tabela de documentação de configuração 4.7 para os ativos e responsabilidades
através do ciclo de vida do serviço
Relacionamentos
Relaçãos descrever a forma como o item de configuraçãos trabalhar juntos para
realizar os serviços. Estas relações são realizadas no CMS - esta é a grande
diferença entre o que é gravado em um CMS eo que é realizada em um ativos
registo.
As relações entre CIs são mantidos de modo a proporcionar dependência
informação. Por exemplo:
• A CI é uma parte de um outro CI, por exemplo, um módulo de software é
parte de um programa, uma servidor é parte de uma infra-estrutura local -
esta é uma relação 'pai e filho'.
• A CI está ligado a outro CI, por exemplo, um computador está conectado
a uma LAN.
• A CI usa outro CI, por exemplo, um programa usa um módulo de outro
programa, uma serviço de negócio usa um servidor de infra-estrutura.
• A CI está instalado em outro, por exemplo, MS Projeto está instalado em
um PC desktop.
Apesar de uma "criança" CI deve ser "propriedade" pela CI um 'pai', ele pode ser
"usado por" qualquer número de CEI. Se um desktop padrão construir é
fornecido e instalado em todos os PCs dentro de uma divisão ou local, em
seguida, que a construção, incluindo todo o software CIs incluído, será um CI
que é ligada por uma relação com os computadores. O software incluído será
"parte da 'construir. Isto pode reduzir consideravelmente o número de relações

que são necessários, em comparação com quando as relações de CIs
individuais de software são utilizados.
Relacionamentos também são o mecanismo para RFCs associando, registro de
incidentes, registro de problemas, erros conhecidos e registro de liberaçãos com
os serviços e Infra-estrutura de TI CIs a que se referem. Todas essas relações
devem ser incluídos no CMS. RFCs e mudança e registros de lançamento irão
identificar os CIs afetados.
Alguns destes relacionamentos foram mostrados na Figura 4.11. Por exemplo,
EUC é o pai da CI EUC1 para EUC5 e EUC1 por sua vez é o pai de três CIs,
EUC1_01 para EUC1_03, mostrado como o próximo nível na hierarquia. EUC1
usa o DML e Interna serviço Application (IA).
Relações podem ser de um-para-um, um-para-muitos e muitos-para-um.
Carteiras colocação ao abrigo do controlar do CMS é um bom exemplo. A
combinação de Portifólios de Serviços e carteira de clientess gera o carteira de
contratos. Em outras palavras, cada item do portfólio de contratos é mapeado
para pelo menos um item na Portfólio de Serviços e pelo menos um ponto na
carteira de clientes.
Tipos de item de configuração
Os componentes devem ser classificados em ativo ou Tipo CIs, porque isso
ajuda a identificar e documentar o que está em uso, o estado dos itens e onde
eles estão localizados. Tipos típicos da CI incluem serviço, hardware, software,
documentação e pessoal.
Identificação de bibliotecas de mídia
Bibliotecas físicos e eletrônicos da mídia devem ser identificados de forma
exclusiva e registrada no CMS com a seguinte informação:
• Conteúdo local, e médias de cada biblioteca
• Condições para a emissão de um item, incluindo o estado mínimo
compatível com o conteúdo da biblioteca
• Como proteger as bibliotecas do dano malicioso e acidental e
deterioração, juntamente com efetiva recuperação procedimentos
• Condições e controles de acesso para grupos ou tipos de pessoa
registrar, ler, atualizar, copiar, remover e apagar CIs
• Escopo de aplicação, por exemplo, aplicável a partir de ambiente 'sistema
teste 'a'operação'.
Identificação de linhas de base de configuração

Configuração linha de bases devem ser estabelecidos pelo formais acordo em
pontos específicos no tempo e utilizados como pontos de partida para o formal
controlar de uma configuração. Linhas de base de configuração mais mudanças
aprovadas para essas linhas de base, juntos, constituem a configuração
atualmente aprovado. Exemplos específicos de linhas de base, que podem ser
identificadas incluem:
• Um especial 'padrão' CI necessários ao comprar muitos itens do mesmo
tipo (computador de mesa, por exemplo) ao longo de um período
prolongado, se alguns são de incluir componentes adicionais (por
exemplo, um gravador de DVD), esta poderia corresponder a «linha de
base mais ', se tudo computadores desktop futuros estão a ter
características em seguida, uma nova linha de base é criado
• Um aplicação liberar e sua documentação associada.
Várias linhas de base correspondentes às diferentes fases da vida de um "item
de linha de base" pode existir em qualquer momento - por exemplo, a linha de
base para uma libertação aplicação actualmente viver, Aquele que foi o último
ao vivo e já foi arquivada, o que vai ser instalado próximo (sujeito a alterações
em Gerenciamento da Configuração controlo), e um ou mais sob teste. Além
disso, se, por exemplo, um novo software está sendo introduzido gradualmente
regionalmente, mais do que um versão de uma linha de base poderia ser "ao
vivo", ao mesmo tempo. Por isso, é melhor para se referir a cada um por um
número de versão única, em vez de 'ao vivo', 'next' ou 'velho'.
Ao consolidar os estados de configuração em evolução do item de configuraçãos
para formar linhas de base documentados nos pontos designados ou tempos do
Gerenciamento da Configuração vai ser mais eficaz e eficiente. Cada linha de
base é um conjunto mutuamente consistentes de CIs que podem ser declarados
em marcos importantes. Um exemplo de uma linha de base é uma descrição de
um aprovado serviço que inclui versões internamente consistentes de
exigências, matrizes de rastreabilidade de requisitos, projeto, Serviço específico
componentes e usuário documentação.
Cada linha de base constitui um quadro de referência para o serviço ciclo de
vida como um todo. Linhas de base fornecem a base para avaliar o progresso e
realização de trabalhos, ainda, que é internamente auto-consistente e estável.
Por exemplo, a Portfólio de Serviços e a Business Case para um serviço deve
apresentar uma definição coerente e clara do que o pacote de serviços tem a
intenção de entregar. Isto pode constituir a 'escopo base "para o serviço (s) e
dar partes internas e externas de uma base clara para posterior análise e
desenvolvimento. Um exemplo dos pontos da linha de base é mostrada na
Figura 4.12.
Linhas de base são adicionados à CMS como eles são desenvolvidos.
Alterações linhas de base e os liberar de produtos de trabalho construídos a

partir do CMS são sistematicamente controlados e monitorados por meio do
controle de configuração, Gestão da Mudança e auditoria de configuração
funçãos de SACM. Na identificação de configuração, definir e registro a
justificativa para cada linha de base e autorizações associados necessários para
aprovar os dados básicos de configuração.
Figura 4.12 Exemplo de níveis de serviço de configuração do ciclo de vida e os
pontos da linha de base, representadas pelos triângulos numerados
Como um serviço progride através do serviço ciclo de vida, Cada linha de base
fornece níveis progressivamente maiores de detalhes sobre as saídas eventuais
para ser entregue. Além disso, essa hierarquia de linhas de base permite que os
resultados finais para ser rastreada até o original exigências.
Ele precisa ser mantido em mente que as linhas de base anteriores não pode
ser totalmente atualizado com as mudanças que foram feitas mais tarde, por
exemplo, 'correções de curso"A documentação de requisitos pode ser refletido
na liberar documentação.
Identificação da unidade de liberação

'Unidade de liberação"Descreve a porção do serviço ou infra-estrutura que é
normalmente lançado em conjunto em conformidade com um
organização"Libertação s política. A unidade pode variar, dependendo do tipo (s)
ou item (s) de software e hardware.
A Figura 4.13 apresenta um exemplo simplificado mostrando um Infra-estrutura
de TI composta de sistemas, as quais são, por sua vez constituído por suites,
programas que compreendem, que são constituídos por módulos.
Figura 4.13 exemplo simplificado de uma infra-estrutura de TI
Informações de lançamento é gravado dentro do CMS, apoiando a liberação e
desenvolvimento processo. Lançamentos são identificados exclusivamente de
acordo com um esquema definido na política de liberação. O identificação de
liberação inclui uma referência para o CI que representa e um versão número
que, muitas vezes, ter duas ou três peças. Exemplo nomes de lançamento são:
• Grandes lançamentos: Payroll_System v.1, etc, v.2 v.3
• As versões menores: Payroll_System v.1.1, v.1.2, v.1.3 etc
• Emergência de consertos: Payroll_System v.1.1.1, v.1.1.2, etc v.1.1.3
4.3.5.4 Configuração de controle
Configuração controlar garante que não há mecanismos de controlo adequados
sobre CIs, mantendo um registro das alterações a itens de configuração,
versões, localização e guarda / propriedade. Sem o controle do físico ou
eletrônico ativoss e componentes, os dados de configuração e informação
haverá uma incompatibilidade com o mundo físico.

Não CI deve ser acrescentado, modificado, substituído ou removido sem uma
documentação apropriada controlador ou procedimento sendo seguido. Políticas
e procedimentos precisam estar no lugar que englobam:
• Controle de licença, para garantir que o número correto de pessoas estão
usando licenças e que não há uso sem licença e sem desperdício
• Versão controle de serviço ativo, Versões de software e hardware,
imagens /construirs e liberars
• O controle de acesso, por exemplo, às instalações, áreas de
armazenagem e CMS
• Construir controle, incluindo o uso de construção especificação da CMS
para realizar uma construção
• Migração de promoção, de dados eletrônicos e informações
• Tomando uma configuração linha de base de bens ou CIS antes de
realizar um lançamento (em sistema,aceitação teste e produção) de um
modo que pode ser utilizado para a verificação de posterior contra real
desenvolvimento
• Desenvolvimento controlar incluindo a distribuição
• Instalação
• Manter a integridade da DML.
Muitas vezes, há muitos procedimentos que podem mudar um CI. Estes devem
ser revistos e alinhados com o Tipo CIs sempre que possível a normalização
impede erros. Durante o planejamento fase é importante projeto um controle de
configuração eficaz modelo e implementar isso de uma maneira que a equipe
possa facilmente localizar e usar os produtos de formação e procedimentos
associados.
Se muitos Gerenciamento da Configuração ferramentas são usadas há muitas
vezes um controlo plano para cada uma das ferramentas que está alinhado com
o modelo geral de configuração de controle.
Controle deve ser passado a partir da projeto ou fornecedor ao provedor de
serviços no horário agendado com precisão documentação de configuração,
informações e registros. Uma lista de verificação abrangente, cobrindo as
informações do provedor de serviço exigências, a informação de fornecedores e
informações organizacionais necessários podem ser feitos e assinados.
Disposições para a realização de SACM precisam ser estabelecidos no
fornecedor acordos. Métodos para garantir que os dados de configuração é
completa e consistente deve ser estabelecida e mantida. Tal método pode incluir
a linha de base em transição, Definida auditar políticas e intervalos de auditoria.
É importante que a necessidade desta informação e do método de controlo é
estabelecida tão cedo quanto possível durante a desenvolvimento ciclo de vida e
incorporada como uma entrega do serviço novo ou alterado.

4.3.5.5 Estado de contabilidade e relatórios
Cada activo ou CI terá um ou mais estados discretos através do qual se possa
desenvolver. O significado de cada estado devem ser definidos em termos do
que pode ser feito uso do bem ou CI nesse estado. Normalmente haverá uma
gama de estados relevantes para o ativo individual ou IC.
Um exemplo simples de um ciclo de vida é a seguinte:
• Desenvolvimento ou projecto - que denota que a CI está em
desenvolvimento e que nenhuma dependência particular deve ser
colocado sobre ela
• Aprovado - o que significa que o CI pode ser utilizada como uma base
para futuro trabalho
• Retirado - o que significa retirada de uso, ou porque o IC não é mais apto
para o efeito ou porque não há mais uso para ele.
O movimento CIs caminho de um estado para outro deve ser definido, por
exemplo, uma aplicação liberar pode ser registrado, aceitou, instalados ou
retirados. Um exemplo de um ciclo de vida de uma embalagem de libertação
aplicação é mostrado na Figura 4.14. Isto irá incluir a definição do tipo de rever e
aprovação necessária eo nível de autoridade necessária para dar essa
aprovação. Na Figura 4.12 o papel que pode promover a CI a partir de Aceite
para instalado é "gerenciamento de liberação'. Em cada ciclo de vida estado
mudar o CMS deve ser atualizado com o selo razão, data, hora e pessoa que fez
a mudança de status. As atividades de planejamento também deve estabelecer
qualquer atributos que devem ser atualizados em cada estado.
Figura 4.14 Exemplo de ciclo de vida de ativos e item de configuração
Configuração Relato da situação e relatório está preocupado com a garantia de
que todos os dados de configuração e documentação é registrado como cada
ativos ou CI progride através de seu ciclo de vida. Ele fornece o estado da
configuração de um serviço e do seu ambiente como a configuração evolui
através do serviço ciclo de vida.
Relatórios de status fornece os dados atuais e históricos envolvidos com cada CI
que por sua vez permite o rastreamento de alterações a itens de configuração e
sua registros, ou seja, rastrear o status como um CI mudanças de um estado
para outro, por exemplo, 'desenvolvimento','teste','viver'Ou' retirado '.

O organização deve realizar configuração de contabilidade e relatórios de status
atividades durante todo o ciclo de vida do serviço, a fim de apoiar e permitir um
eficiente Gerenciamento da Configuração processo. As atividades típicas
incluem:
• Manter registro de configuraçãos através do ciclo de vida do serviço e
arquivando-os de acordo com a legislação pertinente, acordos ou melhor
da indústria prática,padrãos, por exemplo, ISO 9001, Qualidade Gestão
da informação
• Gerenciando a gravação, recuperação e consolidação do status de
configuração atual eo status de todas as configurações anteriores para
confirmar a veracidade da informação, pontualidade, integridade e
segurança
• Fazendo o status dos itens sob gerenciamento de configuração disponível
em todo o ciclo de vida, por exemplo, para garantir o acesso adequado,
mudar,construir e controles de liberação são seguidos, por exemplo,
construir especificaçãos
• Gravar alterações para instituições de crédito de recebimento do descarte
• Assegurar que as mudanças de configuração linha de bases estão
devidamente documentados. Isto pode ser conseguido mediante a
consolidação dos estados de configuração de evolução item de
configuraçãos para formar linhas de base documentados por vezes
designados ou em circunstâncias definidas.
Registros
Durante a configuração e identificação controlar atividades, registros de status
de configuração será criado. Esses registros permitem a visibilidade e
rastreabilidade e para a gestão eficiente da configuração evoluindo. Eles
geralmente incluem detalhes sobre:
• Serviço de informações de configuração (como o número de identificação,
título, datas de vigência, versão, Status, mudar a história e sua inclusão
em qualquer linha de base)
• A configuração do serviço ou produto (como projeto ou construir estado)
• A qualidade de liberar de novas informações de configuração
• Mudanças implementadas e em andamento
• Capturar os resultados a partir de garantia de qualidade testes para
atualizar o registro de configuraçãos.
As informações de configuração evoluindo serviço deve ser registada de uma
forma que identifica as referências cruzadas e interrelaçãos necessárias para
fornecer os relatórios necessários.
Ativos de serviço e relatórios de configuração

Relatórios de vários tipos serão necessários para Gerenciamento da
Configuração finalidades. Estes relatórios poderão cobrir indivíduo item de
configuraçãos, um serviço completo ou o pleno Portfólio de Serviços. Relatórios
típicos incluem:
• Uma lista de informações de configuração do produto incluído em uma
configuração específica linha de base
• A lista de itens de configuração e baselines sua configuração
• Detalhes sobre o estado actual revisão e mudar a história
• Relatórios sobre as mudanças, renúncias e desvios
• Detalhes sobre o estado dos produtos entregues e mantidos sobre parte e
números de rastreabilidade
• Estado de revisão
• Relatório sobre o uso não autorizado de hardware e software
• CIs não autorizado detectado
• Variações da CMS para física auditar relatórios.
Relatórios de status de ativos para uma unidade de negócios ou explorações de
licenças de software são muitas vezes obrigados pela gestão financeira para
orçamentação, Contabilidade e carregamento.
4.3.5.6 Verificação e auditoria
Estas actividades incluem uma série de revers ou auditars a:
• Verifique se há conformidade entre as linhas de base documentadas (por
exemplo, acordos, interface controlar documentos) eo atual negócio
ambiente a que se referem
• Verificar a existência física de CIs no organização ou nas lojas DML e
peças de reposição, o funcional e operacional características de IC e para
verificar se o registros no CMS coincidir com a infra-estrutura física
• Verifique que a liberação e documentação de configuração está presente
antes de fazer um lançamento.
Antes de um grande lançamento ou alteração, uma auditoria de uma
configuração específica pode ser necessária para garantir que o cliente
ambiente corresponde ao CMS. Antes aceitação na viver ambiente, Novos
lançamentos, construirs, equipamento e padrãos devem ser verificados contra a
contratada ou especificados exigências. Deve haver um teste certificado que
comprova que o funcional exigências de um IC novo ou atualizado foram
verificados, ou algum outro relevante documento (Por exemplo, RFC).
Planos deve ser feito para auditorias de configuração regular para verificar que o
CMDB e informações de configuração relacionados é consistente com o estado
físico de todos os itens de configuração, e vice-versa. Auditorias de configuração
física deve ser realizada para verificar que o "as-built" configuração de um IC

está de acordo com sua configuração "como planejado" e seus documentos
associados. Instalações de interrogatório são obrigados a verificar que o CMDB
eo estado físico de CIs são consistentes.
Estas auditorias devem verificar se correta e autorizada versãos de CIs existem,
e que o CIS somente as houver, e estão em uso no ambiente operacional.
Desde o início, todas as ferramentas ad-hoc, teste equipamentos, computadores
pessoais e outros itens não registrados deverá ser removido ou registrados
através formais Gerenciamento da Configuração. Registro ou remoção será
através do Gestão da Mudança processo e tem de evitar que a autorização de
não-aceitável IC ou a remoção de itens de configuração que podem ser de
suporte processo de negócioes. Itens não registrados e não autorizadas que são
descobertos durante a configuração auditars deve ser investigada, e ações
corretivas tomadas para resolver possíveis problemas com procedimentos e o
comportamento do pessoal. Todas as exceções são registrados e relatados.
Verificação da configuração auditorias, além de que a mudança e registro de
liberaçãos ter sido devidamente autorizada pelo Gerenciamento de Mudanças e
que as mudanças implementadas são como autorizado. Auditorias de
configuração deve ser considerada nos seguintes horários:
• Pouco depois de alterações no CMS
• Antes e depois de alterar a De serviços de TIs ou infra-estrutura
• Antes de um liberar ou instalação para assegurar que o ambiente é como
esperado
• Seguido recuperação de desastres e depois de um 'voltar ao normal'(Este
de auditoria deve ser incluída nos planos de contingência)
• A intervalos planejados
• A intervalos aleatórios
• Em resposta à detecção de qualquer CIs não autorizado.
Ferramentas de auditoria automatizados permitem controlos regulares, para ser
feita em intervalos regulares, por exemplo semanalmente. Por exemplo, as
ferramentas de auditoria de mesa comparar o construir de área de trabalho de
um indivíduo para a construção mestre que foi instalado. Se exceções são
encontradas, algumas organizações voltar a construir ao seu estado original.
Um rolamento programa de auditorias de configuração podem ajudar a usar
recursos mais eficaz. O balcão de atendimento e grupo de apoios irá verificar
que o CIS trouxe à sua atenção, por exemplo, o software que está usando um
chamador, são como registrado no CMS. Quaisquer desvios são relatados para
Gerenciamento de Configuração para investigação.
Se há uma alta incidência de CIs não autorizado detectado, a freqüência das
auditorias de configuração deve ser aumentada, certamente para as partes dos
serviços ou Infra-estrutura de TI afectados por esta problema. Note-se que as

instalações não autorizadas estão desanimados quando a equipe de
Gerenciamento de Configuração é visto estar no controle e realizar auditorias
regulares e freqüentes. Se uma epidemia de CIs não autorizado é detectado,
auditorias de configuração seletiva ou geral deve ser iniciada para determinar a
escala do problema, para colocar as coisas direito, e para desencorajar a
proliferação de CIs não autorizado. Publicidade vai ajudar a reduzir as
ocorrências posteriores. Design de Serviços e Operação de Serviços equipe
precisa ser notificado e envolvido na investigação de CIs não autorizado.
Atualizações para ativos e informações de configuração são acionados por
mudar pedidos, ordens de compra, aquisições e serviço pedidos.
4.3.6.1 Processo de relacionamentos
Por sua própria natureza - como o único repositório virtual de dados de
configuração e informações para IT Service Management - Suporta SACM e
interfaces com todos os outros processo e atividade em algum grau. Algumas
das interfaces mais notáveis são os seguintes:
• Gestão da Mudança - identificando o impacto das mudanças propostas
• Gestão financeira - Captura de informações financeiras essenciais, tais
como custar,depreciação métodos proprietário, e usuário (Por
orçamentação e custo de alocação), manutenção e reparar custos
• ITSCM - a consciência dos ativos da serviço de negócios depende,
controlar de peças-chave e software
• Incidente/problema/erro - Fornecer e manter informações de diagnóstico
chave, manutenção e fornecimento de dados para a balcão de
atendimento
• Gerenciamento de disponibilidade em detecção de pontos de falha.
O relação com a mudança e liberar e desenvolvimento é sinérgica, com estes
processos beneficiar grandemente de uma coordenada única planejamento
abordagem. Configuração controlar é sinônimo de controle de mudanças -
compreensão e atualizações de captura para a infra-estrutura e serviços.
4.3.7 Gestão da informação
Faça backup cópias do CMS deve ser tomado regularmente e armazenados de
forma segura. É aconselhável que um exemplar para ser armazenado em um
local remoto para utilização na evento de um desastre. A freqüência de cópia e a
retenção política vai depender do tamanho e da volatilidade do Infra-estrutura de
TI e do. CMS Certas ferramentas podem permitir a cópia selectiva de IC
registros que são novos ou foram alterados.

O CMS contém informações sobre cópias de segurança das IC. Ele também irá
conter registros históricos das IC e IC versãos que são arquivados e,
possivelmente, também de CIs excluído ou versões de CI. A quantidade de
informação histórica para ser mantido depende de sua utilidade para a
organização. A política de retenção de registros históricos CI devem ser
regularmente revistos e, se necessário, alterado. Se o custo para a organização
de reter informações de IC é maior do que o valor atual ou potencial, não
guarde-o, tomando nota de regulamentação relevante e estatutárias exigências
em relação à retenção de registos.
Tipicamente, a CMS deve conter apenas os registos para os artigos que são
fisicamente disponível ou pode ser facilmente criado usando procedimentos
conhecidos, e sob o controlo de, Gerenciamento da Configuração. Quando
Gerenciamento de Configuração vem operando por um período de tempo, a
limpeza regular deve ser realizado para garantir que os registros redundantes CI
são sistematicamente arquivadas.
Tal como acontece com todos os processos a atuação de SACM deve ser
monitorado, relatou e as medidas para melhorá-lo.
SACM é o processo de apoio central facilitando a troca de informações com
outros processos e, como tal, tem poucos cliente enfrentando medidas. No
entanto, como um motor de base de outros processos no ciclo de vida, SACM
deve ser medido por sua contribuição para estas partes do ciclo de vida e os
KPIs globais que afetam a cliente diretamente.
A fim de otimizar o custo e desempenho do serviço ativos e configurações as
seguintes medidas são aplicáveis:
• O percentual de melhoria na programação de manutenção ao longo da
vida de um ativo (mas não muito, não muito tarde)
• Grau de alinhamento entre a manutenção prestados e apoio às empresas
• Activos identificados como a causa do serviço falhas
• Maior velocidade de gerenciamento de incidentes para identificar IC com
defeito e restaurar serviço
• Impacto de incidentes e erroestá afetando em particular Tipo CIs, por
exemplo, do particular fornecedors ou desenvolvimento grupos, para
utilização na melhoria da De serviços de TIs
• Percentual de reutilização e redistribuição de sub-utilizados recursos e
ativos
• Grau de alinhamento dos prémios de seguro com as necessidades do
negócio
• Proporção de licenças usadas contra pagos pelas licenças (deve ser
perto de 100%)

• Média custar por usuário para licenças (ou seja mais eficaz carregamento
opções alcançados)
• Precisão alcançada em orçamentos e encargos para os ativos utilizados
por cada cliente ou unidade de negócios
• Percentagem de redução negócio impacto de interrupções e incidentes
causados por ativos pobres e Gerenciamento da Configuração
• Melhorado auditar observância.
Outras medidas incluem:
• Aumento qualidade e precisão dos ativos e informações de configuração
• Menos erros causada por pessoas que trabalham com out-of-date
informações
• Shorter auditorias como qualidade de ativos e informações de
configuração é facilmente acessível
• Redução da utilização de hardware e software não autorizada, não-
padrão e variante construirs que a complexidade aumento, os custos de
suporte e risco ao serviço de negócios
• Redução do tempo médio e custo de diagnóstico e resolução de
incidentes e problemas (por tipo)
• Melhoria no tempo para identificar pobre desempenho e de baixa
qualidade ativoss
• Ocasiões em que a "configuração" não é tão autorizados
• Mudanças que não foram concluídas com sucesso ou erros causados por
causa do impacto pobres avaliação, Dados incorretos no CMS, ou pobre
versão controlar
• Exceções relatados durante auditorias de configuração
• Valor da TI componentes detectados em uso
• Redução dos riscos devido à identificação precoce de alteração não
autorizada.
4.3.9 Desafios, fatores críticos de sucesso e riscos
Desafios para SACM incluem:
• Persuadir suporte técnico funcionários para adotar uma verificação in / out
política - Isso pode ser percebido como um obstáculo para um serviço de
apoio rápido e ágil, se os aspectos positivos de tal sistema não são
transmitidas de forma adequada, então o pessoal pode estar inclinado a
tentar contorná-la, mesmo assim, a resistência ainda pode ocorrer,
colocando isso como uma objetivo dentro de sua avaliação anual é uma
forma de ajudar a impor a política
• Atrair e justificar o financiamento para SACM, uma vez que é tipicamente
fora da vista para as unidades de clientes habilitados com financiamento
controlar, Na prática, é tipicamente financiada como um elemento

"invisível" de Gestão da Mudança ITSM e outros processo com
visibilidade mais negócios
• Uma atitude de "apenas a recolha de dados, porque é possível para fazer
', o que leva a uma sobrecarga SACM dados que é impossível, ou pelo
menos de forma desproporcionada caro, para manter
• Falta de compromisso e apoio de gestão que não entendem a chave
papel ele deve jogar apoiando outros processos.
Fator crítico de sucessos incluem:
• Centrado na criação de justificação válida para a recolha e manutenção
de dados no nível acordado de detalhe
• Demonstrando uma abordagem de cima para baixo - com foco na
identificação de itens de configuração de serviço e, posteriormente, da
CEI, o que sustentam os serviços, permitindo assim uma demonstração
rápida e clara de potenciais pontos de falha para um determinado serviço
• Definir um nível justificado de precisão, ou seja, a correlação entre a
lógica modelo dentro SACM eo "mundo real"
• Fazendo uso de tecnologia que permite automatizar as práticas do CMS e
reforçar as políticas de SACM.
Riscos para SACM de sucesso incluem:
• A tentação de considerá-lo tecnicamente focado, ao invés de serviço e de
negócios focada, já que a competência técnica é essencial para a sua
entrega bem sucedida
• Degradação da precisão da informação de configuração ao longo do
tempo, que pode causar erros e ser difícil e caro para corrigir
• O CMS se torna desactualizado devido ao movimento de ativos de
hardware não-autorizado pessoal; semestral física auditars deve ser
conduzida com discrepâncias em destaque e investigados; gestores
devem ser informados de inconsistências em suas áreas.

4,4 Gerenciamento de Liberação e Implantação
Gerenciamento de Liberação e Implantação visa construir,teste e entregar o
capacidade para fornecer os serviços especificados pela Design de Serviços e
que irá realizar o das partes interessadass ' exigências e entregar os objectivos
pretendidos.
4.4.1 Finalidade, finalidade e objectivo
O objectivo da Gerenciamento de Liberação e Implantação é a seguinte:
• Definir e acordar liberar e desenvolvimento planos com os clientes e
partes interessadas
• Garantir que cada pacote de lançamento é composto de um conjunto de
ativos e serviços componentes que são compatíveis uns com os outros
• Certifique-se que integridade de um pacote de libertação e dos seus
componentes constituintes é mantida durante todo o transição atividades
e registradas com precisão no CMS
• Garantir que todos os liberação e desenvolvimento pacotes podem ser
rastreadas, instalados, testados, verificados e / ou desinstalado ou saiu se
for o caso
• Certifique-se que organização e mudança das partes interessadas é
gerenciado durante as atividades de lançamento e implementação (ver
seção 5).
• Registrar e controlar desvios, riscos, questões relacionadas com o serviço
novo ou alterado e tomar ações corretivas necessárias
• Certifique-se que não há transferência de conhecimento para permitir que
os clientes e usuários para otimizar seu uso do serviço para apoiar as
atividades de seus negócios
• Assegurar que as habilidades e os conhecimentos são transferidos para
operações e pessoal de apoio que lhes permitam de forma eficaz e
eficiente entregar, apoiar e manter o serviço de acordo com as garantias
exigidas e nível de serviços.
O objetivo da Gerenciamento de Liberação e Implantação é implantar versões
em produção e estabelecer o uso eficaz da serviço a fim de entregar valor para o
cliente e ser capaz de transferência para operações de serviços.
O objetivo de Gerenciamento de Liberação e Implantação é o de assegurar que:
• Há liberação clara e abrangente e implantação planos que permitem a
mudança de cliente e de negócios projetos para alinhar suas atividades
com estes planos
• Um pacote de lançamento podem ser construídos, instalados, testados e
implantados de forma eficiente a um grupo de implantação ou alvo
ambiente com sucesso e dentro do cronograma

• Um serviço novo ou alterado e sua habilitação sistemaA tecnologia e
organização são capazes de fornecer o serviço acordado exigências,
utilitários ou seja, garantias e nível de serviços
• Há imprevisto mínimo impacto sobre os serviços da produção, operações
e organização de suporte
• Clientes, usuários e Serviço de Gestão de funcionários estão satisfeitos
com o Transição de Serviço práticas e saídas, por exemplo
documentação do usuário e treinamento.
4.4.2 Âmbito
O escopo de Gerenciamento de Liberação e Implantação inclui os processos,
sistemas e funções para embalagem, construir, E teste e implantar uma liberar
em produção e estabelecer o serviço especificado na Pacote Service Design
antes de entrega final para operação de serviços.
Eficaz Gerenciamento de Liberação e Implantação permite que o provedor de
serviços para agregar valor ao negócio por:
• Cumprindo mudar, Mais rápido e com melhor custar e minimizado risco
• Assegurando que os clientes e os usuários podem usar o serviço novo ou
alterado de uma forma que suporta os objetivos de negócio
• Melhorar a coerência na abordagem de implementação em toda a
mudança em negócios, equipes de serviço, fornecedors e clientes
• Contribuindo para atender aos requisitos auditáveis para rastreabilidade
através Transição de Serviço.
Bem planejado e implementado liberar e desenvolvimento vai fazer uma
diferença significativa para um organização"Custos do serviço s. Um
comunicado mal projetado ou de instalação, na melhor das hipóteses, forçar o
pessoal de TI a gastar quantidades significativas de solução de problemas de
tempo problemas e gestão da complexidade. Na pior das hipóteses, ele pode
aleijar o ambiente e degradar o viver serviços.
4.4.4.1 Unidade de Lançamento e identificação
A 'unidade de liberação"Descreve a porção de um serviço ou Infra-estrutura de
TI que é normalmente liberado em conjunto de acordo com comunicado da
organização política. A unidade pode variar, dependendo do tipo (s) ou item (s)
de serviço ativo ou serviço componente tais como software e hardware. Figura
4.15 apresenta um exemplo simplificado mostrando um De serviços de TI

composta de sistemas e ativos de serviços, que são por sua vez formadas por
serviço componentes.
Figura 4.15 Exemplo simplificado de unidades de liberação de um serviço de TI
O objetivo geral é o de decidir o mais adequado nível de liberação da unidade
para cada serviço ativo ou componente. Uma organização pode, por exemplo,
decidir que o unidade de liberação para negócios críticos aplicaçãos é a
aplicação completa, a fim de assegurar que o teste está incompleta. A mesma
organização pode decidir que uma unidade de liberação mais apropriado para
um site é no nível da página.
Os seguintes fatores devem ser levados em conta no momento de decidir o nível
adequado para unidades de liberação:
• A facilidade ea quantidade de mudanças necessárias para liberar e
implantar uma unidade de liberação
• A quantidade de recursos e o tempo necessário para construir,teste,
Distribuir e implementar uma unidade de liberação
• A complexidade das interfaces entre a unidade projectada e o resto dos
serviços e infra-estruturas de TI
• O armazenamento disponível na compilação, teste, distribuição e viver
ambientes.
Soltes devem ser identificado exclusivamente de acordo com um esquema
definido na política de liberação como discutido na seção 4.1.4.2. O identificação
de liberação deve incluir uma referência para o IC e que representa um versão
número que, muitas vezes, ter duas ou três peças, por exemplo, emergência de
consertos: Payroll_System v.1.1.1, v.1.1.2, v.1.1.3.
4.4.4.2 versão opções de design e considerações
Design de Serviços vai definir a abordagem a transição do actual serviço para o
serviço novo ou alterado ou oferta de serviços. A SDP define o serviço e solução

projeto componentes para ser transferida para fornecer a necessária pacote de
serviços(S) e pacote de nível de serviço(S).
As opções comuns para a liberação e desenvolvimento que são considerados
em serviço Projeto são discutidos abaixo. A opção seleccionada terá uma
significativa impacto sobre os recursos de libertação e de implantação, bem
como a actividade resultados. É importante compreender os padrões de negócio
atividade (PBA) e perfil do usuários quando planejamento e projetar os
lançamentos.
Vs 'Big Bang' faseada
Opções para implantar novas versões para vários locais encontram-se ilustrados
na Figura 4.16 e descrito a seguir:
• Opção de "Big Bang" - o serviço novo ou alterado é implantado em todas
as áreas de usuário em um operação. Isso muitas vezes ser usado
quando a introdução de uma aplicação mudança e consistência do
serviço em todo o organização é considerado importante.
• Abordagem por etapas - o serviço é implantado em uma parte da base de
usuários inicialmente, e depois desta operação é repetida para partes
posteriores da base de usuários por meio de uma programada
lançamento plano. Este será o caso em muitos cenários tais como nas
organizações de retalho para novos serviços a serem introduzidos nas
lojas ' ambiente em fases gerenciáveis.
Figura 4.16 Opções para 'big bang' e lançamento faseado

Figura 4.16 também ilustra uma sequência possível de eventos ao longo do
tempo como se segue:
• Há um lançamento inicial do 'Release 1 "do sistema para três estações de
trabalho (1-3).
• Duas estações de trabalho adicionais (4 + 5) são então adicionados ao
mesmo tempo.
• 'Release 2 "do sistema é, então, lançado em uma abordagem de" big
bang "para todas as estações (1-5) de uma só vez.
• Duas estações de trabalho adicionais (6 +7) são então adicionados, em
um passo.
• Há uma implementação faseada do upgrade para "versão 3" do sistema,
inicialmente atualizar apenas três estações de trabalho (1-3) e, em
seguida, os quatro restantes (4-7).
• Uma estação de trabalho adicional (8) é então adicionado ao sistema.
Variações do processo progressivo incluem:
• Porções do serviço são entregues ao viver ambiente em fases finais, mas
todos usuários são afetados simultaneamente (por exemplo, mudanças
incrementais para um aplicativo compartilhado).
• Cada liberar é implantado gradualmente em toda a população total de
usuários finais (por exemplo, localização geográfica um de cada vez).
• Diferentes tipos de elemento de serviço são implantados em fases
distintas, por exemplo, alterações de hardware são: primeiro, seguido de
treinamento do usuário e, em seguida, pelo software novo ou alterado.
• A combinação de todas estas abordagens é habitualmente adoptada, e os
planos podem deliberadamente permitir variações, à luz da actual
desenvolvimento experiência.
No tipo de execução em fases ilustrado acima, é apenas possível empregar esta
abordagem se o serviço foi concebido para permitir que novos e velhos versãos
de coexistir. Se isso não for possível, então a única alternativa é atualizar todas
as partes afetadas juntos na implementação de um "big bang". Para os
elementos, tais como documentação, de pessoal qualificado isso raramente é
um problema, Pois muitos casos de hardware e software, é possível. Por outras
transições, tais como os que envolvem mudanças de rede principais, pode ser
virtualmente impossível de alcançar.

Figura 4.17 Phased implantação em locais geográficos
Figura 4.17 ilustra a implantação gradual para um número de diferentes
localizações geográficas. Ele assume que o novo versãos vai trabalhar ao lado
do anterior. O exemplo utilizado assume que a nova funcionalidade é
implementado em primeiro lugar na sede da organização, Em seguida, numa
piloto ramificar e finalmente nos demais ramos. Se existem um grande número
de locais para tratar, ainda pode demorar muito tempo para executar o sistema
inicial ou melhoramentos em todos os ramos, aumentando assim a probabilidade
de que necessitam para apoiar ainda mais versões do sistema no viver ambiente
concorrentemente.
Empurrar e puxar
Uma abordagem de pressão é utilizado quando o serviço componente é
implantado a partir do centro e enviados para os locais de destino. Em termos de
serviço implantação, entregando atualizados componentes de serviço para todos
usuários - ou em big-bang ou faseada forma - constitui "empurrar", desde que o
serviço novo ou alterado é entregue para os usuários ' ambiente em um
momento não de sua escolha.
Uma abordagem de tração é usado para software liberars, onde o software é
disponibilizado em um local central, mas os usuários são livres para puxar o
software para baixo a seu próprio local em um momento de sua escolha ou
quando uma estação de trabalho do usuário reinicia. O uso de "pull" atualizando
um comunicado sobre a internet tornou este conceito muito mais abrangente.
Um bom exemplo é atualizações de assinatura de vírus, que normalmente são
puxados para baixo para atualizar PCs e servidors quando é melhor se adequa à
cliente, Mas em tempos de extrema vírus risco este pode ser substituído por
uma versão que é empurrado para todos os usuários conhecidos.

Para implantar via 'push' abordagem, os dados em todos os locais de usuário
deve estar disponível. Abordagens Pull não descansar tão fortemente nos dados
de configuração precisos e podem desencadear uma atualização para o usuário
registros. Isso pode ser através de novos usuários aparecendo e solicitar
downloads ou usuários esperados não fazê-lo, desencadeando investigação
sobre sua existência. Como alguns usuários nunca "puxar" um lançamento pode
ser apropriado para permitir que um "pull" dentro de um limite de tempo
especificado e se este for excedido um empurrão será obrigado, por exemplo,
para uma atualização do anti-vírus.
Automação vs Manual
Seja pela automação ou outros meios, os mecanismos para liberar e implantar o
serviço corretamente configurado componentes devem ser estabelecidos na
liberação projeto fase e testados no construir e teste fases.
Automação vai ajudar a garantir a repetibilidade e consistência. O tempo
necessário para fornecer um mecanismo bem concebido e eficiente
automatizado pode não estar sempre disponível ou viável. Se um mecanismo
manual é utilizada é importante para monitorar e medir a impacto de muitas
repetidas atividades manuais, que são susceptíveis de ser ineficiente e
erroPropensa. Muitas atividades manuais vai abrandar a equipe de lançamento
e criar recurso ou capacidade questões que afetam a nível de serviços.
Muitos de libertação e desenvolvimento actividades são capazes de um grau de
automação. Por exemplo:
• Descoberta liberação de ajuda de ferramentas planejamento.
• Descoberta e software de instalação pode verificar se os pré-requisitos
necessários e co-requisitos estão no local antes da instalação de
componentes de software novos ou alterados.
• Compilações automatizadas pode reduzir significativamente a construir e
recuperação vezes que por sua vez pode resolver conflitos de
agendamento e atrasos.
• Configuração automática linha de base procedimentos poupar tempo e
reduzir erros em capturar a estado de configurações e lançamentos
durante a construção, teste e implementação.
• Comparações automáticas do real 'viver"Configuração com a
configuração esperada ou CMS ajudar a identificar problemas na primeira
oportunidade que poderia causar incidentes e atrasos durante a
implantação.
• Processos automatizados para carregar e atualizar dados para a ajuda
CMS para garantir os registros são precisos e completos.
• Instalação procedimentos atualizar automaticamente informações de
usuário e licença no CMS.

Projetando pacotes de libertação e liberação
Figura 4.18 apresenta um exemplo de como os elementos de arquitectura de um
serviço pode ser mudado a partir da linha de base actual para a nova linha de
base com liberars em cada nível. O arquitetura será diferente em algumas
organizações, mas é fornecida nesta seção para dar um contexto para liberar e
implantação de atividades. As equipes de lançamento e implantação precisa
entender a relevante arquitetura , a fim de ser capaz de plano, do pacote, e
construir teste um lançamento para suportar o serviço novo ou alterado. Isso
ajuda a priorizar as atividades de liberação e implantação e gerenciar
dependências, por exemplo, a infra-estrutura de tecnologia precisa estar pronto
com a equipe de operações pronto para apoiá-lo com novos ou alterados
procedimentos antes de uma aplicação é instalado.
Figura 4,18 elementos de arquitetura a ser construído e testado
Figura 4.18 também mostra como os elementos de serviço arquitectónicos
dependem do Portfólio de Serviços que define as ofertas de serviços e pacote
de serviçoss. Serviços dependentes terá de ser construído e testado em
Transição de Serviço. Por exemplo, um serviço de TI financeira pode estar
dependente de vários serviços de apoio interno e um serviço externo. Para mais
detalhes sobre a estrutura dos serviços, consulte o Estratégia de Serviço e
Design de Serviços publicações.
Normalmente, existem dependências entre especial versãos de serviço
componentes necessária para o serviço de operar. Por exemplo, uma nova
versão de um aplicativo pode exigir uma atualização para o sistema operacional
sistema e uma ou a outra destas duas alterações poderiam requerer uma
alteração de hardware, por exemplo, um processador mais rápido ou mais
memória. Em alguns casos, o pacote de libertação pode ser constituída por um
conjunto de documentos e procedimentos. Estes poderiam ser implantado

através de uma atualização manual ou por meio de um mecanismo de
publicação automática, por exemplo, para os SKMS / site.
Um pacote de libertação pode ser um único unidade de liberação ou um
conjunto estruturado de unidades de libertação, tais como o mostrado na Figura
4.19.
Figura 4.19 Exemplo de um pacote de lançamento
O exemplo na Figura 4.19 mostra uma aplicação com a sua usuário
documentação e uma unidade de liberação para cada plataforma de tecnologia.
À direita, há o cliente serviço ativo que é suportado por dois serviços de apoios -
SSA para o serviço de infra-estrutura e SSB para o serviço de aplicação. Estas
unidades de liberação irá conter informações sobre o serviço, suas utilidades e
garantias e documentação de liberação. Muitas vezes, haverá diferentes formas
de concepção de um pacote de lançamento e consideração deve ser dada para
estabelecer o método mais adequado para as circunstâncias identificáveis, das
partes interessadass e possibilidades.

Sempre que possível, os lançamentos devem ser concebidos de modo que
algumas unidades de liberação pode ser removido se causar problemas em
testes.
Valiosa de lançamento do Windows
AReino Unido departamento do governo é especialmente bem colocado para
fazer pleno uso de todos os disponíveis janela de lançamentos. Eles trabalham
em uma financeira segura, de baixa risco ambiente, Com mudanças
programadas cuidadosamente planejadas com antecedência e atribuída a pré-
estabelecido de lançamento do Windows, que estão programados vários meses
separados. Devido ao seu cuidado e longo prazo planejamento, Quando uma
alteração de prova inadequados para liberar, I.e. testes são falhou, alternativa,
qualidadeGarantida mudanças são geralmente disponíveis - preparada e
testada, mas com menor prioridade do negócio e assim voltado para versões
posteriores. Estes podem ser aceleradas para fazer uso da vaga inesperada
criada pelo teste falha. O teste e construir processo também permite que
elementos de lançamentos programados para depois ser encaixados em para a
liberação, ou componentes de sucesso do lançamento não conseguiu ser
implementada, mesmo que os produtos completos não está pronto. Isso permite
mais completa posterior liberação para ser um 'menor' do produto, permitindo
assim que mais mudanças adicionais para ser agendada junto a eles em janelas
versão superior.
Figura 4.20 Coordenar a implantação de componentes de serviço

Qualquer serviço novo e significativo ou alterados ou oferta de serviços vai exigir
o desenvolvimento encenar a considerar toda a gama de elementos que
compreende que serviço - Infra-estrutura, hardware, software, aplicaçãos,
documentação, etc conhecimento Efectivamente, isto significa a implantação irá
conter sub-elementos que compõem as implantações para o serviço, tal como
ilustrado na Figura 4.20. A combinação, relação e interdependências destes
componentes exigirá cuidadosa e considerada planejamento. Implementações
significativas será complexa projetos em seu próprio direito.
Para entender as opções de implantação de um elevado nível avaliação das
unidades de implantação, localização e ambientes pode ser necessária, por
exemplo:
• Avaliação linha de base - Este é um instantâneo do ambiente relevante,
serviços e infra-estrutura, incluindo "mais flexíveis" elementos tais como
habilidades de nível e atitudes se for o caso, deve ser tomado como um
primeiro passo.
• Identificar os componentes - o que pode incluir decidir a melhor maneira
de quebrar uma implantação maior em componentes. Muitas vezes,
haverá diferentes maneiras de alcançar esse colapso e consideração
deve ser dada para estabelecer o método mais apropriado para todas as
circunstâncias identificáveis, das partes interessadass e possibilidades.
• Determinar a abordagem de implementação apropriado para cada um.
4.4.4.3 modelos de lançamento e implantação
Aserviço pode ser implantado no ambiente de produção em um número de
maneiras. Design de Serviços irá selecionar o mais adequado liberar e
desenvolvimento modelos que incluem a abordagem, mecanismos, processos,
procedimentos e os recursos necessários para construir e implantar a versão em
tempo e dentro orçamento.
Os métodos de liberação durante a construção e início de estágios do teste
podem diferir significativamente viver operações, para planejar com
antecedência para assegurar que os métodos de liberação apropriadas sejam
adotadas, no momento certo.
Lançamento e implantação modelos definir:
• Lançamento estrutura - a estrutura geral para a construção de uma liberar
pacote e os ambientes-alvo
• Os critérios de entrada e saída, incluindo obrigatória e opcional entregas
e documentação para cada fase
• Ambientes controlados necessários para construir e testar a versão para
cada nível de liberação, haverá vários ambientes físicos e lógicos através

da Transição de Serviço fase mapeada para diferentes ambientes físicos
disponíveis para o transição equipe
• Os papéis e responsabilidades de cada item de configuração em cada
nível de liberação
• A promoção de lançamento e modelo de base de configuração
• Liberação modelo e horários de implantação
• Apoiar sistemas, ferramentas e procedimentos para documentar e
acompanhar todas as atividades de lançamento e implantação
• A entrega atividades e responsabilidades para a execução da entrega e
aceitação para cada fase de liberar e implantação.
Considerações na concepção do modelo de implantação e lançamento incluem
atividades para:
• Verifique se uma liberação está em conformidade com o SDP, arquitetura
e afins padrãos
• Garantir a integridade de hardware e software é protegido durante a
instalação, manuseio, embalagem e entrega
• Use versão padrão e desenvolvimento procedimentos e instrumentos
• Automatizar a entrega, distribuição, instalação, construir e configuração
auditar procedimentos onde for apropriado para reduzir dispendiosas
etapas manuais
• Gerenciar e implantar / re-implantar / remover /aposentar licenças de
software
• Pacote e construir o pacote de liberação de modo que podem ser
desfeitas ou remediados se necessário
• Usar Gerenciamento da Configuração procedimentos, o CMS e DML para
gerenciar e controlar componentes durante as atividades de construção e
implantação, por exemplo, verificar os pré-requisitos, co-requisitos e pós-
instalação pedidos
• Documentar os passos de lançamento e implantação
• Documentar o grupo de implantação ou alvo ambiente que irá receber a
liberação
• Emitir notificações de serviço.
4.4.5.1 Planejamento
Planos de lançamento e implantação
Planos para liberar e implantação será ligado no geral Transição de Serviço
planejar e adotar a versão selecionada e implantação modelo. A abordagem
consiste em obter um conjunto de som diretrizs para a libertação e posterior
implantação de produção que pode ser escalado a partir de pequenas
organizações de grandes multinacionais. Embora as organizações menores

terão ambientes menos complexos, as disciplinas detalhadas aqui ainda são
relevantes. Mesmo dentro de um único organização, Os planos de lançamento e
implantação precisa ser escalável desde a extensão da sua escala de impacto
sobre a organização irá variar, talvez de impacto apenas uma pequena equipa
de especialistas em um local através de impacto multinacional em todos os
usuários quando introduzir equipamento novo desktop e serviços ou serviços de
transferência para diferentes fornecedors.
Planos de lançamento e implantação deve ser autorizado através Gestão da
Mudança. Eles devem definir a:
• Escopo e conteúdo da libertação
• Avaliação de risco e risco perfil para o lançamento
• Organizações e das partes interessadass afectados pela libertação
• As partes interessadas que aprovou a mudar pedido para a liberação e /
ou implantação
• Equipe responsável pela liberação
• Aproxime-se de trabalhar com as partes interessadas e grupos de
implantação para determinar a:
• Entrega e desenvolvimento estratégia
• Recursos para a liberação e implantação
• Quantidade de mudar que pode ser absorvida.
Aprovação / reprovação critérios
Transição de Serviço é responsável por planejamento o. passa / falha situações
No mínimo estes devem ser definidos para cada ponto de autorização através
do estágio de lançamento e implantação. É importante publicar estes critérios
para os interessados com antecedência, para definir as expectativas
corretamente. Um exemplo de uma situação de passagem antes construir e
teste é o seguinte:
• Todos testes são concluídas com êxito, o avaliação relatório e RFC para
construção e teste são assinados fora.
Exemplos de situações falhar incluem:
• Recursos suficientes para passar para a próxima fase. Por exemplo, uma
compilação automatizada não é possível e assim a recurso exigência
torna-se propenso a erros, muito oneroso e caro; testes identifica que não
haverá dinheiro suficiente para entregar a proposta projeto na fase de
operações.
• Operação de Serviço não tem capacidades para oferecer serviço
particular atributos.
• Design de Serviços não se conforma com a operação do serviço padrãos
para as tecnologias, protocolos, regulamentos, etc

• O serviço não pode ser entregue dentro dos limites das restrições de
projeto.
• Critérios de aceitação de serviços não são cumpridos.
• Documentos obrigatórios não estão assinadas.
• SKMS e CMS não são atualizados, talvez devido a uma processo que é
manual intensivo.
• O incidentes, problemas e os riscos são mais elevados do que o previsto,
por exemplo, mais de 5%.
Construir e testar antes da produção
Construir e planeamento de teste determina a abordagem para a construção,
teste e de manutenção dos ambientes controlados antes da produção. As
atividades incluem:
• Desenvolver construir planos a partir do desenho SDP, especificaçãos e
ambiente configuração exigências
• Estabelecer a logística, os prazos de entrega e tempo de construção para
configurar os ambientes
• Testando a construir e relacionado procedimentos
• Agendamento das atividades de construção e teste
• Atribuir recursos, papéis e responsabilidades para realizar atividades-
chave, por exemplo:
• Segurança procedimentos e controlos
• Suporte técnico
• Preparação construir e ambiente de testes
• Gerenciando teste bases de dados e os dados de teste
• Software ativos e gestão de licenças
• Gerenciamento da Configuração - Configuração auditar, Construir
e linha de base gestão
• A definição e adopção dos critérios de construção de saída e entrada.

Figura 4.21 Serviço V-modelo para representar níveis de configuração e testes
Figura 4.21 apresenta um exemplo de um modelo que pode ser usado para
representar os níveis de configuração diferentes sejam construídos e testados
para fornecer um serviço capacidade. O lado esquerdo representa o
especificação dos requisitos de serviço até à detalhada Design de Serviços. O
lado direito centra-se na validação e actividades de teste que são executadas
em relação às especificações definidas no lado da mão esquerda. Em cada
etapa, no lado esquerdo, há um envolvimento direto pela parte equivalente no
lado direito. Ela mostra que a validação de serviço e aceitação teste
planejamento deve começar com a definição de serviço exigências. Por
exemplo, os clientes que assinar as exigências de serviço acordados também
vai assinar o critérios de aceitação de serviços e teste plano.
A abordagem modelo V-é tradicionalmente associada com a cachoeira ciclo de
vida, Mas é, na verdade, apenas aplicável a outros ciclos de vida, incluindo
iterativos ciclos de vida, tais como prototipagem, RAD abordagens. Dentro de
cada ciclo iterativo do desenvolvimento, Os conceitos do modelo V-de
estabelecer requisitos de aceitação em relação aos requisitos e projeto pode
aplicar, em cada desenho iterativo sendo consideradas para o grau de
integridade e competência que justificaria a libertação para o cliente para o
julgamento e avaliação.
Mais detalhes sobre o teste de validação, e serviço avaliação são fornecidos nas
secções 4.5 e 4.6. O teste estratégia define a abordagem geral para validação e
teste. Ele inclui a organização de actividades de validação e testes e recursos e

pode aplicar a toda organização, Um conjunto de serviços ou de um serviço
individual.
Os níveis típicos de configuração para construção e teste são apresentados na
Tabela 4.8.
Nível Requisitos e
projeto
Construir /
realizações
Validação e teste
Nível 1 Cliente
/ necessidades
de negócio
Definição
estruturada de
contrato requisitos
Contrato com o
cliente (com base
em Portfólio de
Serviços, SLP)
Teste de serviço e avaliação
Determina se um serviço pode
permitir a usuários e os clientes
para usar o serviço para apoiar as
necessidades de seus negócios (é
apto para o efeito e apto para uso).
Requisitos de
nível de
serviço 2
Exigência de
serviço
especificaçãos e
SAC, de volta
rastreáveis ao
contrato requisitos
Serviço capacidade
e recursos para
proporcionar contra
o SLA e serviço
requisitos
Teste de serviço
Teste os critérios de aceitação de
serviço são cumpridos. Inclui a
validação do serviço atuação
contra o exigência de nível de
serviços e SLA em pilotos,
implantação e apoio início da vida.
Nível de
solução
Serviço 3
SDP, Serviço
modelo, Serviço
de ambientes
Solução /sistema
necessária para
fornecer a
capacidade de
serviço; inclui
Serviço de Gestão
de e Operação de
Serviços sistemas e
capacidades
Serviço operacional teste de
prontidão
Para avaliar a integração e
operação da capacidade de
serviço e de recursos. Verifica-se
que o alvo desenvolvimento
organização e as pessoas estão
preparadas para implantar e
operar o serviço novo ou alterado
no viver ambiente, E.g. equipe de
implantação, operações de
serviços, clientes, usuários e
outros das partes interessadass.
Os testes incluem testes baseada
em cenários como a simulação e
ensaio serviço.
Serviço de
nível 4 liberar
Pacote de
lançamento
Serviço de teste de libertação
Um teste que o serviço
componentes pode ser integrado
de forma correcta e que a
libertação pode ser instalado,
construído e testado no alvo
ambientes. Serviço de teste de
libertação inclui o teste não-
funcional que pode ser realizado a
este nível.
Component Componente e Componente ou Componente e teste de

Level 5 e
conjuntos
montagem teste
especificação
conjunto de
componentes
montagem
Testar se um componente de
serviço ou montagem de
componentes corresponde a sua
especificação detalhada.
Componentes ou conjuntos são
testadas em isolamento, tendo em
vista a sua entrega, tal como
especificado, em termos de
entradas gerando resultados
esperados. Evidência de
componente qualidade ou ensaio
no início da cadeia pode ser obtida
por provas de ensaio, a partir tanto
interno como externo fornecedors.
Tabela 4.8 Níveis de configuração de construção e testes
Vários controlado ambientes terá de ser construído ou disponibilizados para os
diferentes tipos e níveis de testes, bem como para apoiar outras transição
atividades como treinamento. Existente desenvolvimento processos e
procedimentos pode ser usada para construir a controlada ambiente de testes.
Os ambientes terá de ser seguro, para assegurar que não há acesso não
autorizado e que qualquer segregação de dever exigências sejam satisfeitas. Os
tipos de ambientes, lógicos e físicos, exigidos durante a liberação e implantação
incluem:
• Construir ambientes - usado para compilar ou montar o pacote de
lançamento ou serviço ativos
• Ao ambiente de teste - utilizado para verificar a funcionalidade,
atuação,recuperação e usabilidade características de um componente de
serviço individual, por exemplo, processo on-line
• Montagem ambiente de teste - utilizado para verificar a funcionalidade,
desempenho, recuperação e características de usabilidade de um
conjunto de componentes de serviços
• Ambiente de integração - para construção e integração de componentes
de serviço
• Sistema ambiente de teste - utilizado para testar todos os aspectos do
serviço integrado arquitetura, Incluindo a aplicação e infra-estrutura
técnica; substancial usuário teste de aceitação é executado neste
ambiente
• Serviço liberar ambiente de teste - usado para instalar, construir e testar
um pacote de libertação em um ambiente controlado, o que é
frequentemente combinada com o ambiente de teste do sistema
• Operação de Serviçoambiente de teste de prontidão - para testar a
serviço e capacidades da unidade de serviços antes da promoção em
viver; Podem incluir o Serviço de Gestão de aceitação teste, alguns
operacional testes de aceitação e testes de aceitação do usuário do
serviço de fim-de-final

• Simulação de ambientes de negócios
• Serviço ambientes de simulação de gestão
• Ambientes de formação - por vezes, esta pode incluir uma base de dados
de teste estabelecido que pode ser usado como um meio de formação
segura e realista
• Piloto ambientes, incluindo pilotos de sala de conferência
• Faça backup e recuperação ambientes, por exemplo, recuperação de
desastres.
Planejamento pilotos
Pilotos são úteis para testar o serviço com uma pequena parte da base de
usuários antes de rolar para fora para a comunidade de serviço todo. É
importante para determinar o apropriado escopo de um piloto (o quanto da
serviço deve ser incluído no tamanho piloto, de departamento ou base de
utilizadores). Este é um passo fundamental para estabelecer o esforço do piloto.
Se o escopo é muito pequena então funcionalidade insuficiente e as variações
de implementação será testado ea probabilidade de significativo erros não ser
descoberto até completa lançamento é maior. Se o escopo é muito grande, não
vai entregar a velocidade e flexibilidade que oferecem os benefícios, mas será
efetivamente um lançamento em primeiro lugar.
Um piloto pode ser utilizado para determinar a viabilidade da maioria, se não
todos, os aspectos do serviço. Mas isso só vai acontecer se tudo das partes
interessadass estão ativamente envolvidos no piloto e usar o serviço como isso
seria feito em um lançamento completo.
O piloto deve incluir medidas para coletar feedback sobre o eficácia do
desenvolvimento plano. Isto pode incluir:
• Topografia pontos de vista e de satisfação de:
• Os usuários finais
• Clientes
• Fornecedors
• Balcão de atendimento e outro pessoal de apoio
• Gerenciamento de rede
• Dados e Gestão do Conhecimento - Estatísticas sobre o uso e eficácia
• Analisando as estatísticas de balcão de atendimento
chamadas,fornecedors, capacidade e disponibilidade.
Compromisso de apoiar o piloto é exigido de todas as partes envolvidas.
Obtenção de que o compromisso pode ser um desafio, pois normalmente os
pilotos vão representar o trabalho adicional para aqueles usuários envolveu mais
e acima de seus trabalhos do dia. Colaboração de fornecedores e pessoal de
apoio (que pode ter que apoiar dois versãos de um serviço em paralelo, ou

entregar uma pequena unidade separada dedicada a apoiar o piloto) também
deve ser obtido.
Planejamento deve acomodar a reversão de um piloto antes da completa
lançamento de um serviço autorizado novo. Novos serviços tendem a ser
pilotado com equipamento de teste e isso precisa ser revertido ao seu estado
original. Além disso, os usuários que faziam parte do piloto deve estar
trabalhando com o mesmo componentes de um serviço como outros usuários
após a implantação completa, não a configuração colocar no lugar para o piloto.
Isto simplifica o dia-a-dia das operações em IT Service Management.
Apesar de um piloto é frequentemente considerada como um julgamento no
ambiente de produção antes de lançar um serviço para fora através do cliente
completo e ambiente de usuário, pode haver justificação para uma série de
pilotos, por exemplo, um piloto para desenvolvimento para cada região
geográfica. Muitas considerações são relevantes, com a melhor solução para
uma dada circunstância de ser um equilíbrio entre benefícios e custar. Fatores
incluem:
• Velocidade e custo - Um único piloto será mais barato e mais rápido do
que vários pilotos, e é a escolha óbvia para um homogêneo organização
onde um único piloto vai encontrar (quase) todas as eventualidades e
assim proporcionar um alto grau de confiança de que um piloto bem
sucedido seria seguido por uma implantação bem sucedida em toda a
organização mais ampla.
• Organização diversificada - Em uma organização com uma série de
circunstâncias em toda a base de usuários, ou com vários ambientes
operacionais, uma vasta correspondência de pilotos pode ser sensato,
com um ensaio em cada uma das áreas. Estes podem ser geridos em
paralelo, com experimentação simultânea em cada ambiente, O que
reduz o tempo decorrido, mas aumenta a gestão despesas gerais e
complexidade. Como alternativa, executando os pilotos em série, lições
aprendidas em um ambiente pode ser aplicado com proveito para os
posteriores, uma vez que mesmo em diversos organização não é
provável que seja uma base comum significativo, por exemplo, dentro do
serviço real componentes. Exemplos de diversidade significativa incluem:
• Diferentes métodos de treinamento necessários para diferentes
grupos
• Tecnologia
• Língua ou cultura
• Rede capacidade.
• Opções de experimentação - Onde soluções alternativas são possíveis
para um lançamento importante, que pode valer a pena tentar cada uma
das opções em separado piloto (De preferência em áreas estreitamente
alinhados para fazer comparações significativas). Armado com os
resultados de cada piloto, uma decisão quanto à abordagem para o

lançamento principal pode ser tomada com base na evidência empírica
sólida.
• Considerações políticas - Internas ou externas questões políticas pode
significar que um grupo específico ou grupos precisa ser envolvido - ou
não envolvido - em um piloto para um serviço novo ou alterado.
Exemplo de necessidade de múltipla pilotagem
Um governo organização entrega de desktop De serviços de TIs para todos os
seus funcionários - em sede corporativa (HQ) e em locais em todo o mundo.
Quando as mudanças são novos ou significativa a ser lançada, em geral, três
pilotos paralelos são realizados para testar os três níveis de comunicação e
tecnologia de suporte que identificaram:
• Aqueles em HQ na conexão de rede direta e com a equipe de apoio local
dedicado
• Aqueles em locais maiores, com conexão de alta velocidade confiável e
semi-especializados locais os administradores de TI
• Aqueles em locais menores, com comunicações confiáveis e sem apoio
treinado local.
A experiência tem mostrado que os três grupos têm aplicação diferentes e
problemas de suporte e que os pilotos em todos os três tipos de cliente valem os
custos adicionais e complicações.
Planejamento embalagem liberação e construir
Planejamento o liberar embalagem e construir atividades inclui as atividades a
desenvolver os mecanismos, planos ou procedimentos para o seguinte:
• Verificando os critérios de entrada / saída
• Gerenciando das partes interessadas mudar e comunicações por:
• Obter e manter a lista de contatos e seus detalhes
• Comunicar as alterações propostas, os benefícios esperados e
como a mudança afeta a organização e pessoal
• Formação de pessoas e conhecimentos transferência
• Estabelecer os Serviços e serviço ativos, por exemplo, acordos e
contratos estão em vigor
• Horários concordando:
• Concordando os prazos de entrega e manipulação de quaisquer
alterações / atrasos
• Finalizando a logística e entrega procedimentos e listas de
verificação
• Agendamento e alocação controlada transição ambientes,
instalações e ferramentas para: (i) aquisição de ativos de serviços
e componentes, e (ii) libertação de embalagem, construção e teste

• Desenvolvimento de procedimentos e mecanismos que utilizam
disponível Gerenciamento da Configuração, Lançamento, conteúdo /
publicação eletrônica e outras ferramentas para:
• Construir, Cópia, promover, distribuir, auditar, Instalar e ativar um
lançamento
• Gerenciar licenças de software, digital direitos e Direitos de
Propriedade Intelectual (DPI)
• Conversão sistemas e usuários a partir do actual aplicaçãos e tecnologia
para o serviço novo ou alterado, por exemplo, migrar ou reformatar dados
de aplicações e informações
• Desenvolver o Serviço de Gestão de capacidade e recursos para:
• Realização de pesquisas de local
• Atualizando informações sobre o serviço, por exemplo, catálogo de
serviços,liberar documentação
• Construção e elaboração do gestão da informaçãos e outros
operacional sistemas, como por exemplo sistemas e gestão de
eventos, Sistemas de medição
• Operar e manusear o previsto capacidade necessária para suporte
• A operação dos ambientes controlados, incluindo procedimentos
para expandir a capacidade, se necessário
• Documentar e fornecer a informação a ser criado e / ou atualizado
durante transição, E.g. remediação planos para ser elaborado e
publicado
• A instalação do serviço novo ou alterado pronto para a ativação
• Transferência / transição uma equipe de serviço ou serviço ou
organização
• Desactivação e / ou eliminação de serviço ativos e componentes
• Serviços cessantes
• Avaliação da preparação de um alvo desenvolvimento grupo (clientes,
usuários e Operação de Serviços pessoal) para tomar uma liberação
• A definição e adopção dos critérios de saída.

Planejamento de implantação
Existem muitas considerações de planeamento que necessitam de ser
consideradas. Planejadores deve ser capaz de responder as questões incluídas
na Tabela 4.9.
Pergunta implantação Exemplos
O que precisa ser
implantado?
Você tem uma boa compreensão do serviço e lançamento que está
sendo implantado? Quais são os componentes que compõem o
pacote de lançamento? Quais são os negócio drivers para a
implantação? É exigido para atender a uma necessidade crítica de
negócios?
Quem são os usuários? Qual os usuários são afetados pela implantação? Que linguagem que
eles usam? Será que eles precisam de nenhum treinamento
especial?
Há localização
dependências?
Há algum férias, de paragem ou outras interrupções para negócio
normal neste local? Qual o nível de necessidades de detalhe a ser
registrado, por exemplo, edifício, chão da sala,?
Onde estão os
usuários?
São todos os usuários e sistemas local para a implantação, ou são
alguns remoto, e como isso afetará a logística?
Quem mais precisa ser
preparado com
antecedência?
Faça o balcão de atendimento e apoio à formação necessidade
pessoal? Existem problemas de acesso a serem resolvidos -
segurança ou físico?
Quando é que a
implantação precisa ser
concluída?
A implantação precisa ser completada por uma determinada data e
hora ou pode ser concluída, seguindo um horário flexível?
Porque é que a
implantação aconteça?
É a implantação necessária para corrigir um problema ou é
necessário para algumas funcionalidades novas que foi solicitado, e
não os usuários a entender o que está vindo?
Quais são os fator
crítico de sucessos e
critérios de saída?
Como você vai saber que a implantação foi bem sucedida? Quem vai
autorizar a implantação? Como você vai saber quando a implantação
for concluída?
Qual é a corrente
capacidade do provedor
de serviços?
Quais são os atuais serviços, processos e Serviço de Gestão de
capacidade - capacidade, Aspectos financeiros, os actuais sistemas
e infra-estrutura?
Tabela 4.9 Perguntas a serem respondidas quando se planeja a implantação
Logística e planejamento de entrega
Uma vez que a abordagem geral de implantação é compreendido, desenvolver a
logística e entrega planos. Estes planos de lidar com aspectos como:
• Como e quando unidade de liberaçãos e serviço componentes será
entregue

• O que os prazos típicos são: o que acontece se houver um atraso
• Como acompanhar o andamento da entrega e obter a confirmação da
entrega
• Disponibilidade de armazenamento seguro, quando necessário
• Gerenciando costumes e outras implicações de distribuição internacional.
Bem como os aspectos de entrega, há logística geralmente conseqüentes a
tratar, por exemplo, desmantelamento e eliminação de itens redundantes,
incluindo software e licenças, hardware, habilidades, computador e alojamento
de pessoal, contratos de suporte (utilidade abastecimento, manutenção, limpeza,
etc.) Também pode haver uma necessidade de equipamentos temporária (por
exemplo, equipamento do balanço) ou software descartável que é necessário
para o transição.
Se os planos de transição exigir qualquer paralelo execução de serviços ou de
equipamento, isto é particularmente desgastante do ponto de vista da logística,
visto que instalações duplas são susceptíveis de ser necessário para um curto
período de tempo.
Uma vez que a logística e entrega planos foram determinados, eles precisam de
ser comunicados a todos das partes interessadass, incluindo a notificação formal
para as pessoas consultadas na determinação do plano.
Entrega não é suficiente; logística bem sucedida requer que os componentes
chegam e realizar, conforme necessário. Portanto desenvolvimento
planejamento para todos os itens despachados - hardware, software,
documentação e treinamento - irá abordar como os componentes são rastreados
e documentados na entrega. Isto deve incluir:
• Verificação contra uma lista definitiva de necessária serviço ativos e IDs
únicos componentes 'e versãos
• A nota de entrega detalhando os componentes a serem entregues,
incluindo IDs exclusivos, versões e quantidades
• O que deve haver (conteúdo lista para verificar contra)
• O que precisa estar lá para atendê-la, em termos de equipamentos, pré-
requisitos e co-requisitos
• Como garantir que ele está correto / de trabalho - o que as ferramentas,
parâmetros, mecanismos de feedback, critérios de aceitação devem ser
aplicados?
• Métricas para monitoramento e determinar o sucesso do liberar
implantação esforço.
Financeiro / comercial planejamento

Aspectos financeiros e comerciais terão de ser especificamente verificado antes
da implantação e atividades adicionado à implantação planeja se necessário.
Por exemplo:
• Capital de giro - Os fundos suficientes disponíveis para entregar as
expectativas dos clientes, por exemplo, para financiar mudanças iniciais
para ganhar aceitação emocional durante o desenvolvimento?
• Contratos e licenças - Ter todas as informações necessárias contrato e
licença transferências foi arranjado?
• Financiamento - Será o financiamento disponível para o apoiar sistemas
para gerir o serviço, E.g. CMS e as licenças relacionadas?
• Propriedade intelectual - Tem toda a gama de IP, a sua propriedade e
uso contínuo foi abordado, incluindo:
• Software desenvolvido por uma das partes
• Documentos tais como usuário manuais?
4.4.5.2 Preparação para construir, testar e implantação
Antes de autorizar a construir e teste fase, a Design de Serviços e a liberar
projeto deve ser validado contra o exigência para a oferta de serviços novos ou
alterados. Isso deve resultar em feedback construtivo sobre o Design de
Serviços. Record, acompanhar e medir os riscos e problemas contra os serviços,
serviço ativos e dentro do IC pacote de serviços, SLP, SDP ou pacote de
lançamento. Priorizar as questões e ações para garantir que eles podem ser
resolvidos de uma forma atempada. Por fim, produzir uma validação relatório e
os resultados associados prontos para o serviço avaliação.
Uma avaliação independente da serviço e design versão usa o relatório de
validação e resultados (ver 4.6.5). Essa avaliação verifica que a mudança para
os serviços ou oferta de serviços vai entregar o previsto resultados, isto é, o
serviço de espera pela usuário ou cliente. Se houver problemas, um relatório de
avaliação intercalar está preparado. Este relatório lista os desvios da SDP, um
risco perfil e recomendações para Gestão da Mudança. Se houver desvios no
exigência de nível de serviços, em seguida, o pacote de serviços, SAC ou SLP
pode ser alterada (por Gestão da Mudança) Ação e devem ser tomadas para
modificar a versão do serviço proposto e alterações relacionadas. A conclusão
bem sucedida da avaliação do Design de Serviços linha de base garante que o
serviço liberar construir e teste começa com um design estável baseline e
aprovado.
Para algumas versões do Transição de Serviço Gerente pode precisar para
classificar indivíduos ou estabelecer uma equipe de pessoas competentes para
executar os planos. Se os indivíduos não são dedicados há risco que possam
ser desviadas para trabalhar em outros projetos. Estes riscos precisam ser
mitigados como eles são muitas vezes a causa de atrasos.

Na maioria das vezes, a introdução de um serviço de tecnologia habilitado
requer treinamento para o lançamento, desenvolvimento, Construir e equipes de
testes. As necessidades de formação desses grupos vai estar em níveis
diferentes. O reconhecimento dos diferentes conjuntos de habilidades,
capacidades e competências, dentro dos vários grupos é um pré-requisito útil
para identificar a formação necessária. Na especificação do treinamento
programa, O número de pessoas que necessitam de formação tem de ser
determinada, e a maneira como o conhecimento pode ser fornecido necessita de
ser considerada. Embora a necessidade de formação difere de versão para
versão, o impacto de treinamento pode ser significativo. Por exemplo, se o
pessoal de apoio estão espalhados muitos locais, a formação específica, os
mecanismos automatizados, tais como a formação e-learning ou baseado em
computador (CBT) soluções através da internet ou intranet, pode tornar-se uma
proposta atraente.
Exemplos de necessidades de treinamento incluem:
• Interpretando o Design de Serviços documentação e planos
• Utilização de ferramentas de apoio, por exemplo, para o pessoal liberação
central
• Mudanças na saúde e segurança exigências
• Mudanças nas segurança políticas e procedimentos
• Formação técnica
• Serviço de Gestão de e processo formação, e.g. novo construir
procedimento para a nova item de configuração tipo.
4.4.5.3 construir e testar
Durante as fases de construção e de teste, os serviços comuns e de infra-
estrutura precisam ser administrados com cuidado, uma vez que pode afetar de
forma significativa a construção e teste de um serviço de tecnologia habilitada e
sua infra-estrutura de tecnologia subjacente. Aspectos fundamentais que
precisam ser gerenciados durante as atividades de construir e testar uma oferta
de serviço ou serviço são:
• Uso da compilação e ambiente de testes
• Aspectos relativos à normalização e integração
• Gestão das configurações:
• Durante as atividades de construção e teste, por exemplo, versão
controlar,linha de base controlo de gestão, de entradas e saídas de
um estágio de construção ou teste
• Gravando o completo registro da construção de modo que ele pode
ser reconstruído, se necessário
• Mantendo evidência de testes, por exemplo, resultados do teste e
relatório de ensaio

• Controlar o acesso direitos de física e tecnologia componentes, por
exemplo, parâmetros de ajuste
• Verificação de que segurança exigências sejam satisfeitas
• Verificação actividades, por exemplo, pré-requisitos sejam
atendidos antes de uma construção ou teste começa
• Gerenciando ambienteal, por exemplo, problemas medidas de
espaço, refrigeração, energia, precauções contra incêndio
acessibilidade e segurança
• Preparar e controlar o serviço liberar pronto para a promoção ao
próximo ambiente
• Promover ou entregar a versão do serviço para a próxima fase ou
equipe.
Linhas de base de configuração da controlada ambientes e do pacote de
liberação antes e após a instalação, construção ou desenvolvimento são
registados no CMS para fornecer uma restaurar ponto. As informações de
configuração também deve ser atualizado para refletir o recebimento e
implementação de um unidade de liberação ou o pacote de libertação total a um
grupo ou a implantação ambiente alvo. O definitivo versão do pacote de
lançamento (aprovado em serviço de teste de lançamento) deve ser colocado no
DML, mesmo quando o pacote de lançamento consiste apenas de
documentação para um upgrade de hardware. O pacote de lançamento deve ser
sempre retirado do DML para implantar na Operação de Serviços prontidão,
serviço de aceitação e ambientes vivos.
Solte e documentação de construção
Procedimentos, modelos e orientações devem ser usadas para permitir que a
equipe de liberação para tomar serviço ativos e produtos de interno e externo
fornecedors e construir um pacote de lançamento integrado de forma eficiente e
eficaz.
Procedimentos e documentos para a compra, distribuição, instalação,
movimentação e controle de ativos e componentes que são relevantes para a
aquisição, construção e teste de uma versão incluem:
• Contrato e acordos (por exemplo, para encomendar um novo
equipamento ou software)
• Pedidos de compra e ordenação
• Pedido cumprimento
• De entradas e de entrega
• Saúde e segurança diretrizs
• Segurança políticas e procedimentos
• Arrendamento acordos
• Propriedade intelectual direitos/ Direitos digitais
• Os contratos de suporte

• Procedimentos para:
• Gerenciamento de configurações de serviços e infra-estrutura
• Distribuição e instalação de software
• Distribuindo, tradução e conversão de dados e informações
• Entregar, instalação e equipamentos móveis
• Limpeza de dados e mídia
• Eliminação da documentação, meios e equipamentos
• Construção, comissionamento e descomissionamento ambiente de
testes, infra-estruturas e instalações
• Conhecimento de publicação de informações e dados
• Validação e teste
• Aceitação e autorização
• Documentar acordos de licença e títulos de licença, juntamente com
"prova de licença".
'Prova de licença "é o que um tribunal irá aceitar como prova de uma entidade
jurídica que tenha uma licença. Cada fabricante de software em geral, afirma o
exigências para a sua prova de licença, de modo que não há regras rígidas e
rápidas podem ser dadas aqui. Como princípio geral, prova de licença requer
alguma forma de evidências diretamente do fabricante do software. Há um
espectro de tipos de provas para ter uma prova de licença. Os exemplos típicos
incluem:
• Impressos licença documentos de confirmação de fabricantes de software
(com segurança recursos)
• Eletrônicos de licença documentos de confirmação de fabricantes de
software realizadas em sites de acesso controlada
• Certificados de Autenticidade (COA), que normalmente são gravadas, ou
com outros recursos de segurança. Estes podem ser peças soltas de
papel, pedaços de papel colados em capas de manuais, etiquetas
coladas em equipamentos, etiquetas impressas ou colados em caixas de
varejo.
A solução proposta deve ser documentado para permitir conhecimento adquirido
durante o construir e fases de teste para ser entregue ao Operação de Serviços
e Melhoria de Serviço Continuada deve ser mantida para o futuro liberars. É
importante que a informação seja ordenada e mantido de forma sistemática,
como durante a construção e atualizações de atividades de teste a
documentação será necessária. A documentação inclui:
• Processo descrições e procedimentos
• Suporte e manuais de operação, balcão de atendimento os scripts etc
• Transferência de comunicações, treinamento e conhecimento entregas

• Manuais de usuários com instrução de trabalhos
• Informações sobre o serviço
• Contexto de negócios e informações de marketing
• Catálogo de serviços,SLA e documentação de apoio:
• Informações de hardware e software
• Lógica e física visão geral da arquitetura
• Descrições técnicas detalhadas e referências
• Informações técnicas
• Serviço de Gestão de planos e operações
• Continuidade do negócio planejamento detalhes
• Índice de documentação para o serviço e liberar - Baseline.
Adquirir e testar itens de entrada de configuração e componentes
Item de configuraçãos e componentes (por exemplo, serviços serviço ativos) são
adquiridos a partir de projetos, fornecedors, parceiros e desenvolvimento grupos.
Para impedir a aquisição de componentes desconhecidos e potencialmente
arriscado para construir um é essencial para utilizar CIs que tenham atingido um
certo qualidade nível ou componentes de um catálogo de componentes padrão
que tenham sido previamente avaliados, testados e autorizados para uso em
condições específicas. Caso contrário, uma mudança terá de ser aumentada
para a avaliação do componente e, ou incorporando-o no padrãoO catálogo ou
aceitá-la como uma exceção única para esta versão.
As atividades de aquisição incluem:
• Interface com os processos de aquisição para adquirir os componentes
(ou com os departamentos internos de produção, se fornecido em casa)
• Captura e gravação:
• Novos ou atualizados ativos de serviços e da CEI no SACM
• Recebimento de componentes
• Mudança, entrega e documentação de liberação do fornecedor
• Verificação, monitoramento e relatar a qualidade de CIs de entrada e
serviço componentes
• A garantia de que a prova da licença pode ser demonstrado quando
necessário
• Iniciar uma ação se a qualidade é diferente de expectativa, e avaliar o
provável impacto deste sobre o transição
• Atualizando estado de item de configuraçãos em SACM, e.g. para indicar
que eles estão prontos para ser liberado para a próxima fase ou rejeitado.
Verificação atividades para verificar os componentes destinados a um pacote de
lançamento ou construir incluem:
• Estabelecendo que todos os itens são de boa-fé, e realmente foram
encomendados ou encomendado

• Convenções de nomenclatura padrão de etiquetagem e têm sido
aplicados como especificado na projeto especificaçãos para os
componentes da CEI e serviço
• Gravação de itens adquiridos externamente e verificar estes contra a sua
entrega e documentação de liberação
• Verificando que:
• Produtos desenvolvidos e componentes de serviços passaram com
sucesso apropriado documentado qualidade revers
• Todo o software é como o esperado e sem acréscimos maliciosos
estão incluídos (por exemplo, itens de software que podem conter
vírus)
• Todas as alterações ao anterior versãos ou configuração linha de
bases foram autorizadas pela Gestão da Mudança e outras
alterações não foram incluídos - o que pode exigir uma
configuração auditar e instalações de comparação para verificar
contra a configuração desejada
• Todos os itens definitivas foram adicionados ao DML e
corretamente registrado no CMS
• Rejeição / retorno dos componentes está devidamente controlado
e documentado.
Questões, não-conformidade, erro conhecidos relatórios e desvios sobre a
qualidade dos componentes de serviços e quaisquer riscos deve ser passado
para o relevante das partes interessadass, por exemplo, garantia de qualidade,
CSI, Design de Serviços.
Lançamento embalagem
Construir gestão procedimentos, metodologias, ferramentas e listas de
verificação deve ser aplicada para garantir que o liberar pacote é construído de
uma maneira padrão controlado e reproduzível, de acordo com o design da
solução definido na Pacote de Desenho de Serviço. Como um pacote de
lançamento progride para a produção ele pode precisar de ser reconstruído. Por
exemplo: se uma nova versão de um IC ou necessidades de componente a ser
incorporado rapidamente para corrigir erros, se a documentação precisa ser
atualizado.
As atividades-chave para construir um pacote de lançamento são:
• Montar e integrar o lançamento componentes, de uma forma controlada,
para assegurar uma reprodutível processo.
• Criar a compilação e documentação de liberação, incluindo:
• Construir, instalação e teste planos, procedimentos e scripts
• Detalhes de como monitorar e verificar a qualidade do lançamento
e como reconhecer e reagir a problemas

• Os processos automatizados ou manuais e procedimentos
necessários para distribuir, implantar e instalar a versão para o
alvo ambiente (Ou removê-lo se necessário)
• Procedimentos para sair unidade de liberaçãos ou remediar uma
mudar deve falhar um lançamento
• Procedimentos para controle e gerenciamento de licenças de
software e digitais direitos.
• Instalar e verificar o pacote de liberação.
• Linha de base o conteúdo do pacote de lançamento.
• Enviar uma notificação de serviço para informar as partes interessadas
que o pacote de lançamento está disponível para instalação e uso.
Se o teste de um pacote de lançamento for bem sucedido, o liberar e o conteúdo
do pacote de distribuição são colocadas sob o controlar de Gerenciamento da
Configuração, Linha de base e verificado contra o projeto de liberação e de
definição do pacote de liberação. A partir deste ponto, todas as alterações no
pacote de lançamento são gerenciados através Gestão da Mudança, E.g. para
corrigir um erro em testes. Se, em qualquer etapa, o teste de um pacote de
lançamento não for concluído com êxito, a reavaliação e renegociação da
liberação é gerido através de Gerenciamento de Mudanças.
Construir e gerenciar os ambientes de teste
Construção eficaz e ambiente de teste gestão é essencial para garantir que o e
compilações testes são executadas de forma repetível e administrável. Controle
inadequado desses ambientes significa que mudanças não planejadas podem
comprometer as atividades de teste e / ou causar significativa re-trabalho.
Dedicado construir ambientes devem ser estabelecidos para a montagem e
construção do componentes para o ensaio controlado e desenvolvimento
ambientes.
Preparação de ambientes de teste inclui a construção, alterar ou melhorar os
ambientes de teste prontos para receber o lançamento.
Um De serviços de TI é, na maioria das ocasiões, construído a partir de uma
série de tecnologias recursos ou de gestão ativoss. Na fase de construção, estes
blocos diferentes, muitas vezes a partir de diferentes fornecedors, são instalados
e configurados em conjunto para criar a solução como projetado.
Standardization facilita a integração dos diferentes blocos de construção para
proporcionar uma solução de trabalho e do serviço.
Automatizar a instalação de sistemas e aplicação software em servidors
estações de trabalho e reduz as dependências nas pessoas e agiliza o
procedimentos. Dependendo da versão e implantação planos, a instalação pode
ser efectuada antecipadamente (por exemplo, se o equipamento está a ser
substituído), ou pode ter de ocorrer in situ na viver ambiente.

Os físicos elementos de infra-estrutura, em conjunto com o ambiente em que
eles vão operar, Precisam ser testados de forma apropriada. Parte dos ensaios
podem ser para testar a replicação da solução a partir de uma infra-estrutura
ambiente para a outra. Isso dá uma maior garantia de que o lançamento para o
ambiente de produção será bem sucedida.
Ambiente de testes deve ser mantido ativamente e protegido utilizando Serviço
de Gestão de melhores práticas. Para qualquer mudança significativa para a
serviço, A pergunta deve ser feita (como o é para a continuidade da relevância
de continuidade e plano de capacidades): "Se esta mudança se concretize, será
necessário que haja uma mudança como consequência de os dados de teste?"
Durante o construir e atividades de ensaio, operações e equipes de apoio devem
ser plenamente informados e envolvidos como a solução é construído para
facilitar uma transferência estruturada a partir da projeto para a equipe de
operações.
4.4.5.4 Serviço de testes e pilotos
As atividades são coordenadas através de testes de gerenciamento de testes,
que planeja e controla a execução de testes que é descrito na seção 4.5. Teste
tem como objetivo construir confiança no serviço capacidade prévio para a final
aceitação durante piloto ou apoio início da vida. Será com base no teste
estratégia e modelo para o serviço sendo alterado.
Os critérios de teste refletem as condições previstas no qual o serviço está
prevista para operar e entregar benefício. No entanto, estas circunstâncias
podem mudar, e em muitas situações modernas tal mudança é quase inevitável
e muitas vezes imprevisível. Estas alterações e suas impacto em testes de
serviço e aceitação deve ser observado, entendido e documentado. Suas
conseqüências precisam ser expressas em termos de critérios de aceitação
alterados e atualizações do pacote de serviços, Incluindo o SLP. Este será
necessária a colaboração ea entrada do negócio, Clientes e outros afetada das
partes interessadass, o que pode incluir fornecedores e operações. O Design de
Serviçoser estará envolvido em proceder a quaisquer alterações uma vez que
este conhecimento pode ajudar na construção de uma flexibilidade adicional e
relevante para futuros projetos de serviços novos ou alterados.

Figura 4.22 Exemplo de teste de serviço através de Transição de Serviço
Um exemplo de testes que podem ser executados durante liberar e
desenvolvimento é mostrada na Figura 4.22. Mais detalhes sobre estes testes
são descritos na seção 4.5 no validação e testes. Na prática, os tipos de teste se
sobrepor aos diferentes níveis de teste para fornecer uma gama completa de
testar todo o tempo de vida útil.
Aserviço teste controlos de libertação que o serviço componentes pode ser
integrado de forma correcta e que a libertação pode ser instalado, construído e
testado no ambiente alvo.
Operação de Serviços testes de prontidão garante que um serviço e seu
subjacente aplicação e infra-estrutura de tecnologia pode ser transferida para o
ambiente de produção de uma maneira controlada. Ele fornece um nível de
confiança de que o serviço novo ou alterado irá fornecer o nível de serviço
especificado no serviço exigências e exigência de nível de serviços. No entanto,

é muito cedo para finalizar o SLA neste ponto. O SLA é finalizado no piloto ou
mais geralmente em suporte de vida cedo, antes do Transição de Serviço é
fechado. O serviço operacional teste de prontidão visa:
• Determinar se um serviço e sua subjacente serviço ativos pode ser
liberada no ambiente de produção, pela primeira vez e para
implementações posteriores
• Garantir que o processo de negócioes, clientes, usuários e interfaces do
provedor de serviço (SPI) são capazes de usar o serviço corretamente
• Garantir que as equipes de serviço são capazes de operar o serviço e
usando o Serviço de Gestão de sistemas adequadamente.
Os testes que são realizados como parte do serviço operacional prontidão de
teste incluem:
• Desenvolvimento teste de prontidão - Para assegurar que os processos
de implantação, procedimentos e os sistemas podem implementar,
instalar, comissão e encerrar o pacote de lançamento e consequente
novo ou alterado serviço na produção / implantação ambiente
• Serviço de teste de Gestão - Para assegurar que o serviço atuação
podem ser medidos, monitorados e relatados na produção
• Operação de Serviços teste - Para assegurar que as equipas de serviço
poderá operar o serviço em produção
• Nível de serviço teste - Para garantir que o serviço novo ou alterado vai
entregar o exigência de nível de serviços
• Teste de usuário - Garantir que os usuários podem acessar e usar o
serviço novo ou alterado, por exemplo, eles têm acesso à actualização
catálogo de serviços e informação de contato do balcão de atendimento
• Interface do provedor de serviço teste - Assegurar que as interfaces
para o serviço estão trabalhando
• Desenvolvimento verificação teste - Para assegurar que o serviço
capacidade foi corretamente implantado para cada alvo desenvolvimento
grupo ou ambiente.
Ensaios de serviços
Um método de teste consiste em simular tanto quanto do serviço possível, em
um ensaio de serviço (por vezes referido como "escritório modelo"). Um ensaio
serviço é uma simulação de como a maior parte do serviço como possível em
uma sessão de prática extensiva e amplamente participativo. É o estágio final de
testes internos, o último estágio antes de qualquer público vivem correndo. Isto é
como um 'ensaio geral' de um jogo, definindo todos os elementos - figurino,
iluminação, etc - em uma privada última executado através da performance. Ele
pode proporcionar benefícios significativos ao estabelecer erros e impraticável
procedimentos antes que eles afetem os negócios em viver operação. No
entanto, eles são o tempo, complexo e demorado relativamente caros de

preparar, e entregar documento. Um equilíbrio cuidadoso e deliberado é,
portanto, necessária entre os custos previstos e os risco danos perfil que
poderiam impedir.
Um ensaio serviço ocorre apenas antes da implantação do serviço, se realizada
muito cedo, há uma chance significativa de que o meio ambiente, tecnologia,
pessoas e legislação em que o serviço está sendo liberado vai mudar e invalidar
os resultados. Se for muito perto do declarado liberar agora os problemas
encontrados não serão tratadas antes de o serviço entrar no ar.
O objetivos do ensaio serviço incluem:
• Confirmação de que todos das partes interessadass foram identificados e
estão empenhados em operar ou usar os serviço - Se não isso será
evidenciado por falta de jogadores para os papéis dentro do ensaio de
serviço
• Garantir que todos os interessados têm processos e procedimentos em
vigor e está pronto para receber processo e resolver incidentes,
problemas e alterações relacionadas com o serviço novo ou alterado
• Testando o eficácia de 'erro-proofing' incluído dentro dos procedimentos
de serviço. (À prova de erros, muitas vezes referido por "jugo Poca" o
termo japonês, é sobre a introdução de avisos antecipados de usuário
erros ou maus prática e sempre que possível a introdução de etapas nos
procedimentos para evitar esses erros -., como intertravamentos
interruptor elétrico, e verifique soma-dígitos na entrada de dados),
enquanto os testes podem verificar como reage um serviço de erro do
usuário previsto, o ensaio serviço irá encorajar um comportamento
imprevisível e estabelecer como esse comportamento afeta a capacidade
do serviço para oferecer os benefícios requeridos.
O ensaio serviço requer uma representação adequada de todos os interessados,
com o compromisso de fornecer pessoal para - normalmente - um ensaio de dia
inteiro para um serviço novo ou significativamente alterado. É sempre benéfico
para envolver "comuns" representantes da comunidade de interessados, e não
aqueles com experiência anterior ou conhecimento do serviço. Erros típicos
serão mais susceptíveis de vir de usuários típicos - aqueles que estiveram
envolvidos em projeto e desenvolvimento vai achar que é impossível
'desaprender' e será colorida por suas expectativas de comportamento de
serviço.
O foco de um ensaio serviço é normalmente em um dia de ensaio real, mas
entrega bem sucedida de um ensaio serviço envolve mais etapas, incluindo a
preparação e análise, espelhando o Plan-Do-Check-Act ciclo. Estágios típicos de
um ensaio de serviço que incluem as seguintes atividades.
Plano - preparar para o dia

Pedido de um ensaio serviço - o projeto ou equipes de implementação de
serviços de considerar que um ensaio serviço seria apropriado e desencadear o
processo com uma solicitação.
As tarefas incluem o seguinte:
• Nomear um gestor ensaio que reúne todas as informações relevantes.
• Identificar os principais processos e secundário.
• Identificar todos das partes interessadass e suas informações de contato.
• Produzir guia ensaio inicial - o roteiro a ser seguido.
• Estabelecer e documentar exemplos típicos de incidentes, solicitações de
serviços, capacidade e disponibilidade questões e outras eventos que
precisam ser manipulados, quando o serviço é viver.
• Produzir documentação para permitir a simulação, processamento,
acompanhamento e análise dos cenários esperados.
• Identificar todos das partes interessadass, fornecedor e provedor de
serviços pessoal que precisam estar envolvidos e garantir o seu
compromisso, através de financiamento direto, o compromisso interno etc
• Criar scripts detalhados - em colaboração com cliente ou gerente de
contas.
• Convidamos todos os interessados a planejamento e reuniões de
preparação e briefings (pode ser por documentação, e-mail, etc Webinars
se briefings físicos não são praticáveis.)
Não - entregar o ensaio
Realização de reuniões para:
• Introduzir o objetivos, documentos, etc envolvimento de gravação,
• Passo a passo os cenários e scripts para estabelecer a autenticidade da
abordagem em um nível detalhado
• Realizar o ensaio, ou seja, deixar os jogadores entregar o script e
observar o processamento de eventos e elementos-chave, por exemplo,
seguir um incidente através da ocorrência de loggings,
diagnóstico,resolução,recuperação e fecho.
Check - documentar o dia
As tarefas incluem:
• Analisar e avaliar os resultados do ensaio e determinar as implicações
• Produzir um relatório de ensaio escrito sobre o ensaio, com
recomendações, por exemplo, re-trabalhar o serviço antes
desenvolvimento
• Gravação identificado erros, problemas e riscos.

Agir - agir seguindo o ensaio
Considerando os resultados do ensaio, as opções serão:
• Declare serviço ter passado sem preocupação.
• Ou considerar que o serviço não é adequado para avançar nesta fase e
remeter para Design de Serviços e / ou Transição de Serviço para o re-
trabalho e reescalonamento. (Ocasionalmente, pode ser que a repetição
de serviços mostra que o ambiente real em que o serviço está prevista
para a função é diferente o suficiente de expectativa de prevenir o
comportamento aceitável do serviço na realidade - isto pode exigir
repensar e revisão no Estratégia de Serviço e / ou processo de negócio
nível.)
• Analisar e fechar a serviço ensaio, fornecendo idéias de melhoria para
CSI,SD e administração de ST, conforme apropriado.
Pilotos
Prosseguindo a analogia teatral visto no ensaio de serviço, se o ensaio de
serviço é o 'ensaio geral' - o último treino antes de ser vista pelo público -, então
o piloto é o "off Broadway" de execução de um jogo. Ele é feito para o público
real e em, mas para um público pequeno e apenas com a expectativa de
polimento (espero menor) adicional do atuação, Cenário roteiro e efeitos.
Realização de um piloto é mais fácil controlar como ele é implantado em um
menor ambiente/usuário base.
Um piloto estabelece para detectar se algum elemento do serviço não
produzirem os resultados necessários e identificar as lacunas / questões em
Serviço de Gestão de que colocou o serviço e / ou o negócio do cliente e ativoss
em risco. Ele não necessita de abranger todos os serviços e sistema
funcionalidade, mas incidirá sobre as áreas de risco e executar o suficiente do
serviço para determinar se ele vai funcionar suficientemente bem na
implantação. O objectivo é garantir que o serviço capacidade suporta a
prestação do serviço exigências e exigência de nível de serviços. Na medida do
possível, deve verificar se os utilitários de serviços são apto para o efeito e as
garantias estão aptos para uso.
Estabelecer critérios claros objetivos para a implementação piloto, tais como:
• Para estabelecer métricas e fornecer a confiança de que o desempenho
do previsto e nível de serviços serão atendidas
• Para avaliar os benefícios e os custos reais obtidos durante o piloto
contra o Business Case
• Para criar aceitação de novos processos e formas de trabalho dentro da
base de usuários, provedor de serviços e fornecedors

• Para identificar, avaliar e mitigar alguns dos riscos associados com uma
implantação completa.
Como não é provável que sejam projeto mudanças e melhorias que precisam
ser incorporadas ao liberar antes completa desenvolvimento, É importante
acordar a forma como estes serão financiados na frente. Também é importante
para assegurar que não há um consenso sobre a forma como o piloto
implementação será assinado.
Durante o piloto da equipe de lançamento e implantação deve:
• Esteja pronto para invocar contingência /recuperação procedimentos
• Envolver as pessoas-chave que serão envolvidos na implantação
completa
• Garantir que as pessoas envolvidas no piloto são treinados e que eles
entendam seu novo / alterado papel e responsabilidades
• Documento necessário operacional e procedimentos de apoio,
informações e materiais de formação que não podem ser adequadamente
simulada em um ambiente de teste
• Estabelecer a viabilidade de documentação, formação e apoio e
modificar, se necessário
• Estabelecer usuário do cliente, e das partes interessadas a interacção
com o serviço em tempo real das situações, por exemplo, com real
negócio decisões a serem tomadas
• Capturar métricas apropriadas a fim de comparar com o serviço atuação
modelo
• Estabelecer critérios adicionais que precisam ser satisfeitas antes de
plena implantação começa
• Determinar o nível provável de serviços de apoio e Serviço de Gestão de
recursos que serão necessários e resolver quaisquer problemas
• Descobrir e corrigir problemas e erroé cedo e corrigir muitos deles antes
da implementação final. Isto inclui as irritações menos críticos menores e
excentricidades de um serviço que não necessariamente causar a não
aceitação mas não reduzir significativamente a aceitação emocional do
serviço entre a comunidade de usuários
• Melhorias de documentos e, se necessário incorporá-las em planos para
a implantação completa.
Quando a libertação tem sido usado por um período suficiente durante um piloto,
é importante verificar que o serviço é capaz de satisfazer os requisitos do
cliente, usuário e a Design de Serviços bem como o predito resultados (embora
nem todos estes irão ser realizado, neste ponto).
Se o piloto tem um comprimento suficiente, poderá ser adequado realizar uma
avaliação independente de comparar a actual vs previu serviço capacidade e
desempenho (especificado no Desenho de Serviço) em nome da das partes

interessadass, usuários e clientes. Este avaliação inclui um avaliação de risco se
o serviço vai continuar a oferecer o serviço exigências, por exemplo, nível de
serviços e garantias.
As saídas de uma entregue com sucesso serviço piloto incluirá:
• Novo serviço ou alterados e capacidade que tenham sido testados e
avaliados
• Relatório de piloto de testes e resultados
• Um relatório gerado pela avaliação função, Que é passado para Alterar
Gestão e que compreende: uma actualização risco perfil, o relatório
desvios recomendação,
• Chave das partes interessadas acordo que o lançamento está pronto para
uma implantação completa
• Benefícios demonstrados do serviço (dentro dos níveis de tolerância
acordados)
• Confirmação de que o desenvolvimento equipe testou a implantação
processo e aceita a custar modelo, Modelo de implantação e métricas a
serem utilizados para a monitoramento durante a implantação e apoio
início da vida
• Grupos-alvo de implantação em diferentes localizações geográficas
aceitar o serviço liberar e comprometendo-se a implantação planos, em
particular grupos com diferentes culturas e idiomas.
4.4.5.5 Planejar e preparar a implantação
O planejamento e atividades de preparação de preparar o grupo de implantação
para implantação. Isto constitui uma oportunidade para preparar o organização e
pessoas para organizacional mudar, Ver seção 5.2. A abordagem global para o
planejamento da implantação é descrito no planejamento de liberação e
implantação (ver parágrafo 4.4.5.1). Durante a fase de implantação real a
implementação detalhada plano é desenvolvido. Isto inclui pessoas atribuindo a
atividades específicas. Por exemplo, um indivíduo específico pode ser atribuído
a oferecer treinamento para um treinamento atividade sobre o plano de
implantação.
Os critérios de entrada para planejar e preparar um grupo de implantação de
destino ou ambiente incluem:
• Desenvolvimento das partes interessadass são suficientemente confiante
na liberação do serviço para implantar o liberar, Possuir seus aspectos de
implementação e eles estão comprometidos com a implementação (ver
secção 5.2).
• A gerência sênior, os clientes, os negócios e provedor de serviços
equipes de aceitar os custos de implantação, gestão, organização e

pessoas implicações da liberação, bem como em qualquer organização,
função e processo mudanças.
Um exemplo das atividades de implantação que se aplicam à implantação de um
grupo alvo é mostrada na Figura 4.23.
Figura 4.23 Exemplo de um conjunto de atividades de implantação
Preparando-se para desenvolvimento inclui a avaliação de prontidão cada grupo
de implantação de receber e implementar um pacote de lançamento, a
identificação de lacunas que precisam ser preenchidas e planejamento das
atividades necessárias para implantar, transferir ou de-comissão /aposentar
serviços ou serviço ativos. Ele também irá incluir a transferência de um serviço

ou de uma unidade de serviço, bem como atividades de movimentação e
disposição.
Avaliação
Embora a implantação avaliação devem ser realizados no início, ela deve ser
revisto periodicamente. Os resultados desta avaliação são alimentados em
planejamento de implementação detalhado para o grupo de implantação de
destino.
A avaliação de prontidão para um grupo de implantação identifica:
• Problemas e riscos em entregar os serviços atuais que podem afetar a
implantação. Os tipos de risco incluem:
• Falta de internos dedicados recursos e externa fornecedor
recursos
• A falta de formação, competências e sensibilização
• Mudança não planejada ou no final exigências
• Antecipado impactos, por exemplo, sobre a estrutura organizacional,
ambiente para os serviços novos ou modificados, clientes diretos e
usuários, parceiros, fornecedores
• Lacunas que precisam ser preenchidas.
Os aspectos para avaliar incluem:
• Aspectos financeiros e ativos:
• Atual e necessário capital de giro
• Estabelecer novos ou alterados contratos, licenças, direitos de
propriedade intelectual e digital direitos
• Problemas e riscos em entregar os serviços atuais que podem afetar a
desenvolvimento
• Aplicável de saúde, segurança, segurança e regulamentos ambientais,
fornecedor e aspectos relativos aos contratos
• Atual capacidade do empresa clientes e usuários de usar e ganhar o valor
do serviço novo ou alterado
• Serviço corrente, capacidade de serviço e recursos utilizados, incluindo:
• Estrutura de serviço
• Serviço dinâmica
• Métricas de serviço e relatórios, incluindo garantias e nível de
serviços alcançado
• Atual Serviço de Gestão de capacidade e recursos:
• Diferenças dos pré-requisitos para a implantação, por exemplo,
inadequados acordos de licenciamento, largura de banda de rede
• As operações atuais e recursos de apoio, por exemplo,
ferramentas, pessoas

• Recursos de apoio e carga de trabalhos como pode haver um
aumento significativo no número de incidentes por usuário que se
pode esticar os recursos para o gerenciamento de incidentes,
problemas e correções
• Atuação relatórios e planos de melhoria
• Capacidade de prever e controlar o real incidente e problema
volumes durante a implantação, o que pode exigir atualização de
ativos ou usuário registros com a data e hora da instalação ou
implantação para permitir análise de tendências
• Identificar os requisitos para adequar o serviço novo ou alterado ou
solução de base, por exemplo, processos, procedimentos, instrução de
trabalhos
• Prontidão organizacional:
• Papel, Recursos e habilidades análise de lacunas
• Necessidades de formação análise
• Capacidade de atribuir indivíduos competentes para as funções
necessárias
• Motivação e capacitação - faz o atual organização e cultura
incentivar a aplicação das habilidades necessárias? Existe a
liderança certa e compromisso?
• Avaliar a disponibilidade de clientes, usuários, provedor de
serviços pessoal e outras das partes interessadass, tais como
fornecedores, parceiros
• Aspectos relacionados com a aplicaçãos, informações e dados:
• O acesso a informações e aplicativos e dados
• Acessando secretos, documentos restritos ou confidenciais e
dados
• Conhecimento e experiência no uso do aplicativo - os usuários e
pessoal de apoio
• Infra-estrutura e instalações:
• Difícil acesso, por exemplo, localizado no alto de um prédio sem
equipamento de elevação adequado (elevador ou guindaste, etc);
centro da cidade, com estacionamento restrito; locais remotos
• Intermédia e final e lojas de hardware definitivo e mídia
• IT espaço e equipamento capacidade exigências, tais como:
• pegadas de tamanho e equipamentos
• requisitos de energia e disjuntor classificações
• fonte de alimentação ininterrupta (UPS) e gerador de cargas
• requisitos de temperatura e umidade
• saídas de calor e ar condicionado requisitos
• desembaraço porta e requisitos de acesso de engenharia
• exigências de cabeamento
• Interferência eletromagnética (EMI) e interferência de rádio
freqüência (RFI) requisitos
• Ar qualidade requisitos
• Peso e cargas no chão falsos

• Considerações de rede
• Equipamentos de saúde, segurança, segurança e exigências
ambientais.
Desenvolver planos e se preparar para a implantação
Planejamento para um dado desenvolvimento inclui a atribuição específica
recursos para efectuar a implantação e apoio início da vida actividades. Ao
desenvolver estes planos, identificar e avaliar os riscos específicos para este
grupo de implantação usando o serviço modelo para identificar negócios e
serviço crítico ativoss que têm a mais alta risco de causar perturbação. As
atividades incluem:
• Planos de mitigação de risco
• Desenvolver transferência /transição, De atualização, de conversão, de
eliminação, planos de aposentadoria
• Logística e planejamento de entrega:
• O serviço ativos e componentes para a implantação,
estabelecendo como e quando será entregue, confirmação e que a
entrega foi alcançado com sucesso e registrado
• A preparação do local, de acordo com a saúde aplicável,
segurança, segurança e regulamentos e exigências ambientais
• Processos de alfaiataria, procedimentos e conhecimento, por exemplo,
quadro ajustes de conversão da linguagem, tempo
• Transferência de conhecimento e de formação das partes interessadass
em como usar, beneficiar, gerenciar, apoio e operar o serviço novo ou
alterado:
• Identificar os beneficiários essenciais e potencial de treinamento
(tais como clientes, usuários, ITSM, balcão de atendimento,
Suporte, operações, equipes de implantação, projetos)
• Atualização de service desk com conhecimento do grupo de
implantação de destino e sua ambiente
• Comunicar às pessoas envolvidas:
• Sobre as mudanças e os benefícios esperados
• Como a alteração afeta o organização e pessoal
• Fazer alterações em situações de emergência de continuidade planos e
procedimentos
• Mobilizar a Operação de Serviços organização e apoio
• Mobilizar os usuários para estar pronto para usar o serviço
• As actividades adicionais identificados a partir da avaliação.
O próximo passo é verificar os planos de implantação detalhados, realizar
quaisquer testes de preparação de implantação e levantar uma RFC para ser
autorizado através da Gestão da Mudança processo. O serviço está pronto para
implantação.

4.4.5.6 transferência executar a implantação e reforma
As atividades a seguir fornecem um exemplo dos diferentes aspectos que serão
executadas na ordem especificada no plano de implantação.
Transferir activos financeiros
Alterações e transferências de ativos financeiros devem ser concluídas como
parte da implantação. Isto incluirá, mas não está limitado pelo seguinte:
• Quaisquer mudanças em fornecedor financeiro acordos e encargos
• Adquirir ou transmitir de apoio anual e custos de manutenção, incluindo
sistemas para administrar o serviço, por exemplo, CMS
• Novos custos de licença e renovações
• Desastre anual recuperação contratos com terceiros
• Disposição ou transferência de capital de giro
• Transferência de propriedade intelectual.
Transferência / transição e de organização empresarial
Transferência de um unidade de negócios,serviço ou a unidade de serviço
envolverá mudar ao organização si. O tema da mudança organizacional é
abordada no capítulo 5. Atividades que precisam ser executadas incluem:
• Finalize organização, estrutura, funções e responsabilidades.
• Comunicar mudança na organização, funções e responsabilidades.
• Garantir que as pessoas se adaptar e adotar novas práticas. Isto requer
uma boa comunicação das conseqüências e exigências do serviço
implantado, por exemplo, melhor uso de recursos para entregar a
mensagem; preocupações compreensão pessoais e de grupo, e
garantindo mensagens para grupos diversos e relacionados são
consistentes e apropriadas.
• Gerar, no mínimo, aceitação e preferência apoio activo das mudanças
impostas sobre as pessoas.
• Garantir que as pessoas entendam a continuidade planos e
procedimentos.
Quando a mudança inclui uma transferência de provedor de serviços, E.g. novo
terceirização,insourcing, Mudança de provedor terceirizado, então alguns
elementos específicos precisam ser considerados, por exemplo, mudança
organizacional, ganhos rápidos para evitar confusão e maior reviravolta pessoal.
Pessoas competentes com as competências adequadas são necessários para
executar o desenvolvimento,operar e gerenciar o serviço novo ou alterado no
negócio,cliente e organização de prestação de serviço. As atividades
relacionadas incluem:

• Recrutar pessoal com competências adequadas. Ao invés de desenvolver
novas habilidades para o pessoal existente, pode ser mais eficiente para
recrutar novos funcionários que já têm as habilidades necessárias. Isso
pode ser, além de pessoal existente, ou pode exigir a substituição de
alguns funcionários com habilidades inadequadas, com mais pessoal
relevante para as circunstâncias revistas do novo serviço.
• Identificar as pessoas existentes (por exemplo, pessoal, fornecedors, os
usuários) com competências adequadas, móveis ou re-alocação de
pessoas, se necessário. Para as habilidades necessárias para realmente
implantar o serviço novo ou alterado, destacamento temporário, ou
mesmo horas extras, pode ser a abordagem mais eficiente.
• Considere terceirizar /contrato recursos para fornecer as competências
necessárias. Isto é semelhante ao do envio de pessoal interno, mas neste
caso de comprar as habilidades necessárias temporariamente de
fornecedores externos onde já existam. Se as habilidades são
necessárias a longo prazo, um requisito para passar essas habilidades
para o pessoal (ou a longo prazo) permanente pode ser útil.
• Fornecer treinamento. Gerenciar a logística de treinamento, coordenação,
configuração, comunicação, registro e entrega avaliação atividades,
incluindo usuários e Operação de ServiçoS equipas.
• Executar o plano de transferência de conhecimento e acompanhar o
progresso para a conclusão.
• Avaliar a competência dos funcionários novos e modificados e outras
pessoas.
Implantar processos e materiais
Implantar ou publicar os processos e materiais prontos para as pessoas
envolvidas na mudança organização empresarial e de serviços, por exemplo,
usuários e as equipes de operações de serviço que necessitam para executar os
processos novos ou alterados. Os materiais podem incluir políticas, processos,
procedimentos, manuais, resumos, produtos de treinamento, produtos de
mudança organizacional etc
Treinamento de pessoas para usar novos processos e procedimentos pode levar
algum tempo, principalmente para um mundial desenvolvimento para milhares
de pessoas.
Implantar capacidade de gerenciamento de serviços
Implantar processos novos ou alterados, sistemas e ferramentas para o
provedor de serviços equipes responsáveis pela Serviço de Gestão de
actividades. Verifique que todos são competentes e confiantes para operar,
Manter e gerir o serviço de acordo com o serviço modelo e processos. Remover
ou serviços redundantes de arquivos e ativos, por exemplo, processos,
procedimentos e ferramentas.

Durante a implantação monitorar o serviço contra o modelo de serviço e atuação
padrãos, tanto quanto possível.
Serviço de transferência
Transferir uma serviço envolverá também a mudança organizacional descrito
anteriormente nesta seção. As questões em torno da transferência de um
serviço e as atividades que precisam ser executadas incluem:
• Revendo os serviços de desempenho, problemas e riscos, através da
realização de algum serviço testes e uma avaliação do serviço antes da
transferência
• Auditoria de configuração serviço ativos e configurações
• Finalizando catálogo de serviços (Adicionar ou remover o serviço) e
informações relacionadas
• O envio de uma notificação de serviço para comunicar a mudança
relevante das partes interessadass.
Quando a mudança inclui uma transferência de fornecedor de serviços, por
exemplo, novo terceirização,insourcing, Mudança de provedor terceirizado,
então alguns elementos específicos precisam ser considerados, que incluem:
• Gerenciando alterações contratuais
• Gerenciamento das mudanças feitas existentes acordos
• Atualizando detalhes do contrato e informações nos SKMS
• Transferência de propriedade de bens e serviços item de configuraçãos,
lembrando-se de atualizar o CMS.
Implantar serviço
Implantar o lançamento do serviço e realizar as atividades para distribuir e
instalar o serviço, serviços de apoio, aplicaçãos, dados, informações,
infraestrutura e instalações. Estas incluem:
• Distribuição e entrega do serviço e do serviço componentes no local e
hora correta
• Construir, instalar e configurar os serviços e componentes de serviço com
todos os dados convertidos ou novo e informações
• Testando o sistema e os serviços de acordo com a instalação e aceitação
testes e relatórios que produzem a instalação e teste
• Gravar qualquer incidentes, inesperado eventos, problemas ou desvios
dos planos
• Corrigir eventuais desvios que estão fora do projeto limitações e
restrições.
Aposentadoria desmantelamento e serviço

Alguns aspectos específicos precisam ser considerados para se aposentar
desmantelamento e serviços e bens de serviço. Por exemplo, a procedimentos
para se aposentar, a transferência (por exemplo, para outro orçamento titular) ou
reinstalação serviço ativos precisa levar em conta qualquer
segurança,confidencialidade, Licenciamento ambiental ou outras exigências
contratuais. Isto inclui:
• Remoção de cópias de software implantados e dados de aposentard
hardware; falha em fazer isso pode resultar em violação da licença ou em
equipe utilizando software não suportado
• Identificar licenças e outros ativos que podem ser reimplantados; software
que está sendo retirado do uso em uma área bem pode permanecer em
uso em outros lugares
• Eliminação de equipamentos de acordo com as políticas e procedimentos
ambientais
• Movendo ativos que podem ser realocados para proteger áreas de
armazenamento, se necessário. Se os ativos que estão sendo
aposentados estão permanecendo em uso em outros lugares,
especialmente para hardware, os ativos liberados podem desempenhar
um papel útil como equipamento de reposição para ser mantido em lojas
de ativos para readaptação rápida no evento de falhas.
Registros de transferência de aposentadoria, e eliminação deve ser mantido e
utilizado para atualizar outras informações, tais como informações sobre licença.
Remover os ativos redundantes
Uma compreensão abrangente dos ativos usados por um serviço aposentado
precisa ser adquirida e gerenciado. Com uma compreensão completa quaisquer
ativos redundantes podem ser identificados e removidos, portanto,
potencialmente economizando taxas de licença, liberando capacidade e
prevenção de uso acidental. A incapacidade de desenvolver e executar
corretamente estas atividades pode resultar em:
• Espaço em disco desperdiçado e licenças
• Pagamento indevido de taxas de licença e manutenção
• Remoção de ativos associados com o serviço redundante, mas também
usado por outros serviços, causando, portanto, incidentes dentro desses
serviços, por exemplo, software comum componentes e os elementos da
rede.
Como parte das atividades de limpeza é importante para eliminar ou arquivo de
dados redundantes, informações e registros relacionados com o serviço anterior
ou produtos. O pleno escopo e escala de um ativo de serviço ou de serviço
precisa ser considerado, e isso deve se estender para as seguintes áreas:

• Apoiar contratos com terceiro fornecedors, como mudanças no uso
provável pode exigir renegociação de contratos.
• Na casa do segundo / terceiro nível pessoal de apoio com conhecimentos
específicos deixará de poder exigir que o conhecimento. Isso pode exigir
uma reavaliação de sua papel, O nível de retenção de pagamento, etc, e
as oportunidades para a reorganização pode ser identificado.
• Balcão de atendimento carga de trabalho pode ser afetada.
• Registros dentro do base de conhecimento relativa à descomissionado
componentes pode ter de ser arquivados e excluídos.
4.4.5.7 Verifique implantação
Quando o desenvolvimento actividades estão completas, é importante verificar
que usuários, Operação de Serviços pessoal, e outro das partes interessadass
são capazes de usar ou operar o serviço. Os testes devem ser especificamente
verificar que:
• O serviço, serviço ativos e serviço capacidade/recursos estão no lugar,
por exemplo, através da realização de um auditar tal como uma auditoria
de configuração do implantado linha de base contra a linha de base como
planeado
• Atualizações para documentação e informação são concluídas, por
exemplo, catálogo de serviços, contratos, acordos, detalhes do contato
• Materiais de comunicação, orientação e aprendizado está pronto para
distribuir aos stakeholders, operações de serviço e usuários
• Todos os papéis são atribuídos a pessoas / organizações
• Pessoas e outros recursos estão preparados para operar e usar o serviço
novo ou alterado ou capacidade de serviço em situações de emergência,
normal e desastres
• As pessoas têm acesso às informações necessárias para usar, operar ou
apoiar o serviço
• A medição e comunicação sistemas são estabelecidos para medir
atuação do serviço e os recursos subjacentes.
Este é um bom ponto para obter feedback sobre a implantação processo para
alimentar futuras melhorias, como por exemplo através de inquéritos de
satisfação.
Relatar quaisquer problemas e incidentes e tomar ações corretivas quando
necessário.
Confirmação de sucesso da implantação verificação desencadeia o início e
lançamento de suporte de vida para o grupo no início da implantação.
4.4.5.8 apoio Início da vida

Apoio início da vida (ELS) oferece a oportunidade de transição o serviço novo ou
alterado para Operações de Serviço de forma controlada e estabelecer o novo
serviço capacidade e recursos. Um exemplo da actividade ELS é mostrado na
Figura 4.24.
Figura 4.24 Exemplo de atividades de apoio início da vida
Em Design de Serviços, As partes interessadas terão concordado a entrada e
saída de critérios apoio início da vida mas pode ser necessário para finalizar o
atuação metas e critérios de saída precoce nesta fase. Isso pode ajudar a
entender o desenvolvimento processo de verificação e cliente set e das partes
interessadas expectativas sobre a entrega do serviço para Operação de
Serviços.

ELS fornece recursos adequados para resolver operacional e questões de
suporte rapidamente, central e local, para garantir que os usuários podem usar o
serviço para apoiar suas atividades de negócios sem interrupção injustificada.
As equipes de implantação deve analisar onde os usuários e recursos de
suporte irá enfrentar problemas e problemas, talvez com base na experiência
anterior, por exemplo esclarecimento, sobre:
• Papel atribuições, funções e responsabilidades
• Arranjos financeiros e de financiamento
• Compras e pedido cumprimento
• Segurança políticas e procedimentos
• Aumentar incidentes e mudar pedidos
• Escalada procedimentos
• Procedimento de reclamações
• Usando ferramentas de diagnóstico e ajudas
• Licenciamento de software. Regras
Durante ELS, a equipe de implantação implementa melhorias e resolve os
problemas que ajudam a estabilizar o serviço. O Melhoria de Serviço Continuada
publicação fornece informações relevantes sobre medição e melhorias no
serviço. A implantação recursos gradualmente desistir de prestar o apoio
adicional quando a usuários equipes e serviço familiarizar-se com as alterações
e os incidentes e riscos reduzir.
Métricas para o grupo de implantação de destino ou ambiente medida
desempenho do serviço, a performance do Serviço de Gestão de e os processos
operacionais e equipes eo número de incidentes e problemas, por tipo. O
objetivo da equipe de implantação é estabilizar o serviço para o grupo de
implantação de destino ou ambiente tão rápida e eficazmente quanto possível.
Um exemplo de um gráfico de desempenho de implantação é mostrado na
Figura 4.25.
Variação no desempenho entre grupos diferentes de implantação e unidades de
serviço devem ser analisadas e as lições aprendidas a partir de uma
implantação usado para melhorar distribuições subseqüentes.

Figura 4.25 Ilustração dos benefícios de suporte de vida direcionados cedo
O exemplo mostrado na Figura 4.25 apresenta o número de incidentes para dois
ramos de um varejo organização que têm o mesmo número de utilizadores e da
mesma desenvolvimento agendar. Na implantação de um a incidente ter
reduzido os níveis mais rapidamente. Aprofundando o Transição de Serviço
gerente descobriu que a equipe responsável pela implantação A foi mais
competente no treinamento de usuários e transferência de conhecimento para o
balcão de atendimento de modo que eles podem ajudar os utilizadores a ser
mais eficaz com maior rapidez.
Durante ELS, a equipe de implantação deve garantir que a documentação e
base de conhecimento são atualizados com diagnósticos adicionais, erro
conhecidos, solução alternativas e perguntas mais frequentes. A equipe também
deve resolver qualquer transferência de conhecimento ou lacunas de formação.
No metas acordadas em apoio início da vida, É importante para avaliar os
problemas e riscos, especialmente aqueles que afetam o cronograma de entrega
e custos. Transição de Serviço monitoriza a atuação do serviço novo ou alterado
em apoio início da vida até os critérios de saída sejam alcançados. Estes
incluem, quando:
• Os usuários podem utilizar o serviço de forma eficaz e eficiente para suas
atividades empresariais
• Proprietário do serviços e proprietário do processos estão comprometidos
para gerenciar e operar o serviço de acordo com o serviço modelo,
Desempenho padrãos e os processos
• A prestação de serviços é gerenciado e controlado através de qualquer
interface do provedor de serviços
• Progresso consistente está sendo feito para trazer os benefícios
esperados e valor em cada marco de apoio início da vida

• Nível de serviços padrões de desempenho e de serviço estão sendo
consistentemente alcançado sem variação inesperada transferência
formal antes de Operações de Serviço
• SLAs são finalizados e assinados pela diretoria e clientes
• Variações inesperadas no desempenho do serviço e atendimento ao
cliente ativoss como mudanças em riscos residuais são monitorados,
relatados e gerenciados de forma apropriada
• Verificando que as atividades de treinamento e transferência de
conhecimento são concluídas, obtendo confirmação positiva do público-
alvo. Isso pode ser na forma de testes de competência
• O serviço liberar, O SLA, Outros acordos e qualquer contratual entregas
são assinados fora.
4.4.5.9 Rever e fechar uma implantação
Quando se analisa a implantação das seguintes atividades devem ser incluídos:
• Captura de experiências e feedback no cliente, usuário e provedor de
serviços satisfação com a implantação, por exemplo, por meio de
pesquisas de feedback.
• Realçar qualidade critérios que não foram atendidas.
• Verifique se todas as ações, correções e mudanças necessárias estão
completas.
• Comente mudanças abertos e assegurar que o financiamento ea
responsabilidade por mudanças abertas são acordadas antes de entrega.
• Comente atuação metas e resultados alcançados, incluindo recurso e
usar capacidade tais como os acessos dos utilizadores, transaçãos e os
volumes de dados.
• Certifique-se de que não há capacidade, Capacidade de recursos, ou
problemas de desempenho no final da implantação.
• Verificar que qualquer problemas, erro conhecidos e solução alternativas
são documentadas e aceitas pelos clientes /negócio e / ou fornecedors.
• Reveja a Risco Registrar e identificar os impactos que Operação de
Serviços e de apoio. Riscos de endereço ou de concordar ação como
mover os riscos para a Transição de Serviço Log risco.
• Verificar que os activos redundantes foram removidos.
• Verifique se o serviço está pronto para transição de apoio início da vida
em operações de serviços.
Cada desenvolvimento deve considerar se quaisquer questões relevantes foram
detectados que devem ser passadas através de CSI, tais como:
• Comentários sobre a implantação modelo e plano
• Erros na procedimentos detectado
• «Quase-acidentes" onde as coisas poderiam ter dado errado em
circunstâncias previsíveis ou onde a intervenção foi necessária

• Dados incorretos ou informações relevantes registros
• Incidente e os problemas causados pela implantação
• Problemas com atualização de registros.
Implantação é completado com uma entrega do apoio para o grupo de
implantação ou alvo ambiente para operações de serviços.
Uma implementação de pós rever de uma implantação é realizada através
Gestão da Mudança.
4.4.5.10 Análise e Transição de Serviço próximo
Para finalizar que um Transição de Serviço é completado, deve haver um formal
rever realizado que é apropriado para a escala ea magnitude do mudar. Uma
revisão da Transição de Serviço deve incluir:
• Verificando que todas transição actividades completado, por exemplo,
documentação e informação é capturada, atualizado, garantiu, arquivados
• Verificando que as métricas precisas foram capturados.
Independente avaliação do lançamento do serviço utiliza as saídas de
implantação. Essa avaliação verifica o desempenho real e resultados do serviço
novo ou alterado contra o desempenho previsto e os resultados, ou seja, o
serviço esperado pelo usuário ou cliente. Um relatório de avaliação (ver 4.6.6)
está preparada que lista os desvios da SP / SLP / SDP, um risco perfil e
recomendações para a Gestão da Mudança. Se houver desvios no exigência de
nível de serviços, em seguida, o pacote de serviços, SLP ou SAC pode ser
necessário alterar (via Gestão da Mudança, De acordo com o representante do
cliente e outros das partes interessadass). Conclusão bem sucedida do
avaliação garante que o serviço pode ser formalmente fechado e entregue à
Operação de Serviços e CSI.
Atransição relatório deve ser elaborado que resume a resultados. Como parte de
produzir esse relatório de um workshop transição pós poderia ser realizada,
envolvendo todas as partes como um "lições aprendidas" do exercício. Lições
aprendidas e melhorias são alimentados em Gestão da Mudança para uma
revisão, após a aplicação e em Melhoria de Serviço Continuada para transições
futuras.
O processo de liberação começa com a recepção de um RFC aprovado para
implantar um pacote de lançamento pronta para produção. Desenvolvimento
começa com a recepção de um RFC aprovado para implantar um pacote de
liberação para um grupo de implantação de destino ou do ambiente, por
exemplo, unidade de negócios, Grupo de clientes e / ou serviço unidade.

As entradas são:
• Autorizado RFC
• Pacote de serviços, SLP
• SDP, incluindo o serviço de modelo e SAC
• Plano de continuidade de serviço de TI e afins plano de continuidade de
negócios
• Serviço de Gestão de e planos de operações e padrãos
• Tecnologia e aquisição de normas e catálogos
• Adquirido serviço ativos e componentes e a sua documentação
• Construir modelos e planos
• Ambiente exigências e especificaçãos para construir, testar, lançamento,
treinamento desastre, recuperação,piloto e implantação
• Solte política e liberação projeto de Design de Serviços
• Lançamento e implantação de modelos, incluindo planos de modelo
• Critérios de entrada e saída para cada fase de liberação e implantação.
As saídas são:
• Plano de lançamento e implantação
• RFCs concluídos para as atividades de lançamento e implantação
• Serviço de notificação
• Atualizado catálogo de serviços com as informações relevantes sobre o
serviço novo ou alterado
• Serviço testado Novo capacidade e do ambiente, incluindo SLA, Outros
acordos e contratos, mudou organização, As pessoas competentes e
motivados, negócios estabelecido e processos de Gestão de Serviços,
instalado aplicaçãos, bancos de dados, infra-estrutura convertidos
tecnologia, produtos e instalações
• Documentação Gestão de novo ou alterado Serviço
• Pacote de serviços que define o exigências da empresa cliente / para o
serviço
• SLP, que define o exigência de nível de serviços, por exemplo, horas de
serviço, serviços críticos de negócios, dados e períodos, meta de nível de
serviços
• SLA, Sustentando OLAs e contratos
• Serviço modelo que descreve a estrutura ea dinâmica de como o serviço
é operado e gerenciado
• Novos ou alterados relatórios de serviço
• Continuidade Testado planos
• Completas e precisas item de configuração lista com um auditar trilha
para o IC na liberar pacote e também o serviço novo ou alterado e
configurações de infra-estrutura
• Serviço plano de capacidade que está alinhada com o correspondente
negócio planos

• Implantação do pacote de liberação pronto (baseline) - para o futuro
desenvolvimentos
• Transição de Serviço Relatório.
Implantação é completado com uma entrega do serviço novo ou alterado para as
operações na conclusão bem sucedida da implementação de pós rever da
implantação realizada dentro Gestão da Mudança.
Ao longo da implantação processoApropriado, registros serão criados e
mantidos. Como itens de configuração são implantados com sucesso, o CMS
será atualizado com informações como:
• Novos ou alterados os itens de configuração
• Relaçãos entre exigências e casos de teste
• Instalação /construir planos
• Logística e planos de entrega
• Validação e planos de testes, provas e relatórios
• Locais novos ou alterados e usuários
• Estado atualizações (por exemplo, do reservado para viver)
• Mudança de propriedade ativoss
• Realização de licença.
Outros dados e informações também serão capturados e gravados dentro do
amplo serviço de sistema de gestão do conhecimento. Isto pode incluir:
• Desenvolvimento história da informação, da implantação em si, quem
estava envolvido, horários etc
• Registros de treinamento, normalmente realizada pelo RH em muitas
organizações, mas respeitantes a ITSM equipe a responsabilidade pela
sua atualização será logicamente descansar com ITSM também.
• Regras de acesso e níveis
• Erro conhecidos. Normalmente, um novo serviço ou alterados serão
introduzidos com identificado erros, que embora não de acordo com o
original Design de Serviços especificação são, todavia, suficientemente
pequena na natureza para ser aceitável em viver operação. Estes podem
estar sob investigação ativa e resolução pelos construtores de serviços,
ou pode ser considerado aceitável. Em ambos os casos os erros será
implantado no banco de dados de erros ao vivo como um elemento da
implantação do serviço ao vivo. Esta informação estará disponível através
dos SKMS ao balcão de atendimento que irá então ser capaz de ligar
incidentes relatados contra estes erro conhecidos.
Como parte das atividades de limpeza é importante para apagar ou arquivar
registros redundantes relacionadas com o serviço anterior ou produtos.

4.4.8.1 clientes ou negócios
Os indicadores incluem:
• Variação de serviço atuação exigido pelos clientes (mínimo e reduzindo)
• Número de incidentes contra a serviço (Baixo e reduzindo)
• De clientes aumentou e usuário satisfação com os serviços prestados
• Insatisfação do cliente diminuiu - questões de serviço resultantes de
serviços mal testados ou não testados aumenta a percepção negativa do
fornecedor de serviços organização como um todo.
4.4.8.2 Os prestadores de serviços
Os indicadores incluem:
• Reduzido recursos e os custos para diagnosticar e corrigir incidentes e
problemas na implantação e produção
• Maior adoção do Transição de Serviço quadro comum de padrãos, re-
utilizáveis processos e documentação de apoio
• Discrepâncias reduzidas em configuração auditars em comparação com o
mundo real.
Desafios para a liberação e implantação incluem:
• Desenvolver padrão atuação medidas e métodos de medição em todo
projetos e fornecedors
• Lidar com projetos e fornecedores onde as datas de entrega estimados
são imprecisos e há atrasos na programação de atividades Transição de
Serviço
• Entender o diferente das partes interessadas perspectivas que sustentam
eficaz gestão de risco para a mudança impacto avaliação e teste
atividades
• A construção de uma compreensão completa dos riscos que impactaram
ou podem impactar Transição de Serviço bem sucedida dos serviços e
lançamentos
• Incentivar uma gestão de risco cultura onde as pessoas compartilham
informações e ter uma abordagem pragmática e de medição para risco.
• O serviço novo ou alterado capacidade e os recursos são construídas no
alvo ambiente ou desenvolvimento grupo.

• O serviço novo ou modificado foi testado contra o Design de Serviços.
• A capacidade de serviço tem sido provado em um piloto desenvolvimento.
• Reutilizável teste modelos são desenvolvidos que pode ser usado para
testes de regressão em versões futuras.
Os riscos para sucesso liberar e implantação incluem:
• Mal definidas escopo e compreensão de dependências mais cedo ciclo de
vida etapas que levam ao escopo fluência durante a liberação e
implantação
• Usando a equipe que não se dedicam a atividades de liberação e
implantação, principalmente se o esforço é uma quantidade significativa
de seu tempo
• Gestão:
• Incompetência de gerenciamento
• A inadequação das políticas corporativas, por exemplo, segurança,
Licenciamento de software
• Adoção de práticas de manejo inadequadas
• Liderança fraca
• Finanças:
• Escassez de finanças
• Atrasos mover implantação em exercício diferente
• A falta de clareza sobre o financiamento para modificações /
correções durante transição
• Controles:
• Falta de definição dos controles necessários leva a mudanças mal
avaliados e não autorizada, afetando adversamente lançamento e
implantação planos
• Dificuldade de monitoramento e gerenciamento de licenças de
software, por exemplo, devido à complexidade
• Mudanças inesperadas ou em controlos regulamentares ou
requisitos de licenciamento
• Gestão de organização mudar:
• Expectativas pouco claras /objetivos de clientes, usuários,
fornecedors e outros das partes interessadass
• As diferenças culturais / mal-entendidos
• Fatores humanos
• Com os fornecedores / parceiros
• Má comunicação
• Mudança organizacional moral dos funcionários impactos
• Pessoas com problemas de violação de critérios de proteção de
dados pessoais
• Conflitos de personalidade
• Pessoal-chave que têm autoridade insuficiente para cumprir as
suas funções
• Recrutamento e seleção pobres procedimentos

• A falta de clareza sobre os papéis e responsabilidades
• Interesses escusos criando conflitos e comprometer qualidade
• Interesses individuais ou de grupo têm prioridade injustificada
• Compromisso pobres e tomada de decisão
• A não obtenção de aprovação adequada no momento certo
• A indecisão ou a decisão final tomada
• Falta de operacional apoiar
• Informações insuficientes ou imprecisas
• Saúde e segurança comprometida
• O tempo permitido para a liberação e desenvolvimento - É que vai fazer
ou quebrar o projeto?
• Fornecedors / fonte / parceria relaçãos durante transição:
• Falha de fornecedores para atender contratual exigências, o que
poderia ser em termos de qualidade, quantidade, prazos ou sua
exposição própria risco
• Atrasos na contrato negociação
• Mudança organizacional impactos empregado moral dos
funcionários e fornecedor atuação
• Protecção de dados impactos compartilhamento de dados
• Encolhendo recurso piscina de funcionários descontentes
• Governo questões:
• Compromisso da alta administração está faltando em uma ou outra
das organizações
• O gestão de fornecedores função não é maduro ou é inexistente
• Mudanças nas práticas de trabalho e procedimentos afectar uma
ou outra das organizações
• 'Inadequadaback-out'Ou' plano de contingência 'se sourcing / parceria
falhar
• Aplicação/ Técnicos riscos de infra-estrutura:
• Inadequado projeto
• Negligência profissional
• Humano erro/ Incompetência
• Infra-estrutura falha
• Diferenças / dependências em infra-estrutura / aplicações
• Aumento dos custos de desmantelamento / descomissionamento
• Segurança ficar comprometida
• Atuação falha (Pessoas ou equipamentos)
• Violações em física segurançaSegurança / informação
• Barreiras imprevistas ou restrições devido à infra-estrutura.

4,5 Serviço de validação e teste
O conceito subjacente a que Testing Service e Validação contribui é garantia de
qualidade - Estabelecer que a Design de Serviços e liberar vai entregar um novo
ou alterado serviço ou oferta de serviço que é apto para o efeito e apto para uso.
O teste é uma área vital dentro Serviço de Gestão de e tem sido muitas vezes a
causa subjacente invisível do que foi levado para ser processos de
Gerenciamento de Serviço ineficientes. Se os serviços não são testados
suficientemente então a sua introdução no operacional ambiente vai trazer um
aumento da:
• Incidentes, uma vez que falhas em elementos de serviço e desencontros
entre o que se queria e que foi entregue impacto no apoio às empresas
• Balcão de atendimento chamadas para esclarecimento, já que os serviços
que não estão funcionando como pretendido são inerentemente menos
intuitiva causando um maior apoio exigência
• Problemas e erros que são mais difíceis de diagnosticar no viver
ambiente
• Custos, já que os erros são mais caros para corrigir na produção que se
encontram em testes
• Serviços que não são utilizados de forma eficaz pelo usuários para
proporcionar o valor desejado.
4.5.1 Finalidade meta e os objetivos
A finalidade do Serviço de validação e teste processo é a seguinte:
• Planejar e implementar um processo de validação e teste estruturado que
fornece objetivo evidência de que o serviço novo ou alterado vai apoiar o
negócio do cliente e das partes interessadas requisitos, incluindo o
acordado nível de serviços
• Qualidade assegurar um lançamento, o seu serviço constituinte
componentes, a resultante serviço e serviço capacidade entregue por
uma liberação
• Identificar, avaliar e resolver problemas, erros e os riscos em todo
O objetivo da Serviço de validação e teste é garantir que um serviço irá fornecer
valor aos clientes e seus negócio.
Os objetivos do serviço de validação e teste são:
• Prover confiança de que uma versão irá criar um serviço novo ou alterado
ou ofertas de serviços que entregar o esperado resultados e valor para os
clientes dentro dos custos projetados, capacidade e constrangimentos

• Validar que um serviço é "apto para o efeito"- Ele vai entregar a
necessária atuação com limitações desejadas removidos
• Assegurar um serviço é "apto para uso" - ele atende certa especificaçãos,
nos termos e condições específicas de uso
• Confirmar que o cliente e das partes interessadas exigências para o
serviço novo ou modificado estão definidos corretamente e corrigir
qualquer erros ou variaçãos no início do serviço ciclo de vida como esta é
consideravelmente mais barato do que a fixação erros na produção.
4.5.2 Âmbito
O provedor de serviços assume a responsabilidade pela implementação,
operação e / ou manutenção de clientes ou serviço ativos a níveis especificados
de garantia, No âmbito de um serviço acordo.Serviço de validação e teste pode
ser aplicado em todo o serviço ciclo de vida para qualidade assegurar qualquer
aspecto de um serviço e capacidade dos prestadores de serviços, recursos e
capacidade para oferecer um serviço e / ou serviço liberar com sucesso. A fim
de validar e testar um serviço de ponta a ponta as interfaces para fornecedors,
clientes e parceiros são importantes. Interface do provedor de serviço definições
definir os limites do serviço a ser testado, por exemplo, processo as interfaces e
interfaces organizacionais.
O teste é igualmente aplicável a in-house ou desenvolvidos serviços, hardware,
software ou serviços baseados no conhecimento. Ele inclui o teste de serviços
novos ou modificados ou componentes de serviço e analisa o comportamento
destes no alvo unidade de negócios, Unidade de serviço, desenvolvimento grupo
ou ambiente. Este ambiente pode ter aspectos exteriores à controlar do
prestador de serviços, por exemplo, redes públicas, usuário níveis de habilidade
ou de ativos de clientes.
Teste apóia diretamente o processo de liberação e implantação, garantindo que
os níveis apropriados de testes são realizados durante o lançamento, construir e
implantação de atividades. Ele avalia o serviço detalhado modelos para garantir
que eles são adequados à finalidade e apto para utilização antes de serem
autorizados a entrar Operação de Serviços, através do catálogo de serviços. A
saída do teste é usada pela avaliação processar a fornecer a informação sobre
se o serviço está a ser avaliado de forma independente do serviço de entrega
atuação com um aceitável risco perfil.
Serviço falhas pode prejudicar o negócio do prestador de serviços e ativos do
cliente e resultar em resultados, tais como perda de reputação, perda de
dinheiro, perda de tempo, ferimentos e morte. O valor chave para o negócio e
clientes de testar o serviço e Validação é em termos do grau de confiança que

estabeleceu um novo serviço ou alterado irá entregar o valor e os resultados que
lhe é exigido e compreender os riscos.
Teste bem sucedido depende de todo o entendimento partes de que não pode
dar, de fato, não deve dar, quaisquer garantias, mas fornece um grau de
confiança medido. O grau requerido de confiança varia dependendo do cliente
negócio requisitos e as pressões de um organização.
4.5.4.1 Entradas de Design de Serviços
Um serviço é definido por uma pacote de serviços que compreende um ou mais
pacote de nível de serviços (SLPs) e re-utilizável componentes, muitos dos quais
são próprios, por exemplo, serviços serviços de apoios. O pacote de serviço
define os utilitários de serviços e garantias que são entregues através do correto
funcionamento do conjunto particular de identificado serviço ativos. Um SLP
fornece um nível definitivo de utilidade ou garantia a partir da perspectiva de
resultados, ativos e padrões de atividade de negócio (PBA) dos clientes. Por
conseguinte, é um contributo essencial para testar planejamento e projeto.
A concepção de um serviço é relacionado com o contexto no qual um serviço
será utilizado (as categorias de ativos do cliente). O atributos de um serviço de
caracterizar a forma e função do serviço a partir de uma perspectiva de
utilização. Estes atributos devem ser rastreáveis para os resultados de negócios
previsto que fornecem a utilidade do serviço. Alguns atributos são mais
importantes do que outros para diferentes conjuntos de usuários e clientes, por
exemplo, base, atuação e atributos atrativos. Um serviço bem concebido
proporciona uma combinação destes para proporcionar um nível adequado de
utilidade para o cliente.
O Pacote de Desenho de Serviço define o acordado exigências do serviço,
expresso em termos de serviço modelo e Operação de Serviçosplano que
fornecem entrada chave para testar o planejamento e design. Modelos de
serviço encontram-se descritos mais em Estratégia de Serviço publicação.

Figura 4.26 Modelos de serviço descrever a estrutura ea dinâmica de um serviço
O modelo de serviço (Figura 4.26) descreve a estrutura ea dinâmica de um
serviço que será entregue por operações de serviços, através do plano de
operações de serviços. Transição de Serviço avalia estes durante a validação e
teste fases.
Estrutura é definida em termos de núcleo particular e serviços de apoios e os
serviços necessários activos e os padrões em que eles estão configurados.
Como o serviço novo ou alterado é projetado, desenvolvido e construído, os
ativos de serviços são testadas e verificadas contra os requisitos e projeto
especificaçãos: é o ativo serviço construído corretamente?
Por exemplo, o projeto para serviços de armazenamento gerenciados devem ter
a entrada em ativos como cliente, tais como negócios aplicaçãos utilizam o
armazenamento, a maneira em que o armazenamento agrega valor para as
aplicações, e que os custos e riscos da cliente gostaria de evitar. A informação
sobre os riscos é de particular importância para serviço testando como isso vai
influenciar a cobertura dos testes e priorização.
Serviço modelos também descrevem a dinâmica de criação de valor. Atividades,
o fluxo de recursos, coordenação e interações descrever a dinâmica (ver Figura
4.27). Isso inclui a cooperação e comunicação entre os usuários de serviços e
agentes de serviços, como provedor de serviços pessoal, processos ou sistemas
que o usuário interage com, por exemplo, um menu de auto-serviço. A dinâmica
de um serviço incluem padrões de negócios atividade, Padrões de demanda,
exceções e variações.

Figura 4.27 Dinâmica de um modelo de serviço
Design de Serviços usa processo mapas, diagramas de fluxo de trabalho, filas
modelos, e padrões de atividade para definir os modelos de serviço. Transição
de Serviço como avalia os modelos de serviços detalhados para garantir que
eles sejam adequados à finalidade e apto para uso, é importante ter acesso a
estes modelos para desenvolver os modelos de teste e planos.
O pacote Design de Serviços define um conjunto de projeto restrições (Figura
4.28) contra o qual a versão do serviço e do serviço novo ou alterado será
desenvolvido e construído. Validação e teste deve testar o serviço nas fronteiras
para verificar se as restrições de projeto estão definidos corretamente e
principalmente se há uma melhoria de projeto para adicionar ou remover uma
restrição.

Figura 4.28 As restrições de design de um serviço
4.5.4.2 A qualidade do serviço e garantia
Garantia de serviço é entregue embora verificação e validação, Que por sua vez
são entregues por meio de testes (testando algo em condições que representam
a final viver situação - uma ambiente de teste) E por meio de observação ou
rever contra um padrão ou especificação.
Validação confirma, através do fornecimento de evidência objetiva, de que o
exigências para um uso específico pretendido ou aplicação foram cumpridas.
Validação num ciclo de vida contexto é o conjunto de atividades e garantir a
ganhar a confiança de que um sistema ou serviço é capaz de realizar a sua
finalidade, objetivos e objetivos.
A validação dos requisitos de serviço e as respectivas critérios de aceitação de
serviços começa a partir do momento em que as necessidades de serviço são
definidos. Haverá aumento dos níveis de serviço de validação de teste realizada
como uma versão do serviço progride através do ciclo de vida do serviço.

Verificação é a confirmação, através do fornecimento de evidência objetiva, de
que os requisitos especificados foram cumpridos, por exemplo, um serviço ativo
cumpre a sua especificação.
Logo no início do ciclo de vida do serviço, validação confirma que o cliente
precisa, contratos e serviço atributos, especificada no pacote de serviços, São
traduzidas corretamente no Design de Serviços como requisitos de nível de
serviço e restrições, por exemplo, capacidade e limitações de demanda. Mais
tarde, o serviço de testes de ciclo de vida são realizados para avaliar se o
serviço real oferece os níveis necessários de serviços, utilidades e garantias. O
garantia é uma garantia de que um produto ou serviço será prestado ou vai
atender a determinadas especificações. O valor é criado para os clientes, se os
serviços públicos são apto para o efeito e as garantias são adequados para uso
(Figura 4.29). Este é o foco de validação de serviço.
Figura 4,29 Criação de valor a partir de utilitários de serviços e garantias
4.5.4.3 Políticas
Políticas unidade que e apoio Serviço de validação e teste incluem serviço
qualidade política,risco política, Transição de Serviço política, liberar política e
Gestão da Mudança política.
Política de qualidade de serviço
A liderança sênior irá definir o significado de qualidade de serviço. Estratégia de
Serviço discute as perspectivas de qualidade que um provedor de serviços
precisa considerar. Além de nível de serviço métricas, qualidade de serviço leva
em conta o positivo impacto do serviço (utilidade) E da certeza da garantia de
impacto. A publicação Estratégia de Serviço descreve quatro perspectivas de
qualidade:

• Nível de excelência
• Valor para dinheiro
• Conformidade com as especificações
• Atendendo ou superando as expectativas.
Um ou mais, se não todos os quatro, perspectivas são geralmente necessários
para guiar a medição e controlar de Serviço de Gestão de processos. A
perspectiva dominante vai influenciar a forma como os serviços são medidos e
controlados, o que, por sua vez, influenciam a forma como os serviços são
projetados e operados. Compreender o qualidade perspectiva irá influenciar o
Design de Serviços e abordagem das validação e testes.
Política de risco
Diferentes segmentos de clientes, organizações, unidade de negócioss e serviço
unidades têm atitudes diferentes para risco. Quando um organização é um
entusiasta do tomador negócio risco, o teste será olhando para estabelecer um
menor grau de confiança do que uma organização de segurança crítica ou
regulada pode procurar. A política de risco irá influenciar o controle necessário
através Transição de Serviço incluindo o grau e nível de validação e teste de
exigência de nível de serviços, utilidade e garantia, I.e. disponibilidade riscos,
segurança riscos, riscos de continuidade e capacidade riscos.
Política de Transição de Serviço
Consulte o Capítulo 3.
Política de liberação
O tipo ea freqüência de lançamentos vai influenciar a abordagem de teste.
Lançamentos freqüentes, como uma vez por dia da unidade exigências para re-
utilizável teste modelos e testes automatizados.
Mudar a política de Gestão
A utilização de mudar de janelas podem influenciar o teste que deve ser
considerado. Por exemplo, se há uma política de "substituição" de um pacote de
lançamento no final do alteração de horário ou se o pacote de libertação
programada é atrasada, em seguida, a testes adicionais podem ser necessários
para testar esta combinação se existem dependências.
A política de testes irá refletir os requisitos de Estratégia de Serviço. Exemplos
de declarações políticas incluem:
• Biblioteca de teste e reutilização política. A natureza do IT Service
Management é repetitivo, e os benefícios muito de reutilização. A gestão

de teste do serviço papel dentro de um organização deve assumir a
responsabilidade de criar, catalogação e manutenção de uma biblioteca
de teste modelos, casos de teste, scripts de teste e dados de teste que
podem ser reutilizados. Projetos e equipes de serviço precisa ser
motivado e incentivado a criar re-utilizáveis teste ativoss e reutilizar ativos
de testes.
• Integrar o teste para o projeto e serviço ciclo de vida. Isto ajuda a detectar
e remover defeitos funcionais e não funcionais, logo que possível, e reduz
a incidentes na produção.
• Adote uma abordagem de teste baseado em risco que visa reduzir o risco
para o serviço e os negócios do cliente.
• Envolver-se com os clientes, das partes interessadass, usuários equipes
e serviços em todo o ciclo de vida do projeto e serviço para melhorar suas
habilidades de testes e capturar feedback sobre a qualidade dos serviços
e bens de serviço.
• Medições de teste e estabelecer monitoramento sistemas para melhorar a
eficiência e eficácia de Serviço de validação e teste Melhoria de Serviço
Continuada.
• Automatizar o uso de ferramentas de testes automatizados e sistemas,
especialmente para:
• Complexo sistemas e serviços, tais como serviços
geograficamente distribuídas, em grande escala infra-estruturas e
de negócios críticos aplicaçãos
• Em que o tempo para a mudança é crítico, por exemplo, se há
prazos apertados e uma tendência a espremer no teste do
Windows.
4.5.4.4 estratégia de teste
Um teste estratégia define a abordagem global da organização de ensaios e
testes de alocação de recursos. Pode aplicar-se a todo organização, Um
conjunto de serviços ou de um serviço individual. Qualquer estratégia de teste
precisa ser desenvolvido com adequada das partes interessadass para garantir
que há buy-no suficiente para a abordagem.
Cedo na ciclo de vida o serviço validação e teste papel precisa trabalhar com
Design de Serviços e serviço avaliação para planejar e projeto a abordagem de
teste usando a informação do pacote de serviços, Fonoaudiólogos, SDP e do
relatório de avaliação intercalar. As actividades incluem:
• Traduzindo o Design de Serviços em teste exigências e modelos de
ensaio, como por exemplo combinações de compreensão serviço ativos
necessária para fornecer um serviço, bem como as restrições que
definem o contexto de aproximação, e limites a serem testadas
• Estabelecer a melhor abordagem para otimizar a cobertura de teste dado
o perfil de risco e mudança impacto e de recursos avaliação

• Traduzindo o critérios de aceitação de serviços em critérios de entrada e
saída em cada nível de teste para definir o nível aceitável de margem
para erros em cada nível
• Traduzindo riscos e as questões do impacto, recursos e avaliação de
risco na RFC relacionados para o SDP / serviço liberar em requisitos de
teste.
Também é vital para trabalhar com Projeto Gerentes para assegurar que:
• Atividades de teste e recursos adequados são incluídos nos planos de
projeto
• Recursos especializados de teste (pessoas, ferramentas, licenças) são
alocados, se necessário
• O projeto compreende a testes obrigatórios e opcionais entregas
• As atividades de teste são geridos, monitorado e controlado.
Os aspectos a considerar e documentar no desenvolvimento da estratégia de
teste e relacionados planos são mostradas a seguir. Algumas das informações
também pode ser especificado no Transição de Serviço plano ou planos de teste
outros, e é importante para estruturar os planos de modo a que haja uma
duplicação mínima.
Estratégia de conteúdo de ensaio
• Propósito, metas e objetivos de serviço de teste
• Contexto
• Aplicável padrãos, os requisitos legais e regulamentares
• Aplicável contratos e acordos:
• Serviço de Gestão de políticas, processos e padrões
• Políticas, processos e práticas aplicáveis a testes
• Escopo e organizações:
• Provedor de serviços equipes
• Teste organização
• Terceiros, parceiros estratégicos, fornecedors
• Unidade de negócioss / locais
• Os clientes e os usuários
• Teste processo:
• Gerenciamento de testes e controlar - Gravação de progresso,
monitoramento e elaboração de relatórios
• Teste planejamento e estimativa, Incluindo custar estimativas para
o planejamento de serviços, recursos agendamento,
• Preparação de teste, por exemplo, site / ambiente de preparação,
pré-requisitos de instalação
• Atividades de teste - planejamento, execução e documentação de
casos de teste e resultados
• Métricas de teste e de melhoria

• Identificação de itens a serem testados:
• Pacote de nível de serviço
• SDP - Serviço modelo (Estrutura e dinâmica) solução, arquitetura
projeto
• Operação de Serviço plano
• Serviço de Gestão de Planos:
• Elementos críticos onde as prioridades de negócios e avaliação de
risco sugerir o teste deve se concentrar
• Unidade de negócioss, unidades de serviço, locais onde os testes
serão realizados
• Interface do provedor de serviços
• Abordagem:
• Selecionando o modelo de teste
• Níveis de teste
• Abordagens de teste, por exemplo, testes de regressão,
modelagem, Simulação
• Grau de independência para a realização, análise e avaliação de
testes
• Reutilização - experiência, conhecimento, experiência e dados
históricos
• Tempo, por exemplo, foco em testes individuais serviço ativos
testes vs cedo mais tarde, quando o serviço é todo construído
• Desenvolvimento e reutilização de projetos de teste, ferramentas,
scripts e dados
• Erro e alterar o manuseamento e controlar
• Medição sistema
• Critérios:
• Aprovação / reprovação critérios
• Critérios de entrada e saída para cada fase de teste
• Para parar ou re-iniciar as atividades de teste
• Pessoas exigências:
• Papéis e responsabilidades, incluindo a aprovação / rejeição (estes
podem estar em níveis diferentes, por exemplo, rejeitar uma
execução caro e longo projeto normalmente exige maior autoridade
do que aceitá-lo como planejado)
• Atribuir e agendar treinamento e transferência de conhecimento
• Stakeholders - provedor de serviços,fornecedors, cliente,usuário
envolvimento
• Requisitos de ambiente:
• Ambiente de testes para ser usado, locais, organizacional, técnica
• Os requisitos para cada ambiente de teste
• Planejamento e comissionamento de ambiente de teste
• Deliverables:
• Documentação obrigatória e opcional
• Teste planos

• Teste especificaçãos - teste projeto, Caso de teste de teste,
procedimento
• Os resultados dos testes e relatórios
• Validação e qualificação denunciar
• Teste relatórios resumidos.
4.5.4.5 Modelos de ensaio
Um teste modelo inclui um plano de teste, o que deve ser testado e os scripts de
teste que definem como cada elemento vai ser testado. Um teste modelo
garante que o teste seja executado de forma consistente de modo reprodutível,
que é eficaz e eficiente. Os scripts de teste definir as condições de liberação de
testes, associados os resultados esperados e os ciclos de testes.
Para garantir que o processo é repetitivo, os modelos de teste precisa ser bem
estruturada de uma forma que:
• Fornece volta de rastreabilidade para os critérios de exigência ou design
• Permite auditabilidade por meio da execução de teste, avaliação e
elaboração de relatórios
• Assegura que os elementos de teste podem ser mantidas e alteradas.
Os exemplos de modelos de teste são mostrados na Tabela 4.10.
Modelo de teste Objetivo / alvo entrega Condições de
ensaio com base
em
Serviço contrato
modelo de teste
Para validar que o cliente pode usar o serviço para
oferecer uma proposição de valor.
Contrato
exigências. Para
fins, Apto para
Usuário critérios.
Serviço modelo de
teste requisitos
Para confirmar que a provedor de serviços pode /
entregou o serviço necessária e esperada pelo
cliente.
Necessidades de
serviço e Critérios
de aceitação de
serviços.
Nível de serviço
modelo de teste
Para garantir que o provedor de serviços pode
fornecer o exigência de nível de serviços, e os
requisitos de nível de serviço podem ser cumpridas
no ambiente de produção, E.g. testando a resposta
e tempo de correção, disponibilidade, Prazos de
entrega de produtos, serviços de apoio.
Requisitos de nível
de serviço, SLA,
OLA.
Teste de serviço
modelo
Para garantir que o prestador de serviços é capaz
de fornecer, operar e gerenciar o serviço novo ou
alterado através do "como-concebido" modelo de
serviço que inclui a recurso modelo, custar modelo,
integrado processo modelo, capacidade e atuação
modelo etc
Modelo de serviço.

Operações modelo
de teste
Para garantir que o Operação de Serviçoequipes S
pode operar e apoiar o serviço novo ou alterado /
serviço componente incluindo o balcão de
atendimento,Operações de TI,gerenciamento de
aplicativos,gestão técnica. Ele inclui suporte de TI
local e pessoal negócio representantes para De
serviços de TI suporte e operações. Pode haver
diferentes modelos em diferentes lançamento /
teste, por exemplo, os níveis infra-estrutura de
tecnologia, aplicações.
Modelo de serviço,
Operações de
Serviços padrãos,
processos e
planos.
Desenvolvimento
modelo de teste de
libertação
Para verificar se a equipe de implantação,
ferramentas e procedimentos pode implantar o
liberar pacote em um grupo de implantação de
destino ou ambiente dentro do prazo estimado.
Para garantir que o pacote de lançamento contém
todos os componentes necessários para a
implantação de serviços, por exemplo, através da
realização de uma configuração auditar.
Lançamento e
implantação
projeto e plano.
A implementação
do modelo de teste
de instalação
Para testar se a equipe de implantação,
ferramentas e procedimentos pode instalar o pacote
de lançamento em um ambiente de destino dentro
do prazo estimado.
Lançamento e
implantação
projeto e plano.
Desenvolvimento
verificação modelo
de teste
Para testar se a implantação foi concluída com
sucesso e que todos serviço ativos e configurações
estão no local como planejado e satisfazer as suas
qualidade critérios.
Testes auditorias e
de 'reais' ativos de
serviços e
configurações.
Tabela 4.10 Exemplos de modelos de teste do serviço
À medida que o Design de Serviços fase progride, o testador pode usar o Design
de Serviços emergentes e plano de lançamento para determinar o específico
exigências, validação e as condições de ensaio, os casos e os mecanismos a
serem testadas. Um exemplo é mostrado na Tabela 4.11.
Validação de
referência
Condição de validação Níveis de
teste
Caso
de
teste
Mecanismo
1,1 Melhoria de 20% na
classificação de pesquisa com
usuários
1 M020 Vistoria
1,2 Redução de 20% nas
reclamações de usuários
1 M023 Processo
métrica
1,3 Aumento de 20% no uso do
canal de auto-atendimento
2 M123 Estatísticas de
uso
1,4 Ajudar função disponível na
página do aplicativo de auto-
serviço de ponto
3 T235 Teste funcional

1,5 Páginas da Web em
conformidade com
acessibilidade na web padrãos
4 (Aplicação) T201 Teste de
usabilidade
1,6 Aumento de 10% em pontos de
serviço público de auto-
4/5 Infra-
estrutura
técnica
T234 Estatísticas de
instalação
1,7 Públicas de auto-atendimento
pontos cumprir IS1223 padrão.
4/5 Infra-
estrutura
técnica
T234 Observância
teste
Requisitos de mesa 4,11 de serviço, 1: Melhorar a acessibilidade do usuário e
usabilidade
4.5.4.6 Validação e perspectivas de testes
Eficaz validação e concentra-se em ensaios se o serviço irá entregar conforme
necessário. Isto é baseado na perspectiva de quem vai usar, distribuir, implantar,
gerenciar e operar o serviço. A entrada de teste e critérios de saída são
desenvolvidos como a Pacote de Desenho de Serviço é desenvolvido. Estes irão
cobrir todos os aspectos da prestação do serviço a partir de perspectivas
diferentes, incluindo:
• Design de Serviços - Gestão, funcional e operacional
• Tecnologia projeto
• Projeto de processos
• Projeto de medição
• Documentação
• Habilidades e conhecimentos.
Serviço aceitação teste inicia-se com a verificação dos requisitos de serviço. Por
exemplo, clientes, representantes do cliente e outros das partes interessadass
que assinar o serviço acordado exigências também vai assinar o critérios de
aceitação de serviços e serviço de teste de aceitação plano. As partes
interessadas incluem:
• Empresa clientes / cliente representantes
• Usuários do serviço dentro do negócio do cliente que irá utilizar o serviço
novo ou alterado para auxiliá-los na entrega de seu trabalho objetivos e
entregar o serviço e / ou produto para seus clientes
• Fornecedors
• Provedor de serviços/ Unidade de serviço.
Usuários de negócios e perspectiva do cliente
O envolvimento das empresas em testes de aceitação é fundamental para o seu
sucesso, e está incluído no pacote Service Design, permitindo adequada recurso
planejamento.

Do ponto de vista do negócio é importante, a fim de:
• Tem meios definidos e acordados para medir a aceitação do serviço,
incluindo a interface com o prestador de serviços, por exemplo, como
erros ou consultas são comunicadas através de um único ponto de
contato,monitoramento progresso e fecho de mudar pedidos e incidentes
• Compreender e disponibilizar no nível apropriado e capacidade de
recurso para empreender serviço aceitação.
Do provedor de serviços"Perspectiva é a negócio envolvimento é importante
para:
• Manter o negócio envolveu durante construir e teste do serviço para evitar
surpresas quando o serviço de aceitação ocorre
• Garantir a total qualidade do serviço prestado para a aceitação é robusto,
já que este começa a definir as percepções das empresas sobre a
qualidade, confiança e usabilidade do sistema, Mesmo antes de entrar
viver
• Fornecer e manter instalações de teste sólidos e robustos de aceitação
em linha com os negócios exigências
• Compreender onde o teste de aceitação se encaixa em qualquer geral
serviço de negócio ou produto desenvolvimento teste atividade.
Mesmo quando em vivo operação, Um serviço não é 'emocionalmente' aceito
por cliente e usuário até que eles se familiarizem e conteúdo com ele. Os
benefícios de um serviço não será realizado até que a aceitação emocional foi
alcançado.
Aceitação (não) Emocional
Sul dos EUA Steel Mill implementado um serviço de fabricação nova ordem. Foi
encomendado, projetado e entregue por um fornecedor externo. O serviço
prestado foi inovadora e plenamente cumpridos os critérios acordados. O
resultado final foi que a empresa processou o fornecedor citando que o serviço
não era utilizável porque o pessoal de fábrica (devido à falta de formação) não
sabia como usar o sistema e, portanto, emocionalmente não aceitá-lo.
O teste é uma situação onde 'caso de usos ', focalizando os resultados
esperados de um serviço pode ser uma ajuda valiosa para efetiva avaliação de
utilidade de um serviço para o negócio.
Testes de usuário - sistema de aplicação, serviço
Teste compreende testes para determinar se o serviço atende aos requisitos
funcionais e de qualidade dos usuários finais (clientes), executando definido
processo de negócioes numa ambiente que, tanto quanto possível, simula o

viver operacional ambiente. Isto irá incluir alterações no sistema ou negócio
processo. Todos os detalhes da escopo e cobertura será definido no teste de
usuário e teste de aceitação do usuário (UAT) planos. Os usuários finais irão
testar os requisitos funcionais, estabelecendo o grau concordou o cliente de
confiança de que o serviço irá entregar o que eles necessitam. Eles também
realizar testes de Serviço de Gestão de actividades que estão envolvidos com,
por exemplo, capacidade de contato e usar o balcão de atendimento, A resposta
para os scripts de diagnóstico, gerenciamento de incidentes,pedido
cumprimento,mudar pedido gestão.
Uma chave prática é ter a certeza de que negócio usuários participantes em
testes têm suas expectativas claramente definidas e perceber que este é um
teste e esperar que algumas coisas podem não correr bem. Existe o risco de
que possam formar uma opinião demasiado cedo sobre a qualidade do serviço a
ser testado e palavra pode espalhar que a qualidade do serviço é pobre e não
devem ser usados.
Operações e perspectivas de melhoria de serviço
Devem ser tomadas medidas para assegurar que o pessoal de TI exigências
foram entregues antes desenvolvimento do serviço. Equipe de operações vai
usar o serviço aceitação passo para garantir que o caso:
• Facilidades tecnológicas estão no local para realizar o serviço novo ou
alterado
• Competências do pessoal, conhecimentos e recurso estão disponíveis
para suportar o serviço após o go-live
• Processos de apoio e os recursos estão no lugar, por exemplo, balcão de
atendimento, segundo / terceiro apoio de linha, incluindo terceiro
contratos, capacidade e disponibilidade monitoramento e alertando
• Continuidade de negócios e de TI tem sido considerada
• O acesso está disponível a documentação e SKMS.
Melhoria de Serviço Continuada também herdará o serviço novo ou alterado
para o escopo da sua melhoria programa, E devem certificar-se de que eles têm
conhecimento suficiente de sua objetivos e características.
4.5.4.7 Níveis de testes e modelos de teste
Teste está diretamente relacionado com a construção de serviço ativos e
produtos de modo que cada um tem um teste de aceitação associado e
atividade para garantir que ele atenda exigências. Isso envolve testar ativos de
serviços individuais e componentes antes de serem utilizados no serviço novo
ou alterado.

Cada serviço modelo e serviço associado entrega é suportado pelo seu modelo
próprio teste reutilizável que pode ser usado para testes de regressão durante a
implantação de um específico liberar bem como para testes de regressão em
versões futuras. Teste modelos ajudar com a construção de qualidade precoce
no ciclo de vida do serviço, em vez de esperar que os resultados dos testes em
um comunicado no final.
Níveis de construção e testes estão descritos na seção de liberação e
implantação (parágrafo 4.4.5.3). Os níveis de testes que estão a ser realizadas
são definidas pelo modelo de teste seleccionado.
Figura 4.30 Exemplo de serviço V-modelo
Usando um modelo tais como o V-modelo (Figura 4.30) construirs em Serviço de
validação e teste no início do serviço ciclo de vida. Ele fornece uma estrutura
para organizar os níveis de item de configuraçãos a ser gerido através do ciclo
de vida e da validação e testes associados atividades dentro e através de
estágios.
O nível de teste é derivada do modo sistema é projetado e construído. Isto é
conhecido como um modelo de V-, que mapeia os tipos de teste para cada fase
de desenvolvimento. O V-modelo fornece um exemplo de como o Transição de

Serviço níveis de teste pode ser combinado a fases correspondentes exigências
de serviço e de projeto.
O lado esquerdo representa o especificação do serviço requisitos para baixo
para o Design de Serviços detalhada. O lado direito enfoca as actividades de
validação que são executadas em relação às especificações definidas no lado
da mão esquerda. Em cada etapa, no lado esquerdo, há um envolvimento direto
pela parte equivalente no lado direito. Ele mostra que a validação do serviço e
teste de aceitação planejamento deve começar com a definição dos requisitos
de serviço. Por exemplo, os clientes que assinar as exigências de serviço
acordados também vai assinar o critérios de aceitação de serviços e plano de
teste.
4.5.4.8 abordagens de teste e técnicas
Existem muitas abordagens que podem ser combinados para conduzir validação
actividades e ensaios de acordo com os constrangimentos. Diferentes
abordagens podem ser combinadas para o exigências para diferentes tipos de
serviço de serviço, modelo,risco perfil, os níveis de teste, objetivos e os níveis de
teste. Os exemplos incluem:
• Documento rever
• Modelagem e de medição - adequado para testar o modelo de serviço e
operações de serviços planejar
• Baseada no risco abordagem que se concentra em áreas de maior risco,
por exemplo, serviços críticos de negócios, os riscos identificados no
mudar impacto análise e / ou serviço avaliação
• Padrãosobservância abordagem, por exemplo, normas nacionais ou
internacionais ou normas específicas da indústria
• Experiência abordagem baseada, por exemplo, utilizando especialistas no
assunto nas arenas de serviços de negócios, ou técnicos para dar
orientações sobre a cobertura do teste
• Abordagem baseada numa organização'S métodos de ciclo de vida, por
exemplo, cachoeira, ágil
• Simulação
• Testes de cenários
• RPG
• Prototipagem
• Laboratório de testes
• Testes de regressão
• Passo a passo conjunta / oficinas
• Vestido / serviço ensaio
• Sala de conferência piloto
• Viver piloto.

A fim de otimizar o teste recursos, atividades de teste devem ser alocados
contra impacto de serviço importância negócio, antecipado e risco. Negócios
análises de impacto realizadas durante projeto para negócio e gestão da
continuidade do serviço e disponibilidade propósitos são frequentemente muito
relevantes para as prioridades de testes que estabelecem e horários e deve
estar disponível, sujeito a confidencialidade e segurança preocupações.
4.5.4.9 Considerações sobre o projeto
Teste de serviço projeto visa o desenvolvimento de teste modelos e casos de
teste que medem as coisas corretas, a fim de estabelecer se o serviço vai
atender sua finalidade dentro dos limites especificados. É importante evitar
demasiado centrada no nível inferior componentes que são muitas vezes mais
fácil de testar e medir. A adoção de uma abordagem estruturada para a
definição do âmbito e projetar os testes ajuda a assegurar que seja dada
prioridade a testar as coisas certas. Modelos de ensaio deve ser bem
estruturada e repetitiva para facilitar e auditabilidade manutenção.
O serviço foi concebido em resposta ao negócio e requisitos acordados de
serviços e testes tem como objetivo identificar se estes foram alcançados.
Serviço validação e os projetos de teste considerar possíveis mudanças nas
circunstâncias e são flexíveis o suficiente para ser alterado. Eles podem ter de
ser alteradas depois falhas em testes de serviço inicial identificar uma mudança
no ambiente ou nas circunstâncias e, portanto, uma mudança na abordagem de
teste.
Considerações sobre o projeto são aplicáveis para modelos de serviços de teste,
casos de teste e scripts de teste e incluem:
• Empresa / organização:
• Alinhamento com serviço de negócios, processos e procedimentos
• Dependências de negócios, as prioridades, criticidade e impacto
• Os ciclos de negócios e variações sazonais
• Negócio transação níveis
• Os números e tipos de usuários e crescimento futuro antecipado
• Requisitos possíveis devido a novas instalações e funcionalidade
• Negócio cenários para testar o serviço de ponta a ponta
• Serviço arquitetura e atuação:
• Portfólio de Serviços/ Estrutura dos serviços, por exemplo, núcleo
de serviço, Apoiando e sustentando fornecedor serviços
• Opções para testar diferentes tipos de serviço ativos, utilitários e
garantia, E.g. disponibilidade, segurança, Continuidade
• Exigência de nível de serviços e meta de nível de serviços
• Transação níveis de serviço
• Restrições
• Previsões de desempenho e volume

• Monitoramento,modelagem e medição sistema, E.g. existe uma
necessidade significativa para a simulação para recriar os períodos
de pico de negócios? Será que a interface do serviço novo ou
alterado com a monitorização existente e ferramentas de gestão?
• Release de serviço ambiente de teste requisitos
• Gestão de Serviços:
• Serviço de Gestão de modelos, por exemplo,
capacidade,custar,atuação modelos
• Operação de ServiçoO modelo de
• Modelo de suporte de serviços
• Mudanças nos requisitos de informação Gestão de Serviços
• Mudanças na quantidade de usuários de serviços e transações
• Informações sobre o aplicativo e dados:
• Validar que o aplicação trabalha com a informação / bases de
dados e infra-estrutura técnica
• Funcionalidade testes para testar o comportamento da solução de
infra-estrutura e verificar: (i) nenhum conflito em versãos de
software, hardware ou rede componentes, e (ii) comum serviço de
infra-estruturas utilizados de acordo com o desenho
• Acesso direitos definir corretamente
• Infra-estrutura técnica:
• Físico ativoss - é que eles satisfazer as suas especificaçãos?
• Técnico recurso capacidade, por exemplo, armazenamento,
largura de banda de rede poder de processamento, energia,
• Peças sobressalentes - são peças suficientes ou ordenado e
programado para a entrega? São de hardware / software
configurações registradas e correto?
Aspectos que geralmente necessitam de ser considerados na concepção de
testes de serviço incluem:
• Financiar - É o acordado orçamento adequada, tem de passar orçamento
ultrapassado, ter custos alterados (por exemplo, licença de software e
aumenta a taxa de manutenção)?
• Documentação - É toda a documentação necessária disponível ou
programado para a produção, é possível (suficientemente intuitiva para o
público-alvo, disponível em todas as línguas necessárias), em formatos
corretos, tais como listas de verificação, balcão de atendimento scripts?
• Fornecedor do serviço, serviço ativo, Componente - Quais são as
interfaces internas ou externas?
• Construir - Pode o serviço, Ativo serviço ou componente ser construído
em um pacote de lançamento e ambientes de teste?
• Testável - É testável com os recursos, tempo e facilidades disponíveis ou
obtidos?
• Rastreabilidade - O que a rastreabilidade é lá de volta para os
requisitos?

• Onde e quando poderia testes lugar? Existem condições incomuns em
que um serviço pode ter de executar que deve ser testado?
• Remediação - O que planos estão lá para corrigir ou fazer uma liberar
através da ambientes?
Conscientização dos atuais ambientes tecnológicos para diferentes tipos de
negócios, cliente, Pessoal e usuário é essencial para a manutenção de um
válido ambiente de teste. O projeto dos ambientes de teste deve considerar o
atual e esperado viver ambiente quando o serviço é devido para operacional
handover e para o período da sua esperada operação. Na prática, para a
maioria das organizações, olhando mais de seis a nove meses para o negócio
ou futuro tecnológico é o limite prático. Em alguns setores, no entanto, tempos
muito mais longos exigem a necessidade de prever mais para o futuro, até
mesmo a ponto de restringir a inovação tecnológica no interesse dos testes e
expansivo - exemplos são militares sistemas, a NASA e outros ambientes de
segurança críticas.
Projetando a gestão e manutenção de dados de teste precisa de abordar
questões relevantes, tais como:
• Separação dos dados de teste a partir de todos os dados ao vivo,
incluindo medidas para garantir que os dados de teste não pode ser
confundido com viver dados ao serem usados, e vice-versa (há muitos
exemplos da vida real de dados em tempo real a ser copiados e utilizados
como dados de teste e ser a base para as decisões de negócios, por
exemplo, os ícones de desktop apontando para o banco de dados errado)
• Normas de proteção de dados - quando os dados activos são usados
para gerar um banco de dados de teste; se a informação pode ser
atribuída a pessoas que podem muito bem ser abrangidos pela legislação
de protecção de dados, que por exemplo, pode proibir o seu transporte
entre países
• Faça backup de dados de teste e restauração a um conhecido linha de
base para permitir o teste repetitivo, o que também se aplica às condições
de iniciação para testes de hardware que deve ser baseline
• Volatilidade dos dados de teste e ambientes de testes, processos e
procedimentos, que deve estar no local para construir rapidamente e
destruir o ambiente de teste para uma variedade de necessidades de
testes e por isso o cuidado deve ser tomado para assegurar que as
atividades de teste para um grupo que não comprometam as atividades
de teste para outro grupo
• Balanceamento custar e benefício - como ambientes de teste preenchidos
com dados relevantes são caros de construir e manter, de modo que os
benefícios em termos de risco redução para o serviço de negócios deve
ser equilibrado com o custo da prestação. Além disso, como de perto o
ambiente de teste corresponde produção ao vivo é uma questão
fundamental que precisa ser pesado custo equilíbrio com risco.

4.5.4.10 Tipos de testes
Os seguintes tipos de teste são utilizados para verificar se o serviço encontra o
usuário e cliente exigências, bem como a provedor de serviçosRequisitos 's para
a gestão, operação e apoio ao serviço. Deve ser tomado cuidado para
estabelecer a gama de utilizadores possíveis e, em seguida, para testar todos os
aspectos do serviço, incluindo o suporte e relatórios.
O ensaio funcional, dependerá do tipo de serviço e do canal de parto. O teste
funcional é coberto em muitos testes padrãos e melhores práticass (ver
informações).
Teste de serviço vai incluir muitos não-funcional testes. Esses testes podem ser
realizados em níveis diversos testes para ajudar a construir a confiança na
liberação de serviços. Eles incluem:
• Usabilidade teste
• Testes de acessibilidade
• Processo e testes de procedimento
• Transferência de conhecimentos e testes de competência
• Atuação,capacidade e resiliência teste
• De volume, carga, stress e testes de escalabilidade
• Disponibilidade teste
• Faça backup e recuperação teste
• Teste de coerência
• Testes de compatibilidade
• Testes de documentação
• Regulamentar e observância teste
• Segurança teste
• Posicionabilidade logística, e os ensaios de migração
• Coexistência e testes de compatibilidade
• Remediação, Continuidade e recuperação teste
• Configuração, construir e teste instalabilidade
• Operacionalidade e manutenção teste.
Existem vários tipos de teste a partir de perspectivas diferentes, que são
descritos abaixo.
Necessidades de serviço e testes de estrutura - prestador de serviços,
usuários e clientes
Validação do serviço atributos contra o contrato,pacote de serviços e serviço
modelo inclui a avaliação da integração ou "adequação" dos serviços públicos
em todo o núcleo e serviços de apoios e serviços ativos para garantir a
cobertura é total e não há conflitos.

Figura 4.31 testes Projetando para cobrir gama de ativos de serviços, utilidades e
garantias
Figura 4.31 mostra uma matriz de utilitário de serviço para serviço de relatório e
a serviço ativos que suportam cada utilidade. Esta matriz é um que pode ser
utilizado para desenhar os testes de serviço para assegurar que a estrutura de
serviço e teste projeto cobertura é apropriado. Casos testes de serviços são
projetados para testar o serviço exigências, em termos de utilidade,
capacidade,recurso finanças, utilização e riscos. Por exemplo abordagens para
testar o risco de serviço falha incluem o desempenho, estresse, usabilidade e
segurança teste.
Teste de nível de serviço - gerentes de nível de serviço, gerentes de
operações e clientes
Validar que o provedor de serviços pode entregar o exigência de nível de
serviços, por exemplo, testando a resposta e tempo de correção, disponibilidade,
Prazos de entrega de produtos e serviços de apoio.
O atuação a partir de um serviço ativo deve entregar a utilidade ou serviço
esperado. Isso não é necessariamente que o ativo pode entregar o que ele deve
ser capaz de, em seu próprio direito. Por exemplo fábrica de um carro

especificação pode afirmar que ele é capaz de 150kph, mas para a maioria dos
clientes 100kph entrega irá satisfazer plenamente o exigência.
Garantia e garantia de testes - ajuste para o teste de uso
Como discutido anteriormente nesta seção, os clientes vêem o serviço prestado
em termos de garantias contra os serviços públicos, que agregam valor aos seus
ativos, a fim de entregar o esperado negócio apoiar. Para qualquer serviço, as
garantias são expressas em termos mensuráveis que permitem testes de ser
concebido para estabelecer que o garantia pode ser entregue (dentro do grau de
confiança concordou). O grau de detalhe pode variar consideravelmente, mas
sempre refletem a acordo estabelecida durante Design de Serviços. Em todos os
casos, a garantia será descrito, e devem ser mensuráveis, em termos de
negócio do cliente e os efeitos potenciais sobre ele de sucesso ou falha do
serviço para atender a essa garantia.
Os seguintes testes são usados para fornecer a confiança de que as garantias
podem ser entregues, ou seja, o serviço é adequado para usar:
• Disponibilidade é o aspecto mais fundamental de assegurar valor aos
clientes. Ele garante ao cliente que os serviços estarão disponíveis para
uso nos termos e condições acordados. Serviços devem ser colocados à
disposição designado usuários só nas áreas especificadas, locais e
horários.
• Capacidade é um aspecto do serviço de relatório que assegura ao cliente
um serviço que vai suportar um nível especificado de negócios atividade
ou demanda em um nível específico de serviço qualidade. Os clientes
podem fazer alterações à sua utilização de serviços, sendo certo que a
sua processo de negócioes e sistemas será devidamente apoiados pelo
serviço. Gerenciamento de capacidade é um aspecto crítico da Serviço de
Gestão de porque tem um impacto directo impacto sobre a disponibilidade
de serviços. A capacidade disponível para suportar serviços também tem
um impacto do nível de continuidade de serviço cometido ou entregue. A
gestão eficaz da capacidade de serviço pode, portanto, ter efeitos de
primeira ordem e de segunda ordem no serviço garantia.
• Continuidade é o nível de garantia oferecido aos clientes que o serviço
vai continuar a apoiar o negócio através de grande falhas ou
perturbadoras eventos. O provedor de serviços compromete-se a manter
serviço ativos que irá proporcionar um nível suficiente de contingência e
capacidade de resposta. Processos e sistemas especializados vai chutar
para garantir que o nível de serviços recebido por ativos do cliente não
cair abaixo de um nível pré-definido. Fiabilidade é também, desde que os
níveis normais de serviço será restaurard dentro de um limite de tempo
pré-definido para limitar o impacto global de uma falha ou evento. O
eficácia de continuidade de serviço é medida em termos de perturbação
do estado produtivo de activos de clientes.

• Segurança garante que a utilização dos serviços pelos clientes será
segura. Isso significa que os ativos dos clientes dentro do escopo de
prestação de serviços e de suporte não será exposto a certo segurança
riscos. Prestadores de serviços se comprometem a implementar controles
gerais e de nível de serviço que vai garantir que o valor fornecido aos
clientes é completo e não corroído por quaisquer custos evitáveis e
riscos. Serviço de segurança abrange os seguintes aspectos de redução
de riscos:
• Uso autorizado e responsável dos serviços, conforme especificado
pelo cliente
• Proteção de ativos de clientes de acesso não autorizado ou mal-
intencionado
• Zonas de segurança entre ativos e ativos de clientes de serviços
• Desempenha um apoio papel para os outros três aspectos do
serviço de garantia
• Quando eficaz tem um positivo impacto sobre esses aspectos.
Serviço de segurança herda todas as propriedades gerais da segurança
física e humana ativoss, bem como intangíveis, tais como dados,
informação, coordenação e comunicação.
Usabilidade - usuários e mantenedores
Usabilidade o teste é susceptível de ser de uma importância crescente como
mais serviços ficam amplamente utilizado como uma parte da vida diária e uso
comercial comum. Focando a intuitividade de um serviço pode aumentar
significativamente o eficiência e reduzir o Custo unitários de ambos, usando e
apoio de um serviço.
Usuário testes de acessibilidade considera as habilidades restrito de usuários
reais ou potenciais de um novo serviço ou alterados e é comumente usado para
testar os serviços web. Cuidados devem ser tomados para estabelecer os tipos
de usuários possíveis, por exemplo, audição utilizadores deficientes podem ser
capazes de operar um serviço baseado em PC, mas não seria apoiada por
telefone somente suporte baseado em posto de serviço sistema. Este teste pode
se concentrar em usabilidade para:
• Os utilizadores com deficiência, por exemplo, visualmente ou com
deficiência auditiva
• Sensoriais usuários restritos, como por exemplo daltônico
• Usuários trabalhando em segunda língua ou com base em um diferente
cultura.
Contrato e testes de regulação

Auditars e os testes são realizados para verificar que os critérios do contratos ter
sido aceito antes aceitação do serviço end-to-end. Provedor de serviçoss pode
ter uma exigência contratual para cumprir a exigências da ISO / IEC 20000 ou
outro padrãos e que seria necessário para garantir que as cláusulas
correspondentes da norma sejam cumpridas durante a execução de um serviço
novo ou alterado e solte.
Testes de aceitação regulamentar é necessária em alguns setores como defesa,
serviços financeiros e produtos farmacêuticos.
Testes de conformidade
O teste é realizado para verificar observância contra os regulamentos internos e
compromissos existentes do organização, E.g. verificações de fraude.
Serviço de testes de Gestão
O serviço modelos vai ditar a abordagem integrada para testar a Serviço de
Gestão de processos. ISO / IEC 20000 cobre o mínimo exigências para cada
processo para ser compatível com o padrão e manutenção das inter-relações do
processo.
Exemplos de Serviço de Gestão de testes de capacidade de gestão são
mostrados na Tabela 4.12.
Gestão de
funções de
serviço
Exemplos de
controlo de
fase de
concepção de
gerenciamento
Exemplos de
verificações de
gerenciamento
fase de
construção
Exemplos de
verificações de
implantação de
gerenciamento de
fase
Exemplos de
verificações de
gerenciamento
operacional
Exemplos de
apoio início da
vida e
verificações de
gerenciamento
de CSI
Gerenciamento
da
Configuração
São os
designers
conscientes dos
padrões
corporativos
usados para
gerenciamento
de
configuração?
Como é que o
projeto atender
organizacional
padrãos para
configurações
aceitáveis?
O projeto
suporta o
conceito de
versão
controlar?
É o design
criado de uma
maneira que
permite a
Já os
desenvolvedores
construíram o
serviço, aplicação
e infra-estrutura
em conformidade
com os padrões
corporativos que
são usados para
gerenciamento de
configuração?
O serviço usa
apenas o padrão
de apoio
sistemas e
ferramentas que
são consideradas
aceitáveis?
O serviço inclui
suporte para a
versão,
construir,linha de
base e controle
de liberação e de
A implantação do
serviço de
atualizar o CMS
em cada fase do
lançamento?
É a equipe de
implantação
usando um
inventário
actualizado para
completar o plano
ea implantação?
Pode a equipe de
operações o
acesso ao CMS
para que possam
confirmar o serviço
que eles estão
conseguindo é a
versão correta e
configurado
corretamente?
São as instruções
operacionais sob
controle de versão
e construir
semelhantes aos
utilizados para as
compilações
aplicação?
Como o serviço
é revisada dentro
do otimizar fase,
é o CMS usado
para ajudar com
a revisão?
São pessoal de
gerenciamento
de configuração
envolvidos na
otimização
processo,
Incluindo
aconselhamento
na utilização de
e atualizar o
inventário?

desagregação
lógico do serviço
em item de
configuraçãos
(IC)?
gestão?
Que os
desenvolvedores
construídas na
estrutura CI
escolhido para o
serviço de
aplicação e infra-
estrutura?
Gestão da
Mudança
Será que o
Design de
Serviços lidar
com a
mudança? Será
que os
designers de
compreender o
processo de
Gerenciamento
de Mudança
usado pelo
organização?
Tem o serviço
ativos e
componentes foi
construído e
testado contra o
processo
corporativa
Gestão da
Mudança? Tem o
mudança de
emergência
processo foi
testado? É o
impacto avaliação
procedimento
para o Tipo CI
claramente
definido e que foi
testado?
É o processo de
Gerenciamento de
Mudança e
corporativa
padrões usados
durante a
implantação?
É a equipe de
operações
envolvidas no
processo de
Gerenciamento de
Mudança; que é
parte do sinal de
fora-e verificação
processo? Será
que um membro
da equipe de
operações de
assistir às reuniões
Gestão da
Mudança?
As modificações
são identificados
dentro desta
fase, a equipe
não usar o
sistema de
Gestão da
Mudança para
coordenar as
mudanças? A
equipe de
otimização de
compreender o
processo de
Gerenciamento
de Mudança?
Gerenciamento
de Liberação e
Implantação
Será que os
designers de
serviço entender
os padrões e
ferramentas
utilizadas para a
liberação e
implantação de
serviços? Como
o projeto
assegurar que o
serviço novo ou
alterado pode
ser implantado
no ambiente de
uma forma
simples e
eficaz?
Tem o serviço de
aplicação e infra-
estrutura foi
construído e
testado de forma
a garantir que
possa ser
liberado no meio
ambiente de uma
forma simples e
eficiente?
O serviço está
sendo implantado
de forma que
minimize os riscos,
como uma gradual
desenvolvimento?
Tem um
remediação/back-
out opção foi
incluído no pacote
de distribuição ou
de um processo
para o serviço e o
seu constituinte
componentes?
Será que o liberar
e implantação
processo
assegurar que as
informações de
implementação
está disponível
para as equipes de
operações? Faça o
Operação de
Serviços equipes
têm acesso à
versão e
informação,
mesmo antes de o
serviço ou
aplicativo está
implantado no
viver ambiente?
Os membros da
equipe de CSI
entender o
processo de
liberação, E eles
estão usando
isso para
planejamento a
implantação de
melhorias? É
Gerenciamento
de Liberação e
Implantação
envolvidos na
prestação de
consultoria para
o processo de
avaliação?
Gestão de
Segurança
Como o projeto
assegurar que o
serviço é
projetado com
segurança na
linha de frente?
É o construir
segurança do
processo na
sequência de
melhores práticas
para esta
atividade?
O serviço pode ser
implantado de uma
forma que atenda
às normas de
segurança
organizacional e
requisitos?
O serviço de apoio
às verificações
contínuas e
periódicas que a
Administração de
Segurança precisa
para concluir,
enquanto o serviço
está em
operacional usar?
Gerenciamento
de incidentes
O projeto
facilitará a
criação simples
de incidenteÉ
quando algo der
errado? O
projeto é
É um processo
de criação-de-
incidentes
simples, para
quando algo dá
errado,
construído e
A implantação de
usar o sistema de
gerenciamento de
incidentes para
relatar problemas
e problemas? Será
que os membros
Será que a equipe
de operações tem
acesso ao sistema
de gerenciamento
de incidente e ele
pode atualizar as
informações dentro
Os membros da
equipe de CSI
têm acesso ao
sistema de
gerenciamento
de incidentes,
para que possam

compatível com
o gerenciamento
de incidentes
organizacional
sistema? O
projeto
acomodar
registro
automático e
detecção de
incidentes?
testado em
serviços (por
exemplo,
notificação de
aplicativos)? Tem
a compatibilidade
com o sistema
organizacional de
gestão de
incidentes foi
testado?
da equipe de
implantação têm
acesso ao sistema
de gerenciamento
de incidentes, para
que possam
registrar incidentes
e também
visualizar os
incidentes que se
relacionam com o
desenvolvimento?
deste sistema?
Será que a equipe
de operações
compreender suas
responsabilidades
para lidar com
incidentes? É a
equipe de
operações
fornecido com
relatórios sobre o
quão bem ele lida
com incidentes, e
ela age sobre
estes?
registrar
incidentes e
também
visualizar os
incidentes que
podem ser
abordados na
otimização?
Gestão de
problemas
Como o projeto
facilitar os
métodos
utilizados para
análise de
causa raiz
utilizado dentro
da organização?
Tem o método de
fornecer
informações para
facilitar a análise
de causa raiz e
gerenciamento de
problemas foi
testado?
Tem um gerente
problema foi
nomeado para
essa implantação
e não a equipe de
implantação sabe
quem é?
Será que a equipe
de operações
contribuir para o
processo de
gerenciamento de
problemas,
idealmente,
ajudando com e
facilitar a análise
da causa raiz?
Será que a equipe
de operações
conhecer o
pessoal de
gerenciamento de
problemas
regularmente?
Será que a equipe
de operações ver o
relatório de gestão
semanal / mensal
problema?
É o processo de
otimização
sendo fornecidas
informações por
gerenciamento
de problemas
para incorporar
no processo de
avaliação?
Gerenciamento
de capacidade
São os
designers ciente
da abordagem
de
gerenciamento
de capacidade
utilizada dentro
da organização?
Como medir as
operações e
atuação? É
modelagem
sendo usada
para assegurar
que o modelo
satisfaz
capacidade
necessidades?
Tem o serviço foi
construído e
testado para
garantir que ele
atenda a
capacidade
exigências? Tem
a capacidade de
informação
fornecida pelo
serviço foi
testado e
verificado? São
características de
estresse e
volume
construído nos
serviços e
aplicações
constituintes?
É a gestão da
capacidade
envolvida na
implantação
processo de modo
que possa
monitorizar a
capacidade do
recursos
envolvidos na
implantação?
É a capacidade de
gestão da
informação sendo
monitorados e
informou sobre
como esse serviço
é usado, e essa
informação é
fornecida para o
gerenciamento de
capacidade?
É a gestão da
capacidade de
alimentação de
informação no
processo de
otimização?
Gerenciamento
de
disponibilidade
Será que o
projeto tratar o
disponibilidade
necessidades
do serviço? Tem
o serviço foi
projetado para
atender com
Como é que o
serviço foi
construído para
atender os
requisitos de
disponibilidade, e
como isso tem
sido testado? O
É o gerenciamento
de disponibilidade
monitoramento a
disponibilidade do
serviço, os
aplicativos que
estão sendo
implantados e do
Como é a
disponibilidade do
serviço que está
sendo medido, e é
esta informação
que está sendo
alimentada de
volta para a
A avaliação de
usar as
informações de
disponibilidade
para concluir a
proposta de
modificações
que são

apoio e
recuperação
capacidades do
organização?
que o teste foi
feito para
assegurar que a
serviço reúne as
capacidades de
backup e
recuperação da
organização? O
que acontece
quando os
aplicativos de
serviço e
subjacente está
estressado?
resto da infra-
estrutura de
tecnologia para
garantir que a
implantação não
está afetando a
disponibilidade?
Como é a
capacidade de
fazer backup e
recuperar o serviço
durante
desenvolvimento
sendo tratado?
gerenciamento de
disponibilidade
função dentro da
organização de TI?
necessárias para
o serviço? É
exigida qualquer
melhoria na
capacidade do
serviço para
backup e
recuperação?
Gestão da
continuidade
do serviço
Como o projeto
atender aos
requisitos de
continuidade de
serviços da
organização? O
desenho irá
satisfazer as
necessidades
do negócio
recuperação
processar após
um desastre?
Tem o serviço foi
construído para
apoiar o processo
de recuperação
de negócios
depois de um
desastre, e como
isso tem sido
testado?
Será que qualquer
mudança
necessária para o
processo de
recuperação de
negócios depois
de um desastre se
um deve ocorrer
durante ou após a
implantação deste
serviço?
É o processo de
recuperação de
empresas para o
serviço testado
regularmente por
operações?
O que é
requerido em
optimização da
recuperação de
negócios
processo para
atender às
necessidades de
negócios?
Gerenciamento
de nível de
serviço
Como o projeto
atender a SLA
exigências da
organização?
O serviço de
atender a SLA e
atuação
requisitos, e isso
foi testado?
É o gerenciamento
de nível de serviço
ciente da
implantação deste
serviço? Será que
este serviço tem
uma inicial SLA
para a fase de
implantação? O
serviço de afetar o
SLA requisitos
durante a
implantação?
É o SLA visível e
compreendido pela
equipe de
operações para
que aprecia a
forma como a sua
execução do
serviço afeta a
entrega do SLA?
Será operações
ver o semanal /
mensal nível de
serviço relatar?
É o serviço de
informação de
gestão de nível
disponível para
inclusão no
processo de
otimização?
Gestão
financeira
Será que o
projeto atender
as necessidades
financeiras para
este serviço?
Como o
desenho
assegurar que o
novo final ou
alterado serviço
vai atender as
expectativas de
retorno de
investimento?
Tem o serviço foi
construído para
fornecer
informações
financeiras, e
como isso está
sendo testado?
É a gestão
contabilidade
sendo feito durante
a implantação, de
modo que o total
custar implantação
do pode ser
incluído dentro do
custo de
propriedade?
Será operações
fornecer subsídios
para a informação
financeira sobre o
serviço?
Por exemplo, se
um serviço requer
um operador para
executar tarefas
adicionais à noite,
é esta gravado?
É a informação
financeira
disponível para
ser incluído no
processo de
avaliação?
Tabela Exemplos de 4,12 Serviço de Gestão de testes de gerenciamento
Testes operacionais - sistemas, serviços
Haverá muitos operacional testes de acordo com o tipo de serviço. Típico testes
incluem:

• Carga e stress - Estes testes estabelecer se o serviço novo ou
modificado irá realizar com os níveis necessários no capacidade provável
que esteja disponível. Os elementos de capacidade pode incluir eventuais
gargalos na infra-estrutura antecipados que podem ser esperados para
restringir atuação, Incluindo:
• Carregar e todo
• Comportamento nos limites superiores de sistema capacidade
• Largura de banda de rede
• O armazenamento de dados
• O poder de processamento ou memória ao vivo
• Balcão de atendimento recursos - pessoas e tecnologia, tais como
linhas de telefone e de registro
• Disponíveis licenças de software / assentos simultâneos
• Pessoal de apoio - ambos os números e as habilidades
• Instalações de treinamento, salas de aula, treinadores, etc licenças
TCC
• Horários lote noite de processamento, incluindo apoio tarefas.
• Segurança - Todos os serviços devem ser considerados para o seu
potencial impacto em relevante segurança preocupações e,
posteriormente, testados quanto à sua real impacto provável sobre a
segurança. Qualquer serviço que tem um impacto de segurança
antecipado ou expõe um segurança antecipado risco terão sido avaliados
em fase de projecto, ea exigência para o envolvimento de segurança
embutido no pacote de serviços. As organizações devem fazer referência
ao e pode querer procurar observância com ISO 27000, onde a
segurança é uma preocupação significativa para os seus serviços.
• Recuperabilidade - Cada significativa mudar terão sido avaliados para a
pergunta "Se essa mudança for feita, será a recuperação de desastres
(DR) plano precisa ser modificada em conformidade. " Não obstante essa
consideração no início do ciclo de vida, É apropriado para testar se o
serviço novo ou alterado é servida no âmbito do actual plano de DR (ou
alterada com a alteração). Normalmente, os problemas identificados
durante os testes devem ser dirigidos para a equipe de continuidade de
serviço e considerados como elementos ativos para futuros testes de DR.
Testes de regressão
Testes de regressão significa "repetição de um teste já executado com êxito, e
comparar os novos resultados com os resultados anteriormente válidas. Em
cada iteração dos testes de regressão verdade, todos os actuais testes
validados, são executados, e os novos resultados são comparados com o já
alcançado padrãos. Testes de regressão garante que um serviço novo ou
alterado não introduz erros em aspectos dos serviços ou Infra-estrutura de TI
que anteriormente trabalhou sem erros. Exemplos simples de o tipo de erro que
podem ser detectadas são problemas de software, hardware e de contenção de
incompatibilidade de rede. Testes de regressão é igualmente aplicável a outros

elementos, tais como Serviço de Gestão de processo de teste e medição. Na
realidade, é o conceito integrado de teste de serviço - avaliar se o serviço vai
entregar o negócio beneficiar - que faz testes de regressão muito importante nas
organizações modernas, e torná-lo cada vez mais importante.
Figura 4.32 Exemplo de um processo de validação e teste
O teste processo é mostrado esquematicamente na Figura 4.32. As atividades
de teste não são realizadas em uma seqüência. Várias actividades podem ser
executadas em paralelo, por exemplo, execução do teste começa antes todo o
teste projeto está completa. As actividades encontram-se descritos abaixo.
1. Validação e gerenciamento de testes
Gerenciamento de teste inclui o planejamento,controlar e elaboração de
relatórios de atividades através das fases de teste de Transição de Serviço.
Estas actividades incluem:
• Planejamento o teste recursos
• Priorização e programação que está a ser testado e quando
• Gestão de incidentes, problemas, erros não-conformidades, riscos e
problemas
• Verificando que entrada erro conhecidos e a sua documentação são
processados
• Monitoramento progresso e feedback de agrupamento de validação e
atividades de ensaio
• Gestão de incidentes, problemas, erros não-conformidades, riscos e
problemas descobertos durante transição
• Consequentes alterações, para reduzir erros que entram em produção
• Captura de configuração linha de base
• Coleta de métricas de teste, relatórios, análise e gestão.

Gerenciamento de teste inclui questões de gestão, mitigação de riscos e
mudanças de aplicação identificados a partir das atividades de testes como
estes podem impor atrasos e criar dependências que precisam ser geridos de
forma proactiva.
Métricas de teste são usados para medir o processo de teste e gerenciar e
controlar as atividades de teste. Eles permitem que o gerente de teste para
determinar o andamento do teste, o valor agregado e os testes excelente, e isso
ajuda o gerente de teste para estimar quando o teste será realizado. Boas
métricas fornecem informações para decisões de gestão que são necessários
para o agendamento de priorização e gestão de risco. Eles também fornecem
informações úteis para estimar e agendamento para futuros lançamentos.
2. Plano e projeto de teste
Teste planejamento e projeto atividades começam cedo no serviço ciclo de vida
e incluem:
• Resourcing
• Hardware, Redes, pessoal números e as habilidades etc capacidade
• Negócio / cliente recursos exigido, por exemplo, componentes ou
matérias-primas para a produção controlar serviços de caixa, para
serviços ATM
• Serviços de apoios acesso, incluindo, segurança, Catering, comunicações
• Cronograma de marcos, entrega e prazos de entrega
• Prazo acordado para a apreciação de relatórios e outros entregas
• Ponto e tempo de entrega e aceitação
• Financeiro exigências - orçamentos e financiamento.
3. Verifique plano de teste e design de teste
Verifique se os planos de teste e projeto de teste para garantir que:
• O teste modelo oferece cobertura de teste adequado e apropriado para o
risco perfil do serviço
• O modelo de teste abrange os aspectos-chave de integração e interfaces,
por exemplo, as SPIs
• Que os scripts de teste são precisos e completos.
4. Prepare ambiente de teste
Preparar o ambiente de teste usando os serviços da construir e teste ambiente
recurso e também utilizar o liberar e desenvolvimento processos para preparar o
ambiente de teste sempre que possível; ver o ponto 4.4.5.2. Capturar uma
configuração linha de base do ambiente de teste inicial.

5. Realizar testes
Realizar a testes utilizando técnicas manuais ou automatizados e
procedimentos. Testadores devem registrar suas descobertas durante os testes.
Se um teste falhar, as razões para falha deve ser devidamente documentada. O
teste deve continuar de acordo com o teste planos e scripts, se possível.
Quando parte de um teste falhar, o incidente ou questões devem ser resolvidas
ou documentados (por exemplo, como erro conhecido) E as apropriadas re-
testes devem ser realizados pelo mesmo testador.
Figura 4.33 Exemplo de realizar atividades de teste
Um exemplo das actividades de execução do teste é mostrado na Figura 4.33. O
entregas de teste são:
• Os resultados reais que mostram a prova de testes com referências
cruzadas para o teste modelo, Ciclos de teste e condições
• Problemas, erros, problemas não-conformidades e os riscos restantes
para ser resolvido

• Problemas resolvidos / erros conhecidos e alterações relacionadas
• Registe-off.
6. Avaliar os critérios de saída e relatório
Os resultados reais são comparados com os resultados esperados. Os
resultados podem ser interpretados em termos de aprovação / falha; risco para o
negócio /provedor de serviços, Ou se houver uma alteração em um valor
previsto, por exemplo, mais alto custar para entregar benefícios pretendidos.
Para produzir o relatório, reunir as métricas de teste e um resumo dos resultados
dos testes. Os exemplos de critérios de saída são:
• O serviço, com sua subjacente aplicaçãos e infra-estrutura de tecnologia,
permite que os usuários de negócios para executar todos os aspectos da
função tal como definido.
• O serviço atende a qualidade exigências.
• Configuração linha de bases são capturados no CMS.
7. Teste limpeza e fechamento
Garantir que o ambiente de testes são limpos ou inicializado. Rever a
abordagem de teste e identificar melhorias para a entrada de projeto/construir,
Comprar / construir parâmetros de decisão e testes de futuro
política/procedimentos.
4.5.6 interfaces de acionamento de entrada e saídas, e entre
processos
4.5.6.1 Gatilho
O gatilho para o teste é uma programada atividade num liberar plano de teste,
plano ou garantia de qualidade plano.
4.5.6.2 Entradas
Os principais insumos para a processo são os seguintes:
• O pacote de serviços - Este compreende um pacote de serviços do
núcleo e reutilizáveis componentes, muitos dos quais são próprios, por
exemplo, serviços serviços de apoio. Ele define utilidades do serviço e
garantias que são entregues através do correto funcionamento do
conjunto particular de identificado serviço ativos. Ele mapeia os padrões
de demanda para o serviço e perfil do usuários de PLSs.

• SLP - Uma ou mais PLSs que proporcionavam um nível definitivo de
utilidade ou garantia do ponto de vista resultados, bens, padrões de
atividade de negócio de clientes (PBA).
• Interface do provedor de serviço definições - Estes definem as interfaces
a serem testados, nas fronteiras do serviço sendo fornecida, por exemplo,
processo interfaces, as interfaces organizacionais.
• O Pacote Service Design - Isso define o acordado exigências do serviço,
expresso em termos de serviço modelo e Operação de Serviçosplano. Ela
inclui:
• Operação modelos (incluindo apoio recursos, escalada
procedimentos e manuseio situação crítica procedimentos)
• Capacidade/recurso modelo e planos -, combinadas com atuação e
aspectos da disponibilidade
• Financeira / econômica /custar modelos (com TCO, TCU)
• Serviço de Gestão de modelo (modelo de processo por exemplo,
integrado na norma ISO / IEC 20000)
• Projeto e interface especificaçãos.
• Planos de lançamento e implantação - Estes definem a ordem que
unidade de liberaçãos será implantado, construído e instalado.
• Critérios de Aceitação - Estes existem em todos os níveis em que testes
e aceitação Estão previstos.
• RFCs - Estes instigar mudanças necessárias para o ambiente no qual as
funções de serviço ou funcionará.
4.5.6.3 Saídas
A saída direta de teste é o relatório entregue ao serviço avaliação (Ver secção
4.6). Este estabelece:
• Configuração linha de base do teste ambiente
• Teste realizado (incluindo opções escolhidas e constrangimentos
encontrados)
• Os resultados dos testes estas
• A análise dos resultados, e.g. comparação dos resultados reais com os
resultados esperados, os riscos identificados durante as atividades de
teste.
Depois que o serviço tem sido usado por um tempo razoável deve haver dados
suficientes para realizar uma avaliação do real vs previsto serviço capacidade e
atuação. Se a avaliação for bem sucedida, um relatório de avaliação é enviado
para Gestão da Mudança com uma recomendação para promover o lançamento
do serviço de apoio início da vida e em operação normal.
Outras saídas incluem:

• Atualizado dados, informações e conhecimento para ser adicionado ao
serviço de sistema de gestão do conhecimento, E.g. erros solução
alternativas, as técnicas de teste, os métodos de análise
• Teste incidentes, problemas e erro registros
• Idéias de melhoria para Melhoria de Serviço Continuada para enfrentar
potenciais melhorias em qualquer área que tem impacto sobre o teste:
• Para o processo de teste em si
• À natureza e documentação da Design de Serviços saídas
• Terceiro relaçãos, fornecedors de equipamentos ou de serviços, parceiros
(co-fornecedores aos clientes finais), usuários e clientes ou outros das
partes interessadass.
4.5.6.4 Interfaces para estágios do ciclo de vida de outros
Teste suporta todos os liberar e desenvolvimento passos dentro Transição de
Serviço.
Embora este capítulo centra-se na aplicação de testes na fase de Transição de
Serviço, o teste estratégia irá assegurar que o teste processo funciona com
todas as fases do ciclo de vida:
• Trabalhar com Design de Serviços para assegurar que os projetos são
inerentemente testável e apoio positivo na realização deste objectivo
exemplos vão desde incluindo a auto-monitoramento dentro de hardware
e software, através da re-utilização de elementos de serviço previamente
testadas e conhecido através de assegurar direitos de acesso a
fornecedores de terceiros para realizar inspeção e observação de
elementos de serviço entregues facilmente
• Trabalhando em estreita colaboração com a CSI para alimentar falha
informação e de aperfeiçoamento idéias resultantes de exercícios de
testes
• Operação de Serviço usará manutenção testes para garantir a eficácia
continuada dos serviços, pois esses testes exigirá manutenção de lidar
com a inovação e mudança nas circunstâncias ambientais
• Estratégia de Serviço deve acomodar testes em termos de financiamento
adequado, recurso, Etc perfil
A natureza do IT Service Management é repetitivo, e essa capacidade de se
beneficiar de reutilização é reconhecido na utilização sugerida de transição
modelos. Testando benefícios muito de reutilização e, para isso, é sensato para
criar e manter uma biblioteca de testes relevantes e um conjunto de dados
atualizados e mantidos estabelecidos para a aplicação e execução de testes. O
grupo de gestão de teste dentro de um organização deve assumir a

responsabilidade de criar, catalogação e manutenção de scripts de teste, casos
de teste e os dados de teste que podem ser reutilizados.
Da mesma forma, o uso de ferramentas de testes automatizados (Computer
Aided Software Testing - CAST) está se tornando cada vez mais central para o
teste eficaz em ambientes de software complexos. Equivalentemente
abordagens de teste padrão e automatizado de hardware são rápidos e eficazes.
Os dados de teste
No entanto também um teste foi concebido, ele conta sobre a relevância dos
dados utilizados para executá-lo. Isso claramente se aplica fortemente para
testes de software, mas as preocupações equivalentes se relacionam com os
ambientes em que hardware, etc documentação é testada. Testando
equipamentos eléctricos num ambiente protegido, com fornecimento de energia
alisado e de poeiras, a temperatura ea humidade controlar não será um teste
importante se o equipamento vai ser utilizado num escritório normal.
Ambientes de teste
Ambiente de testes deve ser mantido ativamente e protegidos. Para qualquer
significativo mudar para uma serviço, A pergunta deve ser feita (como por
relevância da continuidade e plano de capacidades, deve a mudança ser aceito
e implementado): "Se esta mudança se concretize, será necessário que haja
uma consequente impacto para os dados de teste? "Se assim for, pode envolver
a atualização de dados de teste, como parte da mudança, eo dependência de
um elemento de serviço, ou serviço, em dados de ensaio ou teste ambiente será
evidente a partir dos SKMS, através registros e relaçãos, no âmbito do CMS.
Resultados de esta questão incluem:
• Atualização conseqüentes dos dados de teste
• Um novo conjunto de dados separado ou novo ambiente de teste, Uma
vez que o original, é ainda necessário para outros serviços
• Redundância dos dados de teste ou ambiente - uma vez que a mudança
vai permitir testes dentro de outro ambiente de teste existente, com ou
sem modificação para que os dados de ambiente / (isso pode na verdade
ser a justificativa por trás de uma mudança perfectivo - para reduzir os
custos de testes)
• Aceitação que um menor nível de teste serão aceitos desde que os dados
de teste / ambiente não pode ser atualizado para oferecer cobertura de
teste equivalente para o serviço mudou.
Manutenção de dados de teste deve ser um exercício ativo e deve abordar
questões relevantes, incluindo:

• Separação de quaisquer viver dados, e os passos para garantir que ele
não pode ser confundido com dados ao vivo ao ser usado, e vice-versa
(há muitos exemplos da vida real de dados em tempo real a ser copiados
e utilizados como dados de teste e ser a base para as decisões de
negócios)
• Normas de proteção de dados - quando os dados activos são usados
para gerar um banco de dados de teste, se a informação pode ser
atribuída a pessoas que podem muito bem ser abrangidos pela legislação
de protecção de dados que, por exemplo, pode proibir o seu transporte
entre países
• Faça backup de dados de teste e restauração a um conhecido linha de
base para permitir testes repetíveis, o que também se aplica às condições
de iniciação para testes de hardware que deve ser baseline.
Uma base de dados de teste estabelecido também pode ser usado como um
meio de formação segura e realista para um serviço.
4.5.8.1 primário (de valor para o negócio / clientes)
O negócio julgará testes de desempenho como um componente do Design de
Serviços e transição as fases do ciclo de vida de serviço. Especificamente, o
eficácia de testar em entregar para a empresa pode ser avaliada através de:
• Cedo validação que o serviço vai entregar o valor previsto, que permite a
correção precoce
• Redução do impacto da incidentes e erros em ao vivo que são atribuíveis
aos recém-transferida serviços
• Utilização mais eficaz dos recurso e envolvimento do cliente / empresa
• Reduziu os atrasos em testes de impacto que o negócio
• O aumento da compreensão mútua do serviço novo ou alterado
• Compreensão clara dos papéis e responsabilidades associadas com o
serviço novo ou alterado entre os clientes, usuários e provedor de
serviços
• Custar e recursos necessários a partir de usuário e cliente envolvimento
(por exemplo, testes de aceitação do usuário).
A empresa também irá se preocupar com a economia do teste processo - Em
termos de:
• Teste planejamento, Preparação, as taxas de execução
• Incidente,problema,evento taxas
• Emissão e risco taxa
• Problema resolução taxa
• Resolução eficácia taxa

• Contenção fase - análise por serviço ciclo de vida etapa
• Reparar percentual esforço
• Problemas e as mudanças por serviço ativo ou Tipo CI
• Alterações tardias por serviço estágio do ciclo de vida
• Percentual eficácia inspeção
• Residual risco percentagem
• Inspeção e testes retorno sobre o investimento (ROI)
• Custo de horas extras não planejada e não orçamentado para o negócio
• Custo de fixação erros em viver operação comparado a correção de erros
no início do ciclo de vida (por exemplo, os custos podem ser de £ 10 para
corrigir um erro na Design de Serviços e R $ 10.000 para corrigir o erro de
se atingir a produção)
• Custo operacional melhorias associado com a redução de erros em
serviços novos ou alterados.
4.5.8.2 secundário (interno)
O teste função e processo em si deve se esforçar para ser eficaz e eficiente, e
por isso as medidas de sua eficácia e os custos precisam ser tomadas. Estes
incluem:
• Esforço e custo de instalação de um teste ambiente
• Esforço necessário para encontrar defeitos - ou seja, número de defeitos
(por tipo de significado, categoria etc) em comparação com os testes
recurso aplicado
• Redução de erros de repetição - opinião dos testes garante que a ação
corretiva dentro projeto e transição (Através CSI) evita erros sejam
repetidos num posterior liberars ou serviços
• Reduziu a taxa de erro / defeito na tarde testando estágios ou de
produção
• Reutilização de dados de teste
• Percentagem incidentes ligados a erros detectados durante os testes e
liberado ao vivo
• Percentagem erros, em cada fase do ciclo de vida
• Número e percentual de erros que poderia ter sido descoberto nos testes
• Incidentes de teste encontrado como percentagem de casos que ocorrem
em operações vivos
• Percentual de culpas encontrado mais cedo avaliação etapas - já que os
custos de reparação acelerar abruptamente para a correção em fases
posteriores da transição
• Número de erro conhecidos documentadas nas fases anteriores de teste.
Testes é de cerca de medir a capacidade de um serviço, conforme necessário
para realizar em um ambiente simulado (ou, ocasionalmente, o real), e por isso,
nessa medida, é focada na medição. Deve ser tomado cuidado para tentar
separar as medidas que, na verdade, se relacionam com o processo de teste a

partir do número de erros introduzidos e serviços sistemas. Medição descuidado
pode aparecer para melhorar os testes eficácia embora o desenvolvimento
práticas são piores - é simplesmente mais fácil encontrar defeitos quando há
muitos deles. O ponto aqui é que o teste é realmente uma etapa do
projeto,construirE liberação desenvolvimento processos ea medida importante é
o geral - sobre a prestação de serviços que oferecem benefícios e não com
menos frequência.
Ainda assim, os desafios mais freqüentes para testes eficazes são baseadas em
falta de respeito e compreensão para o papel dos testes. Tradicionalmente o
teste tenha sido privado de financiamento, e isso resulta em:
• Incapacidade de manter ambiente de teste e teste dados que
correspondam ao viver ambiente
• Insuficiência de pessoal, habilidades e ferramentas de teste para fornecer
cobertura de testes adequados
• Projetos de avanço e prazos alocados testes sendo espremido para
restaurar projeto Go-live datas, mas no custar de qualidade
• Desenvolver padrão atuação medidas e métodos de medição em projetos
e fornecedors
• Projetos e fornecedores estimar datas de entrega imprecisa e causando
atrasos na programação Transição de Serviço actividades.
eficaz gestão de risco para a mudança impacto actividades de avaliação e
teste
ou podem impactar Transição de Serviço bem sucedida dos serviços e
lançamentos
informações e ter uma abordagem pragmática e de medição para arriscar.
• Qualidade é construída em cada etapa do atendimento ciclo de vida
usando um quadro estruturado, como o V-modelo
• Problemas são identificados no início do ciclo de vida do serviço
• Teste fornece evidências de que o serviço ativos e configurações foram
construídos e implementados correctamente para além do serviço de
entrega de que o cliente necessita
• Reutilizáveis modelos de teste foram desenvolvidos para serem utilizados
para os testes de regressão, no futuro liberars
Os riscos para sucesso Serviço de validação e teste incluem:

• Expectativas pouco claras /objetivos
• A falta de compreensão dos riscos significa que o teste não é destinado a
elementos críticos que precisam ser bem controlada e, portanto, testado
• Recurso (por exemplo, a falta usuários, pessoal de apoio) introduzir
atrasos e ter um impacto Transições em outro serviço.

Avaliação 4,6
Avaliação é um genérico processo que considera se o atuação de algo é
aceitável, valor para o dinheiro etc - e se ele vai ser prosseguido, aceitou em
uso, pago, etc
O propósito da avaliação é fornecer um meio consistente e normalizados de
determinação do desempenho de uma mudança de serviço, no contexto dos
serviços existentes ou previstos e Infra-estrutura de TI. O desempenho real de
um mudar é avaliada em relação a sua previu atuação e quaisquer desvios entre
os dois são compreendidos e geridos.
O objetivo da avaliação é definir das partes interessadas expectativas
corretamente e fornecer informações eficazes e precisas para Gestão da
Mudança fazer alterações certeza que afectam negativamente serviço
capacidade e introduzir risco não transitou desmarcada.
O objetivo é a seguinte:
• Avaliar os efeitos pretendidos de uma mudança de serviço e, como
grande parte dos efeitos indesejados como é razoavelmente prático, dada
capacidade,recurso e restrições organizacionais
• Fornecer a boa qualidade saídas do processo de avaliação para que o
Gerenciamento de Mudanças pode acelerar uma decisão eficaz sobre se
uma mudança de serviço é para ser aprovado ou não.
4.6.2 Âmbito
Especificamente neste seção, considerar a avaliação de serviços novos ou
modificados definidos pelo Serviço de Projeto, Durante desenvolvimento e antes
definitiva transição para operação de serviços. A importância de avaliar o
desempenho real de qualquer mudança de serviço contra o seu rendimento
previsto é uma importante fonte de informações para provedor de serviçoss para
ajudar a garantir que as expectativas são realistas e definidos para identificar
que se existem razões que o desempenho da produção não atendem o que era
esperado.
Avaliação é, pela sua própria natureza, causa com valor. Especificamente
avaliação eficaz estabelecerá a utilização da recursos em termos de benefício
entregues e que esta informação irá permitir um foco mais preciso no valor de
serviço futuro desenvolvimento e Gestão da Mudança. Existe uma grande
quantidade de informação que Melhoria de Serviço Continuada pode levar de

avaliação para analisar futuras melhorias para o processo de mudança e as
previsões e medição de serviço mudar atuação.
Políticas
As políticas a seguir se aplicam ao processo de avaliação:
• Design de Serviçoss mudanças ou serviço será avaliado antes de ser
transferida.
• Qualquer desvio entre o desempenho previsto e real será gerido pelo
representante do cliente ou cliente ao aceitar a mudança, embora o
desempenho real é diferente do que foi previsto, rejeitar a mudança, ou
exigindo uma nova mudança a ser implementada com o desempenho
previsto revisado previamente acordado . Nenhuma outra resultados de
avaliação são permitidos.
• Uma avaliação não deve ser realizada sem um pacote de envolvimento
do cliente.
Princípios
Os seguintes princípios devem orientar a avaliação execução processo:
• Tanto quanto seja razoavelmente prático, a não intencional, assim como
os efeitos pretendidos de uma mudança precisa ser identificada e as suas
consequências entendido e considerado.
• A mudança de serviço será bastante, de forma consistente, abertamente
e, sempre que possível, objetivamente.
Conceitos básicos
A avaliação processo utiliza o Plan-Do-Check-Act (PDCA) modelo para garantir
a consistência em todas as avaliações.
4.6.5.1 Avaliação termos de serviço
Os principais termos apresentados na Tabela 4.13 aplicar ao processo de
avaliação do serviço.
Prazo Função / Meios
Mudança de
serviço
Uma mudança para um serviço já existente ou a introdução de um novo
serviço, a mudança de serviço chega em serviço avaliação e qualificação

sob a forma de um Requisição de Mudança (RFC) de Gestão da Mudança
Pacote Service
Design
Define o serviço e fornece uma plano de mudanças de serviço para o
próximo período (por exemplo, os próximos 12 meses). De particular
interesse para o serviço de avaliação é os Critérios de Aceitação e do
previsto atuação de um serviço em relação a uma mudança de serviço
Atuação Os utilitários e garantias de um serviço
Atuação modelo Uma representação do desempenho de um serviço
Desempenho
previsto
O desempenho esperado de um serviço na sequência de uma mudança de
serviço
O desempenho
real
O desempenho alcançado na sequência de uma mudança de serviço
Desvios denunciar A diferença entre o desempenho previsto e real
Risco Afunção da probabilidade e negativo impacto de um serviço não executado
como esperado
Contramedidas A mitigação que é implementada para reduzir o risco
Plano de teste e
resultados
O teste plano é uma resposta a um impacto avaliação da variação serviço
proposto. Normalmente, o plano vai especificar como a mudança vai ser
testado, o que registros resultará de testes e onde serão armazenados;
que irá aprovar a mudança, e como ele vai ser assegurado que a mudança
eo serviço (s) que afeta permanecerá estável ao longo do tempo. O plano
de teste pode incluir uma qualificação e um plano validação planejar, se a
mudança afeta um ambiente regulado. Os resultados representam a
seguinte implementação real do desempenho da mudança
Risco residual O risco remanescente após contramedidas foram implantados
Serviço
capacidade
A capacidade de um serviço, conforme necessário para realizar
Capacidade Um organizaçãoCapacidade "s para manter a capacidade de serviço sob
quaisquer circunstâncias pré-definidas
Constrangimento Limites sobre a capacidade de uma organização
Recurso O normal exigências de uma organização para manter a capacidade de
serviço
Avaliação plano O resultado da avaliação planejamento exercer
Relatório de
avaliação
Um relatório gerado pela função de avaliação, que é passado ao
Gerenciamento de Mudanças e que compreende:
• Um perfil de risco
• Um relatório de desvios
• Uma recomendação
• Uma declaração de qualificação.

Tabela 4,13 termos-chave que se aplicam ao processo de avaliação de serviços
4.6.5.2 Processo de avaliação

Figura 4.34 Processo de avaliação

Figura 4.34 apresenta o avaliação processo com entradas e saídas.
4.6.5.3 Plano de avaliação
Avaliação de um mudar deve ser realizado a partir de um número de diferentes
perspectivas para assegurar quaisquer efeitos indesejados de uma mudança
são entendidos, bem como os efeitos pretendidos.
De um modo geral seria de esperar os efeitos pretendidos de uma mudança
para ser benéfico. Os efeitos indesejáveis são mais difíceis de prever, muitas
vezes não é visto, mesmo após a mudança de serviço é implementado, e
freqüentemente ignorado. Além disso, eles nem sempre será benéfico, por
exemplo em termos de impacto em outros serviços, o impacto sobre os clientes
e usuários do serviço, e rede sobrecarga.
Efeitos pretendidos de uma mudança devem corresponder aos critérios de
aceitação. Efeitos indesejados não são muitas vezes vistos até piloto encenar ou
mesmo uma vez na produção, que são difíceis de medir e muito muitas vezes
não benéfico para o negócio.
4.6.5.4 Compreender o efeito pretendido de uma mudança
Os detalhes do serviço ao cliente a mudança, exigências e Pacote Service
Design devem ser cuidadosamente analisadas para compreender plenamente o
objectivo da mudança e os benefícios esperados a partir de sua implementação.
Os exemplos podem incluir: reduzir custar de executar o serviço, Aumentar o
serviço atuação, Reduzir recursos obrigadas a operar o serviço, ou melhorar o
serviço capacidade.
A documentação mudança deve fazer medidas claras o que o efeito pretendido
da mudança será e específicas que devem ser usados para determinar eficácia
dessa mudança. Se eles são de alguma forma obscura ou ambígua a avaliação
deve cessar e uma recomendação para não prosseguir deve ser encaminhado
para Gestão da Mudança.
Mesmo algumas mudanças deliberadamente projetados pode ser prejudicial
para alguns elementos do serviço. Por exemplo, a introdução de SOX-
compatível procedimentos, o qual, ao mesmo tempo oferece o benefício de legal
observância, Introduzir etapas de trabalho e custos suplementares.
4.6.5.5 Compreender o efeito não intencional de uma mudança
Para além dos efeitos esperados sobre o serviço e mais amplos organização
não são susceptíveis de ter efeitos adicionais que não eram esperados ou
planejado. Estes efeitos podem também ser revestidos e considerou que o
impacto total de uma serviço mudança é para ser compreendido. Uma das

maneiras mais eficazes de identificação de tais efeitos é pela discussão com
todos das partes interessadass. Não apenas os clientes, mas também dos
usuários do serviço, aqueles que afirmam que, aqueles que financiá-lo, etc
Cuidados devem ser tomados na apresentação dos detalhes da mudança para
garantir das partes interessadass compreender plenamente as implicações e
pode, portanto, fornecer feedback preciso.
4.6.5.6 Fatores para considerar o efeito de uma mudança de serviço
Tabela 4.14 mostra os fatores a serem incluídos quando se considera o efeito de
uma mudança de serviço.
Fator Avaliação de Design de Serviços
S - Provedor de
serviços
capacidade
A capacidade de um fornecedor de serviços ou a unidade de serviço de
realizar, conforme necessário.
T - Tolerância A capacidade ou capacidade de um serviço de absorver a mudança de
serviço ou de liberação.
O - ambiente
organizacional
A capacidade de um organização a aceitar a mudança proposta. Por
exemplo, é o acesso adequado disponível para a equipe de
implementação? Ter todos os serviços existentes que seriam afetados
pela mudança foi atualizado para garantir uma transição suave?
R - Recursos O disponibilidade de pessoas devidamente qualificadas e experientes,
finanças, infra-estrutura suficientes aplicaçãos e outros recursos
necessários para executar os seguintes serviços transição.
M - Modelagem e
medição
A medida em que as predições de comportamento gerados a partir do
modelo coincidir com o comportamento real do serviço novo ou alterado.
P - As pessoas As pessoas dentro de uma sistema e o efeito das alterações neles.
U - Use Será que o serviço seja adequado para o uso? A capacidade de fornecer
as garantias, por exemplo, continuamente disponível, há capacidade
suficiente, é que vai ser seguro o suficiente?
P - Finalidade Será que o novo serviço ou alterados ser apto para o efeito? Pode o
necessário atuação ser apoiado? Será que as restrições ser removido
como planejado?
Tabela 4.14 Fatores para considerar os efeitos de uma mudança de serviço
4.6.5.7 Avaliação de desempenho previsto
Usando cliente exigências (incluindo critérios de aceitação), o desempenho
previsto e do modelo de desempenho, um avaliação de risco é levada a cabo.
Se a avaliação de risco sugere que o desempenho previsto pode criar riscos
inaceitáveis a partir da mudança ou não atender aos critérios de aceitação, um
interino avaliação relatório é enviado para alertar Gestão da Mudança.

O relatório de avaliação intercalar inclui o resultado da avaliação de risco e / ou
o resultado do desempenho previsto contra critérios de aceitação, juntamente
com uma recomendação de rejeitar a mudança de serviço em sua forma atual.
As actividades de avaliação cessar neste momento pendente de decisão da
4.6.5.8 Avaliação de desempenho real
Uma vez que a mudança de serviço foi implementado um relatório sobre real
atuação é recebido a partir de operações. Usando requisitos do cliente (incluindo
critérios de aceitação), o desempenho real eo desempenho modelo, Uma
avaliação de risco é realizada. Novamente, se a avaliação de risco sugere que o
desempenho real é criar riscos inaceitáveis, um interino avaliação relatório é
enviado para Gestão da Mudança.
O relatório de avaliação intercalar inclui o resultado da avaliação de risco e / ou
o resultado do desempenho real versus critérios de aceitação, juntamente com
uma recomendação para remediar a mudança de serviço.
As actividades de avaliação cessar neste momento pendente de decisão da
4.6.5.9 A gestão de risco
Existem duas etapas gestão de risco: Avaliação de risco e mitigação. Risco
avaliação preocupa-se com a análise ameaças e os pontos fracos que tenham
sido ou possam ser introduzida como resultado de uma mudança de serviço.
Arisco ocorre quando uma ameaça pode explorar uma fraqueza. A probabilidade
de ameaças que exploram uma fraqueza, eo impacto se o fizerem, são os
fatores fundamentais na determinação do risco.
O gestão de risco fórmula é simples, mas muito poderosa:
Risco Probabilidade = x Impacto
Obviamente, a introdução de novas ameaças e fraquezas aumenta a
probabilidade de uma ameaça explorar uma fraqueza. Colocar uma maior
dependência de um serviço ou componente aumenta o impacto se uma ameaça
existente explora uma fraqueza existente dentro do serviço. Estes são apenas
alguns exemplos de como o risco pode aumentar como resultado de uma
mudança de serviço.

É uma clara exigência que uma mudança serviço proposto deve avaliar os riscos
existentes dentro de um serviço e os riscos previstos após a realização da
mudança.
Se o nível de risco aumentou em seguida, a segunda fase de gestão de risco é
utilizada para minimizar o risco. Nos exemplos dados acima atenuação pode
incluir medidas para eliminar uma ameaça ou fraqueza e usando desastre
recuperação e apoio Técnicas para aumentar o resiliência de um serviço em que
o organização tornou-se mais dependente.
Seguindo o nível de atenuação do risco é re-avaliado e comparado com o
original. Esta segunda avaliação e de quaisquer avaliações subseqüentes estão
em vigor a determinação do risco residual - o risco que permanece após a
mitigação. A avaliação do risco residual e mitigação associado ao ciclo continua
até que o risco é administrado para baixo a um nível aceitável.
O princípio orientador aqui é que, ou a avaliação do risco inicial ou de qualquer
nível de risco residual é igual a ou menor do que o risco inicial antes da
mudança de serviço. Se este não for o caso, a avaliação vai recomendar a
rejeição da mudança serviço proposto, ou desistir de uma mudança de serviço
implementado.
A abordagem à representação risco recomendado aqui tem uma abordagem
fundamentalmente diferente. Com base no trabalho de Drake (2005a, 2005b),
esta abordagem reconhece que os riscos quase sempre crescer
exponencialmente ao longo do tempo se não for gerenciado, e que o risco de
que não vai causar uma perda provavelmente não vale a pena se preocupar
demais.
Assim, é proposto que uma representação mais forte risco é como mostrado na
Figura 4.35. Principalmente, esta representação tem a intenção de promover o
debate e acordo pelas partes interessadas: é o risco posicionado corretamente
em termos de tempo e perda de potencial ou real; poderia mitigação foram
implantados mais tarde (por exemplo, mais economicamente); deveria ter sido
implantado anteriormente (por exemplo, uma melhor proteção), etc

Figura 4.35 Exemplo perfil de risco
Desvios - previu vs desempenho real
Uma vez que a mudança de serviço passa o avaliação do previsto atuação e o
desempenho real, essencialmente como as avaliações independentes, uma
comparação entre os dois é executado. Ter chegado a este ponto, terá sido
determinado que previu o desempenho real são aceitáveis, e que não há riscos
inaceitáveis. A saída desta atividade é um relatório de desvios. Para cada fator
na Tabela 4,14 o relatório indica a extensão de qualquer desvio entre o
desempenho previsto e real.
Plano de teste e resultados
O teste função proporciona os meios para a determinação do desempenho real
da aplicação seguinte de serviço de um serviço de mudança. Teste fornece a
função de avaliação de serviços com o teste plano e um relatório sobre os
resultados de qualquer teste. Os resultados reais também estão disponíveis para
avaliação do serviço. Estes são avaliados e usados como descrito no parágrafo
4.6.5.8.
Em algumas circunstâncias, é necessário apresentar uma declaração dos
qualificação e / ou validação estado sequência de uma mudança. Isso acontece
em regulamentado ambientes, tais como os produtos farmacêuticos e de defesa.
O contexto para estas actividades é apresentada na Figura 4.36.

Figura 4,36 contexto para atividades de qualificação e validação
As entradas para essas atividades são a qualificação plano e os resultados e /
ou validação plano e resultados. A avaliação processo assegura que os
resultados se encontrarem dentro do exigências dos planos. Uma declaração de
qualificação e / ou validação é fornecida como saída.
4.6.6 Relatório de avaliação
O relatório de avaliação contém as seguintes seções.
Perfil de risco
Uma representação do residual risco à esquerda após uma mudança foi
implementada e depois contramedidas foram aplicadas.
Desvios denunciar
A diferença entre o desempenho previsto e real após a implementação de uma
mudança.
Uma declaração de qualificação (se for o caso)
Seguido rever de qualificação teste resultados e plano de qualificação, a
declaração da existência ou não a mudança deixou o serviço em um estado no
qual não poderia ser qualificado.
Uma declaração de validação (se for o caso)
Após a revisão de resultados de testes de validação e do plano de validação,
uma declaração de haver ou não a mudança deixou o serviço em um estado no
qual não poderia ser validado.
Uma recomendação
Com base em outros factores dentro do avaliação relatório, uma recomendação
ao Gestão da Mudança para aceitar ou rejeitar a mudança:

• Comente e fechar transição
4.6.7 Triggers, entradas e saídas e as interfaces entre processos
Triggers:
• Pedido de Avaliação de Transição de Serviço gerente ou Gestão da
Mudança
• Atividade em Projeto Plano.
Entradas:
• SDP e SAC
• Os resultados do teste e relatório.
Saídas:
• Relatório de avaliação de Gestão de Mudança.
• SDP, SAC
• Os resultados do teste e relatório
• Relatório de avaliação.
O cliente/ KPIs do negócio são:
• Variação de serviço atuação exigido pelos clientes (mínimo e reduzindo)
• Número de incidentes contra o serviço (baixo e redução).
Os KPIs internos incluem:
• Número de projetos fracassados que foram a transição (zero)
• O tempo de ciclo para executar uma avaliação (Baixo e redutores).
4.6.9.1 Desafios
Os desafios incluem:

• Desenvolvimento de medidas de desempenho padrão e métodos de
medição em todo projetos e fornecedors
• Projetos e fornecedores estimar datas de entrega imprecisa e causando
atrasos na programação de atividades de avaliação
eficaz gestão de risco para as actividades de avaliação
• Compreender e ser capaz de avaliar, o equilíbrio entre gestão risco e
assumir riscos, pois afeta a geral estratégia do organização e prestação
de serviços
• Medir e expor menos variação em previsões durante e depois transição
• Tomando uma abordagem pragmática e de medição para arriscar
• Comunicando a atitude da organização de risco e abordagem gestão de
risco efetivamente durante a avaliação de risco
ou podem impactar sucesso Transição de Serviço de serviços e
lançamentos
informações.

4,7 Gestão do Conhecimento
A capacidade de fornecer um qualidade serviço ou processo repousa em grande
medida, da capacidade dos envolvidos para responder às circunstâncias - e que
por sua vez se baseia fortemente em sua compreensão da situação, as opções
e as conseqüências e benefícios, ou seja, o seu conhecimento da situação em
que estão, ou podem encontrar-se , dentro do conhecimento Que dentro do
Transição de Serviço domínio podem incluir:
• Identidade de das partes interessadass
• Aceitáveis os níveis de risco e expectativas de desempenho
• Disponível recurso e prazos.
A qualidade ea relevância do conhecimento repousa por sua vez sobre a
relevância da qualidade, acessibilidade e continuada dos dados que sustentam e
informações disponíveis para serviço pessoal.
O objectivo da Gestão do Conhecimento é garantir que a informação correta
seja entregue para o local apropriado ou pessoa competente no momento certo
para permitir decisão informada.
O objetivo da Gestão do Conhecimento é capacitar as organizações a melhorar
a qualidade da tomada de decisões, garantindo que a informação confiável e
segura de dados e está disponível durante todo o ciclo de vida do serviço.
O objetivos de Gestão do Conhecimento incluem:
• Ativando o provedor de serviços para ser mais eficiente e melhorar a
qualidade do serviço, aumentar a satisfação e reduzir o custar de serviço
• Assegurar que o pessoal tem um entendimento claro e comum do valor
que seus serviços oferecem aos clientes e as maneiras em que os
benefícios são obtidos com a utilização desses serviços
• Assegurar que, em um determinado momento e local, o pessoal prestador
de serviços tem informações adequadas sobre:
• Quem está usando seus serviços
• Os estados atuais de consumo
• Entrega restrições de serviço
• Dificuldades enfrentadas pelo cliente em realizar plenamente os
benefícios esperados do serviço.
4.7.2 Âmbito
Gestão do Conhecimento é um todo ciclo de vidaDe largura processo na medida
em que é relevante para todos os setores do ciclo de vida e, portanto, é

referenciado em toda ITIL a partir da perspectiva de cada publicação. Ele é
tratado em algum grau dentro de outros ITIL publicações, mas este capítulo
define o conceito básico, a partir de um foco Transição de Serviço.
4.7.2.1 Inclusões
Gestão do Conhecimento inclui a supervisão da gestão do conhecimento, a
informação e os dados a partir do qual o conhecimento deriva.
4.7.2.2 Exclusões
Atenção detalhada para a captura, manutenção e uso de ativos e dados de
configuração é definido na Seção 4.2.
Gestão do Conhecimento é especialmente significativa dentro Transição de
Serviço já que o conhecimento relevante e adequada é um dos elementos-chave
de serviços sendo transitaram. Exemplos onde sucesso transição repousa sobre
Gestão do Conhecimento apropriado incluem:
• Usuário,balcão de atendimento, Pessoal de apoio e fornecedor a
compreensão do novo serviço ou alterados, incluindo o conhecimento do
erros assinado antes desenvolvimento, Para facilitar os seus papéis
dentro desse serviço
• A conscientização do uso do serviço, ea interrupção do anterior versãos
• Estabelecimento do aceitável risco e os níveis de confiança associados a
transição, E.g. medir, compreender e agir corretamente em resultados
dos testes e resultados de garantia de outros.
Eficaz Gestão do Conhecimento é um recurso poderoso para pessoas de todas
as funções em todas as fases do serviço ciclo de vida. É um excelente método
para indivíduos e equipes para compartilhar dados, informações e conhecimento
sobre todos os aspectos de uma De serviços de TI. A criação de uma única
sistema de Gestão do Conhecimento é recomendado.
Aplicação específica para o domínio de Transição de Serviço pode ser ilustrado
através de considerar os seguintes exemplos:
• Desfocando do conceito de propriedade intelectual e informações quando
engajados na terceirização e parcerias, portanto, novas abordagens para
o controle de "conhecimento" deve ser tratada e gerida durante Transição
de Serviço
• Transferência de conhecimento, muitas vezes sendo um fator crucial para
facilitar a transição eficaz de serviços novos ou alterados e essencial para
operacional prontidão

• Formação de usuários, pessoal de apoio, fornecedors e outros das partes
interessadass em serviços novos ou alterados
• Gravação de erros, culpas, solução alternativas etc detectados e
documentados durante a Transição de Serviço fase
• Captura de implementação e teste de informações
• Reutilizando anteriormente desenvolvido e qualidade assegurou testes,
treinamento e documentação
• Observância com legislativo exigências, por exemplo, SOX, e
conformidade com padrãos tais como ISO 9000 e ISO / IEC 20000
• Auxiliar decisões sobre se aceita ou prosseguir com itens e serviços,
fornecendo toda a informação relevante (e omitindo informações
desnecessárias e confusas) para os principais decisores.
4.7.4.1 A estrutura de dados-para-Informação-para-Conhecimento-para-
Sabedoria
Gestão do Conhecimento normalmente é exibido dentro do Dados para-
Informação-para-Conhecimento-para-Sabedoria (DIKW) estrutura. O uso desses
termos é apresentada a seguir.
Dados é um conjunto de fatos discretos sobre eventos. A maioria das
organizações capturar grandes quantidades de dados em bancos de dados
altamente estruturados, tais como Serviço de Gestão de e Gerenciamento da
Configuração ferramentas /sistemas e bancos de dados.
As atividades-chave da Administração Conhecimento em torno de dados são a
capacidade de:
• Capturar dados precisos
• Analisar, sintetizar e, em seguida, transformar os dados em informações
• Identificar os dados relevantes e se concentrar recursos na sua captura.
Informações vem de fornecer o contexto para dados. As informações são
normalmente armazenados em semi-estruturada conteúdo, como documentos,
e-mail e multimídia.
A chave Gestão do Conhecimento atividade em torno da informação está a gerir
o conteúdo de uma forma que torna mais fácil a captura, consultar, encontrar,
reutilizar e aprender com as experiências de modo que os erros não se repitam
eo trabalho não é duplicado.
Conhecimento é composto de experiências tácitas, idéias, percepções, valores
e julgamentos dos indivíduos. Pessoas adquirir conhecimento tanto da sua

própria experiência e de seus pares, bem como a partir da análise da informação
(e dados). Através da síntese destes elementos, o conhecimento novo é criado.
O conhecimento é dinâmico e contexto baseado. Conhecimento coloca a
informação em um "facilidade de utilização" forma, o que pode facilitar a tomada
de decisão. Em Transição de Serviço esse conhecimento não é somente com
base na transição em andamento, mas é recolhida a partir da experiência de
transições anteriores, a consciência de mudanças recentes e antecipada e
outras áreas que o pessoal experiente terá sido inconscientemente coleta por
algum tempo.
Sabedoria dá o discernimento final do material, e tendo a aplicação e
sensibilização contextual para proporcionar um entendimento do senso comum
forte.
Isto é mostrado na Figura 4.37.
Figura 4.37 O fluxo de dados a sabedoria
4.7.4.2 O serviço de sistema de gestão do conhecimento
Especificamente dentro IT Service Management, Gestão do Conhecimento vai
ser focado dentro do Serviço do Sistema de Gestão do Conhecimento (SGCS)
em causa, como o próprio nome indica, com o conhecimento. Subjacente a este
conhecimento será uma quantidade considerável de dados, que será realizada
em um repositório central lógica ou Sistema de Gerenciamento da Configuração
(CMS) e Configuration Management Database (CMDB). No entanto, claramente
o SKMS é um conceito mais amplo, que abrange uma base muito mais ampla do
conhecimento, por exemplo:

• A experiência da equipe
• Registros de assuntos periféricos, por exemplo, tempo, usuário números
e de comportamento, organização'S atuação figuras
• Fornecedors 'e parceiros exigências, habilidades e expectativas
• Níveis de habilidade típicos e antecipada do usuário.
Figura 4.38 é uma ilustração muito simplificada do relação dos três níveis, sendo
os dados recolhidos no CMDB, e alimentando através do CMS nas SKMS e
apoiar a tomada de decisão informada processo.
Figura 4.38 Relação do CMDB, o CMS e os SKMS
4.7.5.1 estratégia de Gestão do Conhecimento
Um total estratégia para Gestão do Conhecimento é necessária. Onde há uma
abordagem organizacional para a Gestão do Conhecimento, iniciativas dentro
Transição de Serviço,IT Service Management ou outros grupos devem ser
projetados para caber dentro da abordagem global da organização.
Na ausência de uma abordagem organizacional Gestão do Conhecimento, as
medidas necessárias para estabelecer a Gestão do Conhecimento dentro de
Transição de Serviço ou dentro IT Service Management será necessário. Mas,
mesmo neste caso desenvolvimentos devem sempre ser estabelecidas com
vista à tão grande como extensão de um praticável de Gestão do Conhecimento
- que cobre o pessoal de TI direta, os usuários, terceiro apoio e outros que
possam contribuir ou fazer uso benéfico do conhecimento.
A estratégia - ou no lugar no espaço organização ou em desenvolvimento -
incidirá sobre:

• O governo modelo
• Mudanças organizacionais mudanças em curso e planeadas e
conseqüentes papéis e responsabilidades
• Estabelecer funções e responsabilidades e de financiamento em curso
• Políticas, processos procedimentos e métodos para a Gestão do
Conhecimento
• Tecnologia e outros recurso exigências
• Atuação medidas.
Captura de conhecimento identificação e manutenção
Especificamente, o estratégia irá identificar e plano para a captura de
conhecimento relevante e as informações conseqüentes e dados que a
suportam. Os passos para a entrega deste incluem:
• Ajudar uma organização a identificar o conhecimento que será útil
• Projetando uma sistemática processo para a organização de informações,
destilação, armazenamento e apresentação de uma forma que melhora a
compreensão das pessoas em uma área relevante
• Acúmulo de conhecimento através de processos e fluxo de trabalho
• Geração de novos conhecimentos
• Acessando valioso conhecimento de fontes externas
• Captura de conhecimento externo e adaptando-lo - dados, informações e
conhecimento de diversas fontes, tais como bancos de dados, sites,
funcionários, fornecedors e parceiros.
4.7.5.2 A transferência de conhecimento
Durante o serviço ciclo de vida uma organização precisa de se concentrar em
recuperar, compartilhar e utilizar seus conhecimentos através de problema
resolução de aprendizagem, dinâmico, estratégico planejamento e tomada de
decisão. Para conseguir isto, o conhecimento necessário para ser transferido
para outras partes do organismo, em pontos específicos no ciclo de vida. Muitos
dos Serviço de Gestão de processos vai ligar para isso, por exemplo, permitindo
que o balcão de atendimento ter conhecimento e compreensão ideal no ponto
para qualquer Transição de Serviço em apoio. Eles serão dependente da
informação proveniente de gerenciamento de liberação tal como erro conhecidos
de entrar em produção, mas que não são rolhas de mostrar para o liberar
agendar, ou erro conhecido scripts a partir de qualquer um dos suporte técnico
equipes. Ligações com RH, instalações e outros serviços de apoios precisam ser
estabelecidas, mantidas e utilizadas.
O desafio é, muitas vezes o problema prático de conseguir um pacote de
conhecimento a partir de uma parte do organização para outras partes do
organização. É mais do que apenas o envio de um e-mail! A transferência de
conhecimento é mais complexo, mais precisamente, é o atividade através do

qual uma unidade (por exemplo, um grupo, departamento ou divisão) é afetada
pela experiência do outro. Sua forma deve ser aplicável para aqueles que usá-lo,
e conseguir uma classificação positiva de "facilidade de utilização". A
transferência de conhecimento pode ser observado através de mudanças no
conhecimento ou atuação dos receptores, a um indivíduo ou nível de unidade.
Uma análise das lacunas de conhecimento (se houver) dentro da organização
deve ser realizada. A diferença terá de ser pesquisado e estabelecido pela
investigação direta do entendimento pessoal de conhecimento exigências para
eles para entregar as suas responsabilidades em relação com o seu
conhecimento real observado. Esta pode ser uma tarefa difícil para entregar
objetiva e, ao invés de ressentimento risco ou suspeita, é muitas vezes vale a
pena procurar apoio especializado e experiente para construir isso. A saída do
exercício lacunas de conhecimento irá formar a base para uma melhoria
comunicações plano o que permitirá planejamento e medição de sucesso na
comunicação do conhecimento.
Tradicionalmente a transferência de conhecimento tem sido baseada em sala de
aula formal e documentação. Em muitos casos, a formação inicial é fornecida a
um representante de um grupo de trabalho que é, então, obrigado a cascata o
conhecimento para seus colegas de trabalho. Outras técnicas são muitas vezes
apropriada e formar ferramentas úteis no arsenal Transição de Serviço. Técnicas
vale a pena considerar incluem o seguinte.
Estilos de aprendizagem
Diferentes pessoas aprendem de diferentes maneiras, e o melhor método de
transferir e de manutenção do conhecimento dentro da Serviço de Gestão de e
usuário comunidade terá de ser estabelecida. Estilos de aprendizagem variam
com a idade, cultura, Atitude e personalidade. A equipe de TI pode ser útil
lembrar, especialmente quando eles estão apoiando os usuários de um estilo de
trabalho diferente, por exemplo, gráficos projeto, Os artistas, as equipes de
vendas, que o fato de um mecanismo de transferência de conhecimento
funciona para eles, pode não ser adequado para a sua base de usuários atual.
Para alguns elementos muitos de "hands-on" experiência é um apoio positivo
para o aprendizado, e exercícios de simulação pode ser uma consideração útil,
ou experiência supervisionada e experimentação.
Visualização conhecimento
O objectivo é melhorar a transferência de conhecimento usando computador e
não baseados em computador recursos visuais, tais como diagramas, imagens,
fotografias e storyboards. Centra-se na transferência de conhecimento entre as
pessoas e visa transferir conhecimentos, experiências, atitudes, valores,
expectativas, perspectivas, opiniões e previsões usando várias visualizações

complementares. Formas dinâmicas de visualização como animação educativo
têm o potencial de melhorar a compreensão dos sistemas que a mudança ao
longo do tempo. Por exemplo, este pode ser particularmente útil durante uma
actualização de hardware, quando a localização de uma componente pode
mudar em um item, embora a funcionalidade não altera.
Comportamento de condução
Transferência de conhecimento tem como objetivo garantir que os funcionários
são capazes de decidir sobre as ações corretas para entregar suas tarefas em
quaisquer circunstâncias previsíveis. Para tarefas previsíveis e consistentes, o
procedimento pode ser incorporado dentro de ferramentas de software que o
pessoal usar dentro dessas tarefas. Estes procedimentos, em seguida, dirigir
comportamento na maneira aceitável. Mudar processo modelos (ver Figura 4.2)
e balcão de atendimento scripts são excelentes exemplos. Isto inclui a
capacidade de reconhecer quando as práticas estabelecidas são ou podem ser
inadequado, por exemplo em circunstâncias inesperadas, quando a equipe irá
abandonam as regras estabelecidas quando não entregar, conforme necessário,
ou então vai agravar a situação.
Seminários, Seminários e publicidade
Formalmente o lançamento de um novo ou alterado serviço pode criar um
'evento'Que aumenta a transferência de conhecimento. Eventos de base
tecnológica, como Webinars oferecem a possibilidade de oferecer um elevado
perfil de mecanismo de entrega de conhecimento com a capacidade de reter-lo
online e entregá-lo posteriormente para outros locais e pessoal de novo. Portais
de internet e intranet pode entregar mensagens de equivalentes de uma forma
contínua e permitir fóruns de discussão para questionar e desenvolver
conhecimento.
Revistas e boletins
Canais regulares de comunicação, uma vez estabelecidas, são úteis em permitir
que o conhecimento a ser transferidos em unidades menores - de forma
incremental, em vez de "big bang" pode ser mais fácil de absorver e reter. Eles
também permitem a formação progressiva e adaptação a períodos circunstância
e tempo. Fundamentalmente estas técnicas podem ser feitas divertido e
orientadas para grupos específicos.
Voltado para o público
Um estoque controlar sistema foi introduzido com o pessoal nos armazéns
diretamente introduzir e trabalhar com o novo sistema. Inicialmente toda a
documentação foi formal e escrito em semi-termos técnicos eo pessoal ensinado
como usar o sistema através de formação tradicional e coaching. Assim que o

sistema tinha estabelecido em um boletim mensal foi planejado para manter a
equipe ciente das mudanças, melhorias, sugestões, dicas etc O primeiro versãos
foram, novamente, formal e dirigida apenas a informação necessária. Ele
rapidamente se tornou claro que o conhecimento necessário não estava no lugar
dentro da equipe. Sucesso seguido quando as atualizações evoluiu para um
boletim genuína - entre competições, fotos de férias, bem-humorado e até
mesmo artigos satíricos do exigido usuário conhecimento foi transferido muito
mais sucesso. A lição foi a de que, visando comunicações com precisão a um
público conhecido e compreendido, e tornar a experiência agradável, o
conhecimento necessário transfere junto com o resto. E como um bônus da
equipe contribuiu com artigos de entretenimento e dicas e sugestões que haviam
evoluído.
4.7.5.3 Gestão de dados e informações
Conhecimento repousa sobre a gestão das informações e dados que a sustenta.
Para ser eficaz neste processo requer uma compreensão de alguns chave
processo insumos, como a forma como os dados e informações serão utilizadas:
• O conhecimento é necessário com base no que as decisões devem ser
feitas
• Que condições precisam ser monitorados (alteração das circunstâncias
externas e internas, que vão desde demanda do usuário final, legal
exigências até a previsão do tempo)
• Os dados que estão disponíveis (o que poderia ser capturado), bem como
a rejeição de dados possíveis capturar como inviável; esta entrada pode
desencadear justificação das despesas ou mudanças nas práticas de
trabalho, concebidos para facilitar a captura de dados relevantes, que de
outra forma não estar disponíveis
• O custar de captação e manutenção de dados, eo valor que os dados é
susceptível de trazer, tendo em conta o negativo impacto sobrecarga de
dados na transferência de conhecimentos eficaz
• Políticas, legislação, padrãos e outros requisitos
• Propriedade intelectual direitos e questões de direitos autorais.
Dados de sucesso e gestão da informação vai entregar:
• Conformidade com os requisitos legais e outros, por exemplo, companhia
política, Códigos de conduta profissional
• Formas definidas de dados e informações de uma forma que é facilmente
utilizável pelo organização
• Dados e informações que é atual, completa e válida
• Dados e informações descartados como exigido
• Dados e informações para as pessoas que precisam, quando precisam.
Dados que comprovem e requisitos de informação

As seguintes atividades devem ser planejadas e implementadas de acordo com
as políticas da organização e aplicáveis procedimentos em relação aos dados e
processos de gestão de informação. Este plano e projeto é da responsabilidade
do Estratégia de Serviço e Design de Serviços.
Muitas vezes, os dados e as informações são coletados sem um entendimento
claro de como ela será usada e isso pode ser caro. Eficiência e eficácia são
entregues ao estabelecer a exigências para informação. Considerações
sensíveis, dentro dos limites determinados como descrito acima, pode incluir:
• Estabelecer os itens designados de dados e informações, o seu conteúdo
e forma, juntamente com a razão, por exemplo, técnica, projeto,
Organizacional, Serviço de Gestão de processo,acordo, Operações e
informações; dados é caro para coletar e muitas vezes até mais caro para
manter, e assim devem ser coletadas apenas quando necessário
• Incentivar o uso de conteúdo comum e uniforme e requisitos de formato
para facilitar a compreensão melhor e mais rápido do conteúdo e ajudar
no gerenciamento consistente dos dados e informações recursos
• Estabelecer os requisitos para proteção de dados, privacidade,
segurança, Propriedade, restrições acordo, direitos da propriedade, o
acesso intelectual e patentes com a relevante das partes interessadas
• Definir quem precisa de acesso a quais dados e informações, bem como
quando acessá-lo, incluindo a importância relativa de que em momentos
diferentes. Por exemplo, o acesso às informações da folha de pagamento
pode ser considerado mais importante no dia antes da folha de
pagamento é executado do que em outras épocas do mês
• Considerando todas as alterações à Gestão do Conhecimento processo
através do Gestão da Mudança.
Definir a arquitetura da informação
A fim de fazer uma utilização eficaz dos dados, em termos de fornecer o
conhecimento necessário, uma relevante arquitetura combinado com a situação
organizacional e os requisitos de conhecimentos é essencial. Isto por sua vez
repousa sobre:
• Criar e atualizar regularmente um Serviço de Gestão de informação
modelo que permite a criação, uso e compartilhamento de informações
que é flexível, oportuna e rentável
• Sistemas que definem otimizar a utilização da informação mantendo
dados e informações integridade
• Adotando dados classificação esquemas que estão em uso em todo o
organizaçãoE, se necessário mudanças de negociação para permitir-lhes
a entrega no Serviço de Gestão de área, onde tal em toda a organização
(ou cadeia de suprimentos ou esquemas da indústria do setor) não
existem sistemas de classificação de dados derivados para uso dentro

Serviço de Gestão de deve ser concebido com a intenção de sua
aplicável sendo toda a organização para facilitar o apoio para o futuro de
toda a organização Gestão do Conhecimento.
Um exemplo de uma arquitectura de informação, de conhecimento e de dados é
mostrado na Figura 4.39.
Figura 4.39 Serviço de sistema de gestão do conhecimento
O estabelecimento de dados e procedimentos de gestão de informação
Quando o exigências e arquitetura foram criadas, gestão de dados e
informações para apoiar Gestão do Conhecimento pode ser estabelecido. Os
principais passos necessários envolvem a criação de mecanismos para:
• Identificar os dados de serviços de ciclo de vida e informações que devem
ser recolhidas
• Definir o procedimento necessário para manter os dados e informações e
torná-lo disponível para os que exigem que
• Armazenar e recuperar

• Estabelecer a autoridade e responsabilidade para todos os itens de
informação necessários
• Definir e publicitar direitos, Obrigações e compromissos em relação à
retenção de, transmissão e acesso a itens de informações e dados com
base em aplicável exigências e protegendo a sua segurança, Integridade
e consistência
• Estabelecer adequada apoio e recuperação de dados e informações, o
que deve resolver restabelecendo a capacidade de fazer uso construtivo
de informações, não apenas o re-estabelecimento de um banco de dados
• Identificar os requisitos para análise, à luz da evolução tecnológica, os
requisitos organizacionais, evoluindo política e legislação (e, se
necessário, para se adaptar a) alterações nas:
• informação sistema infra-estrutura à luz da evolução do hardware e
software de tecnologia
• segurança, continuidade de serviços, armazenamento e
capacidade
• Lidar com requisitos de recolha e retenção.
Quando o procedimentos são projetados, promulgada e aceitou a organização
pode:
• Implementar mecanismos para capturar, armazenar e recuperar os dados
identificados a partir das fontes relevantes
• Gerenciar o armazenamento de dados e informações e movimento,
especialmente de acordo com a legislação pertinente.
• Archive designado informação, de acordo com os dados e de gestão de
informação plano incluindo a eliminação segura de informações
indesejadas, inválida ou não verificável de acordo com a organização
política.
Avaliação e melhoria
Como em todos os processos, a captura eo uso de dados e informações para
apoiar Gestão do Conhecimento e tomada de decisão requer atenção para
melhoria contínua, eo plano de melhoria do serviço terá como entrada relevante:
• Medição da utilização dos dados e informações de gerenciamento de
dados transaçãos
• Avaliação da utilidade dos dados e informação - identificado por
relevância relatórios produzidos
• Identificação de quaisquer dados ou informações registradas ou usuários
que já não parecem relevantes para o organização"Conhecimento s
exigências.
4.7.5.4 Usando o serviço de sistema de gestão do conhecimento

Prestação de serviços aos clientes através de fusos horários, ciclos de trabalho,
e geografias requer a partilha de conhecimento bom em todos os locais e
períodos de tempo de Operação de Serviços. A provedor de serviços primeiro
deve estabelecer uma serviço de sistema de gestão do conhecimento que pode
ser compartilhado, atualizado e utilizado por entidades operacionais, parceiros e
clientes. Figura 4.39 apresenta um exemplo da arquitetura para tal sistema.
Implementação de um sistema de gerenciamento de serviços de conhecimento
ajuda a reduzir os custos de manutenção e gestão dos serviços, tanto pelo
aumento da eficiência de operacional gestão procedimentos e reduzindo os
riscos que surgem da falta de mecanismos adequados.
Estudo de caso
Situação atual Uma organização analisado que, pelo menos, 75% do custar
de entregar apoio vem de resolver cliente questões. Foi utilizando tecnologias
pontuais, tais como a balcão de atendimento ferramenta de fluxo de trabalho,
motores de busca, ferramentas de script ou simples base de conhecimentos.
Esses sistemas geralmente peças focadas da resolução processo e eles não
eram muito eficazes. Isso contribuiu para que os clientes insatisfeitos, resultou
em um balcão de atendimento ineficaz e causou problemas de integração de TI.
Solução A SKMS abrangentes foi implementado para ajudar a enfrentar
esses obstáculos através da combinação de busca inteligente e Gestão do
Conhecimento com Serviço de Gestão de e processo de negócio apoio, fluxos
de trabalho e abrangente de auto-atendimento instalações.
Os SKMS foi apoiado pelo Gerenciamento de Problemas e Gestão da Mudança
processo.
A experiência de extremidade usuários que vêm para o site de ajuda foi
melhorado dramaticamente. Em vez de uma caixa de pesquisa vazia seguido
por nenhum resultado ou longe demais, o aplicativo leva o usuário por meio de
um conjunto estruturado de passos. Com base nas especificidades do incidente
ou solicitação eo cliente, telas web vai orientar os usuários para respostas
específicas, follow-up perguntas, escalada opções, oportunidades para detalhar
ou resultados de pesquisa apenas altamente relevantes. As seguintes melhorias
foram conseguidas:
• Produtividade dos agentes aumentou
• Reduzida aversão a web self-service
• Escalações menos.

Com o tempo, os fluxos de trabalho da web foram afinado para entregar mais e
mais otimizarexperiências d. Boas experiências ajudaram a agregar valor ao
produto e serviços, e isso resultou em uma maior lealdade que por sua vez
aumentou lucros.
Conclusão A riqueza de informação existe na maioria das organizações que
não é inicialmente pensados para contribuir para o processo de decisão, mas,
quando usado como complemento aos dados de configuração tradicional, pode
levar as lições da história em foco. Muitas vezes, esta informação é de uma
forma informal. Informações de marketing, de vendas do cliente, ea equipe é
uma fonte comumente ignorado dos dados de tendência valiosos que,
juntamente com a configuração tradicional, pode pintar uma imagem maior, mais
significativo da paisagem e descobrir a direita 'correções de curso'Para trazer
um Transição de Serviço ou operacional suporte para um serviço de volta na
pista e manter uma organização de viajar para a sua objetivos. Sem essa visão
clara, a eficácia e diminui eficiência decairá. Ao reconhecer que isso é no lugar,
as organizações podem mais facilmente justificar a recurso os custos da criação
e manutenção dos dados, processos, conhecimentos e habilidades necessários
para torná-lo mais eficaz possível e maximizar os benefícios.
Todo o material de treinamento e conhecimento precisa ser alinhado à
perspectiva de negócios. Materiais que podem ser incluídas são:
• A linguagem de negócio e terminologia e como a TI terminologia é
traduzida
• O processo de negócioes e onde sustenta-los
• Qualquer SLAs, e apoiar acordos e contratos que iria mudar como
resultado do novo Transição de Serviço - Isto é especialmente importante
para o balcão de atendimento analistas cujo alvo de apoio transição será
manter o serviço, se classificaçãos são precisas o que facilitará a todo
processo.
Para aqueles que a Transição de Serviço processo uma boa maneira de
consolidar a compreensão, quer seja para passar o tempo no desenvolvimento
áreas, participando de alguns dos processos de testes, ou para passar o tempo
no negócio no fim de recepção da Transição de Serviço para entender o
processo a partir da perspectiva de negócio.
Materiais úteis incluem:
• Mapas de processo para entender todas as atividades integradas
• Qualquer erro conhecido logs e os solução alternativas - de novo
particularmente importante para o service desk
• Negócios e outros calendários públicos.

Tecnologia para mesas de serviço e clientes serviço precisa para tornar mais
fácil para os clientes, usuários e agentes de service desk. Alguns progressos
mínimos foi feito com genérico Gestão do Conhecimento ferramentas e há
desenvolvimentos significativos no Serviço de Gestão de indústria para
desenvolver maduro, o negócio orientada para o processo aplicaçãos apoiados
por abrangentes base de conhecimentos. Exemplos de benefícios potenciais
são:
• Agente eficiência - O maior componente de ROI de Gestão do
Conhecimento é reduzido incidente manusear o tempo e a produtividade
do agente aumentado.
• Auto-serviço - Um SKMS abrangente oferece ao cliente conhecimento
diretamente no site de suporte. O custar de auto-serviço é uma ordem de
grandeza menor do que o serviço assistida.
4.7.6 Triggers, entradas e saídas e as interfaces entre processos
Crucial para Gestão do Conhecimento é a necessidade de garantir que os
benefícios da Gestão do Conhecimento são compreendidos e abraçou
entusiasticamente dentro de toda a organização. Especificamente, a gestão do
conhecimento eficaz depende do apoio comprometido e entrega pela maioria, se
não todos, dos que trabalham dentro e ao redor IT Service Management.
Operações de Serviço
Erros no interior da serviço detectado durante a transição vai ser registrados e
analisados e os conhecimentos sobre a sua existência, conseqüências e
soluções alternativas serão disponibilizados para Operação de Serviços em um
fácil de usar a moda.
Equipe de operações
• Linha de frente gerenciamento de incidentes pessoal, em balcão de
atendimento e segunda linha de apoio, São o ponto de captura a maior
parte do quotidiano IT Service Management dados. Se esse pessoal não
entende a importância de sua papel em seguida, a Gestão do
Conhecimento não será eficaz. Tradicionalmente analistas de suporte têm
sido relutantes para gravar suas ações, integralmente, achando que isso
pode prejudicar a sua posição dentro da organização - permitindo que
questões a serem resolvidas sem eles. Mudando isto para uma atitude de
apreciar os benefícios - para indivíduos e da organização - de
conhecimento amplamente re-utilizável é a chave para a Gestão do
Conhecimento sucesso.
• Gerenciamento de Problemas equipe será fundamental usuários de
conhecimento coletado e, normalmente responsável pela normalização de

captura de dados por meio de desenvolvimento e manutenção de scripts
de suporte a captura de dados em gerenciamento de incidentes.
Equipe de transição
Transição de Serviço pessoal capturar dados de relevância através de todos
ciclo de vida fases e assim precisa estar ciente da importância da coleta que
precisa e completa. Transição de Serviço da equipe de captura de dados e
informações:
• Relevantes para a adaptabilidade e acessibilidade do serviço conforme o
projeto, a ser alimentado de volta, através de CSI, a Design de Serviços
• 'Correções de curso"E outras adaptações para o projeto necessário
durante transição. Consciência e compreensão desses vai fazer
transições subseqüentes mais fácil.
Uma forte Business Case é crítico para a gestão do conhecimento efectivo e que
é importante que as medidas de sucesso são visíveis para todos os níveis
envolvidos na execução.
Medidas típicas para uma Provedor de serviços de TI"Contribuição s são:
• Implementação bem sucedida e início da vida operação de serviços
novos e alterados com poucos conhecimentos relacionado erros
• Aumento da resposta às demandas empresariais em constante mudança,
por exemplo, maior porcentagem de consultas e pergunta resolvido
através de acesso único à internet / intranet através do uso de pesquisa e
índice sistemas, como o Google
• Melhoria da acessibilidade e gestão de padrãoe as políticas
• Disseminação de conhecimento
• Redução do tempo e esforço necessários para apoiar e manter os
serviços
• Redução do tempo para encontrar informações para diagnóstico e fixando
incidentes e problemas
• Reduzido dependência de pessoal para o conhecimento.
4.7.7.1 Avaliação e melhoria
Apesar de ser difícil de medir o valor do conhecimento, não deixa de ser
importante para determinar o valor para o organização a fim de assegurar o caso
de despesas e de apoio Gestão do Conhecimento é sustentável. Os custos
associados à Gestão do Conhecimento pode ser medido e comparado com esse
valor.

4.7.7.2 Indicadores relevantes para os negócios / clientes
Gestão do Conhecimento é uma que permite processo e assim por
demonstração da sua eficácia precisa de ser inferida a partir de medições
indirectas. Elementos do serviço qualidade que será positivamente influenciado
pela boa gestão de conhecimento pode incluir:
• Redução do 'usuário erro ' categoria de erros devido à transferência de
conhecimentos direcionados, juntamente com custos mais baratos de
treinamento do usuário
• Abaixe incidente,problema e erro resolução vezes influenciado por uma
melhor formação orientada pessoal de apoio e por um relevante, mantido
e acessível base de conhecimento contendo solução alternativas
• Melhoradas as experiências dos clientes, tais como:
• Resolução mais rápida de uma consulta
• A capacidade de resolver problemas diretamente, sem apoio
externo
• Menos transferência de problemas a outras pessoas e resolução
em níveis mais baixos de pessoal
• Redução do tempo de transição e duração de apoio início da vida.
Medindo benefício de transferência de conhecimento
O valor da transferência de conhecimento melhorado durante Transição de
Serviço através de melhor gestão dos conhecimentos pode ser medido através
do aumento eficácia de pessoal com base e apoiar o serviço novo ou alterado.
Este (efectivamente o grau de inclinação da curva de aprendizagem), por sua
vez, pode ser medida por meio de:
• Incidentes tempo e perdeu classificados como "falta de conhecimento do
usuário"
• Média diagnóstico e reparar tempo para culpas fixados in-house
• Incidentes relacionados com serviços novos ou modificados fixado por
referência a base de conhecimento.
Embora nem todos os elementos do acima podem ser diretamente atribuíveis à
Gestão do Conhecimento, As tendências de estas medidas serão influenciadas
pela qualidade de Gestão do Conhecimento, como mostra o exemplo da Figura
4.40.

Figura 4.40 Contribuição do conhecimento para a eficácia do pessoal de apoio
Claramente, o atuação do grupo de apoios transição pós será um fator
determinante da qualidade da transferência de conhecimentos, normalmente
entregues através da formação, no entanto, é mais pró-ativa para verificar a
compreensão antes de chegar a este ponto. Depois de cada peça de
treinamento atividade deve haver um mecanismo de feedback para verificar a
compreensão e qualidade de entrega. Isso pode ser na forma de um
questionário curso de pós, ou até mesmo um teste para confirmar a
compreensão.
4.7.7.3 As medidas directamente relevantes para o prestador de serviços
Indicações da eficácia da Gestão do Conhecimento processo si incluem:
• Uso da base de conhecimento, medido por:
• Número de acessos aos SKMS
• Tempo médio para encontrar materiais
• Erros relatado pelo pessoal ou detectado em auditar (Nenhum
provavelmente significa que ninguém estava usando)
• Envolvimento da equipe na discussão / consulta / resposta fóruns de
apoio através da partilha de conhecimentos e captura de que o
conhecimento compartilhado
• Grau de reutilização dos materiais de documentação, tal como
procedimentos, teste projeto e balcão de atendimento os scripts
• Satisfação com cursos de formação, boletins informativos, briefings web
etc

5 Serviços de Transição comuns atividades de operação
Bem como os processos discutidos no Capítulo 4, Transição de Serviço apoia e
é apoiado por outras atividades. Este capítulo lida com os elementos que são
uma parte essencial, ou um forte contribuinte para, Transição de Serviço. O
capítulo aborda duas atividades específicas que são importantes para a
Transição de Serviço:
• Organizacional e das partes interessadas mudar - Refletindo a natureza
holística do mudar Transição de Serviço, que deve basear-se, as
organizações não transformar a sua De serviços de TI por apenas
mudando os serviços de TI. Inovações modernas significa que a própria
organização também irá inevitavelmente alterar a fazer uso dos serviços
disponíveis novos e alterados.
• Comunicações - Um dos principais pontos fracos tradicionais em
Transição de Serviço tem sido a incapacidade de fornecer compreensão
imediata suficiente das implicações, benefícios e uso de serviços de TI.

5,1 comunicações de gestão e compromisso
A comunicação é fundamental para qualquer mudança Transição de Serviço
processo. Quanto maior a mudança, maior a necessidade de uma comunicação
clara sobre as razões e fundamentos por trás dele, os benefícios esperados, a
planos para a sua implementação e seus efeitos propostos. Comunicações
devem ser orientadas para o público certo e comunicar claramente as
mensagens e os benefícios de forma consistente. Se a honestidade total não é
possível, admitir isso e explicar por que não é possível, por exemplo, para
segurança razões. Compreender o comprometimento das pessoas é importante
antes de planejamento as comunicações.
5.1.1 Comunicações durante Transição de Serviço
Normalmente muitas pessoas são afetadas por uma mudança de serviço e,
consequentemente, suficiente das partes interessadas buy in-é necessário para
levar a transição para a frente com sucesso. É importante estabelecer fase de
um indivíduo dentro do 'ciclo emocional "para compreender o método de
abordagem. É importante identificar:
• Aqueles que já estão em apoio à transição, e de quem não é sensato
gastar tempo agora, uma vez que não precisam de conversão, pois eles
vão ser apanhados na 'aceitação"Fase
• Aqueles que se opõem fortemente, e que seria improvável a responder
positivamente à persuasão. Não é construtivo para se dedicar a essas
pessoas desde o esforço é mais provável de ser recompensado no
momento.
O melhor uso do tempo é concentrar-se nas pessoas que estão entre os dois
extremos, por exemplo, intervenientes capazes de compreender e acolher a
transição. Embora isto pareça óbvio, é comum que as pessoas gastam muito
tempo a falar com aqueles que são simpáticos a uma ideia, uma vez que este é
mais fácil e fornece o feedback positivo que as pessoas tendem a exigir para
alimentar a sua confiança e satisfação no trabalho. Nesta fase, o Transição de
Serviço equipe precisa ser intuitivo para o seu público.
A equipe de Transição de Serviço em breve tornar-se familiar com a
necessidade de mudar as atitudes e os operação de converter cultura. Para
eles, é uma tarefa de rotina, segurando nenhuma ameaça. Pode ser difícil de
lembrar que, para as pessoas afetadas pela mudança, que não é uma situação
normal e eles vão estar preocupado e um entendimento compartilhado vai ajudar
muito.
Exemplo: síndrome de Emergência

Um médico do hospital trabalhando na sala de emergência será usada para
atender pacientes típicos que apresentam sintomas típicos. Assim, em três
horas, o médico, possivelmente depois de muito tempo horas e ao agarrar um
pouco de descanso merecido, é chamado para ver um paciente que é, em sua
mente, apenas outro homem de meia-idade, com fortes dores no peito. Apesar
de rotina e desinteressante para o médico, no entanto um médico bom lembrar
que é a primeira vez que esse homem tem quase morreu de um ataque
cardíaco. O médico não vai deixar a sua familiaridade com a situação e sua falta
de entusiasmo ser evidente. Em vez disso, eles vão corresponder a sua forma
para a de tratar o paciente e a situação com o urgência ea importância que o
cliente espera.
É importante que o serviço os membros da equipe de transição são capazes de
compreender a impacto do seu trabalho sobre os outros e, portanto, adaptar a
sua própria abordagem para a audiência dos interessados. Em última instância,
o objetivo da equipe de transição de serviço é construir entusiasmo e
compromisso com a mudança, enquanto que todos os agentes são claros sobre
como as mudanças afetarão si mesmos, e que se espera deles nos próximos
meses. Limpar os canais de comunicação bidirecional vai ajudar os funcionários
a sentir os seus comentários e idéias são valorizadas.
Stakeholder gestão pode consumir quantidades significativas de trabalho, com
até 50% do esforço pessoal muitas vezes consumida por essa tarefa durante
períodos significativos de mudança organizacional.
5.1.2 Planejamento de Comunicação
Depois de estabelecer as estratégias que promovam facilitadores mudança
positiva, e tendo compreendido o nível de comprometimento dentro da
organização, Transição de Serviço deve garantir que haja uma comunicação
detalhadas plano que terá como alvo as informações onde será mais eficaz.
Ao anunciar a informação durante uma troca de Transição de Serviço, as
seguintes considerações devem ser feitas para cada declaração que você
precisa para se comunicar:
• Como deve ser a informação ser entregue? De uma só vez ou dividido em
segmentos e libertado durante um período de tempo? Se ele vai ser
lançado em segmentos, então o que são os componentes e qual é a
seqüência de tempo para a entrega de mensagens de comunicação?
• Como deve ser a informação ser entregue? (Ver o ponto 4.7.5.2.) O tom
eo estilo da mensagem deve ser transmitida em - otimista, cauteloso,
otimista?
• Que medidas podem ser tomadas antes da comunicação que irá
aumentar a compreensão ea aceitação das informações dadas?

• Como e quando os grupos se envolver durante a cascata da informação e
comunicação para outros níveis da organização?
• São as comunicações de sucesso em superar as barreiras de
comunicação particulares nesta Transição de Serviço (por exemplo,
diferenças culturais, a estrutura adicional de grandes equipes, o adicional
exigências associados com o pessoal geograficamente dispersos)?
• Há consideração para atender às necessidades de comunicação de
outros das partes interessadass no projeto (Por exemplo, os tomadores
de decisão, líderes de opinião sistema usuários, interno e externo órgãos
reguladores, e quaisquer outras pessoas afetadas pela implementação do
novo Transição de Serviço)?
Figura 5.1 mostra uma visão geral dos elementos-chave para consideração
quando planejamento para uma comunicação eficaz.
Figura 5.1 Exemplo de comunicações estratégia e conteúdo do plano
Para garantir que uma comunicação estratégia é eficaz, inquéritos e medidas
devem ser determinadas para regular monitoramento. Isso vai assumir a forma

de feedback das pessoas que tiveram qualquer comunicação. Ele também deve
incluir como as pessoas estão se sentindo em seu "ciclo de mudança" para
estabelecer que a meta é certo. Neste ponto, pode haver indivíduos que são
identificados que devem ter contato mais pessoal da Equipe de Transição de
Serviço para que eles para conseguir um estado aceitável.
Para obter uma valorização da seqüência de eventos, um diagrama de percurso
de comunicação, tais como a que é mostrada na Figura 5.2 ajuda o
planejamento do processo de comunicação.
Figura 5.2 Exemplo de caminho de comunicação
5.1.3 Métodos de comunicação
Usando meios de comunicação múltiplos irá ajudar a compreensão da
mensagem global. Tipos de mídia comuns incluem:
• Grandes oficinas - para entregar uma mensagem clara e consistente para
o público-alvo na geral Transição de Serviço abordagem, o que será
geralmente no início de qualquer comunicação estratégia a fim de

construir a posse, compreensão e até mesmo entusiasmo entre as
equipes
• Boletim organização - para reforçar as mensagens já entregues, no
entanto, o cuidado deve ser tomado para que esta abordagem é usada
como reforço, e não como a primeira vez que os funcionários podem ter
visto a cascata de comunicação
• Sessões de treinamento - como parte da Transição de Serviço, funções
ou processos serão susceptíveis de mudar, o que requer treinamento
específico, que deve ser planejado dar tempo suficiente para que os
funcionários se familiarizar com as novas formas de trabalho
• Reuniões de equipe - dando apoio aos líderes de equipe da equipe de
Transição de Serviço, que irá garantir em suas próprias reuniões
semanais que podem reforçar as mensagens, é nesta reunião nível mais
baixo que as questões que os funcionários têm pode ser melhor
compreendido, como as pessoas vão sentir dentro de sua zona de
conforto, como eles são usados para este método de comunicação com
os colegas que trabalham com diárias
• Cara a cara - os principais interessados para fazer tempo para visitar o
pessoal no ambiente de trabalho (caminhadas de chão), para dar um
exemplo positivo do apoio da alta administração, e permitir que os
funcionários de fazer perguntas pertinentes para si
• Q & A postagens de feedback - placas ou caixas de correio onde os
funcionários podem levantar questões anônimos e receber feedback
sobre quaisquer preocupações que possam ter
• Intranet corporativa
• Memorandos de reforço - memorandos consistentes da sênior das partes
interessadas reforçando informações-chave, ou dar uma atualização
sobre as atividades de implementação, vai manter a Transição de Serviço
vivo para essas pessoas talvez não realmente envolvidas em todas as
fases
• Posters / roteiros - de boa qualidade de comunicação coloridos no final de
pisos de escritórios que mostram as atividades de implementação, o
progresso ou atualizações gerais; estes são uma forma positiva de
manter comunicações vivo e entrega de uma mensagem consistente
• Preste avisos - chave de comunicação ligado a holerites de assegurar a
actualização de comunicação prático de 100%
• 'Z-cards' / cartões de referência encapsulados - pequenas cartão de
crédito documentos de tamanho segurando as principais informações e
deve ser realizada por pessoal em suas carteiras ou bolsas.
Exemplo: O balcão de atendimento
É importante compreender a dinâmica do balcão de atendimento operação.
Geralmente este grupo de funcionários estará fazendo deslocar de trabalho, com
horas cobrindo manhãs, noites e fins de semana. Eles também tendem a ser um
dos maiores grupos dentro do suporte operação, Por isso é particularmente

importante que receber uma mensagem consistente durante a comunicação
sobre a mudança. Alguns dos meios de comunicação que seriam apropriadas
para esta audiência pode ser a seguinte.
Tomando selecionadas pessoas-chave a partir do balcão de atendimento, tais
como os líderes de mudança e líderes de equipe para ouvir o breve grande
oficina. Isso irá garantir que um grupo grande o suficiente ter ouvido o breve
completo, e então eles vão estar em uma posição para interrogar suas equipes
menores. Membros da Transição de Serviço equipe poderia, então, assistir às
reuniões individuais da equipe para apoiar o líder da equipe como eles
conduzem o debrief, e responder a quaisquer perguntas. Usando memorandos
de reforço, o que garante que a equipe de service desk sentir que eles estão
sendo comunicados pelo o idoso das partes interessadas em vez de ser deixado
de fora. Ele também irá ajudar no ponto em que eles estão prestes a assumir
qualquer apoio das mudanças de Transição de Serviço. Este é também um meio
eficaz de manter um grupo grande de pessoas até à data e engajados no
processo.
Modelos ajudar a comunicar o que as pessoas devem esperar para cada serviço
ou cada tipo de mudar. A Figura 5.3 é um exemplo de um alterar modelo
costumava transição serviços de uma organização para um comercial provedor
de serviços. Este é um exemplo de uma mudança organizacional total, onde
haverá mudanças na gestão, processos e de pessoal, embora muitos
funcionários podem transferir para o novo prestador de serviços organização.
Ter acesso a um conjunto de mudanças, serviços e modelos de transição de
uma forma que é fácil de se comunicar vai ajudar a definir as expectativas
durante a Transição de Serviço.

Figura 5.3 Exemplo de etapas de transição para a terceirização de serviços

5.1.4 Motivação e a importância da comunicação
As pessoas precisam ser mantidos atualizados com o progresso da mudança,
boa ou ruim, se eles devem ser motivados para que isso aconteça. Hackman e
Oldham (1980) descreveu o estado de coisas quando as pessoas tentam fazer o
bem, porque eles acham o trabalho satisfatório, como motivação interna. O
conceito é definida na Tabela 5.1.
As características
essenciais do trabalho
O que o operário fica com
eles
O resultado se todas estas
características do trabalho
estão presentes
Feedback do trabalho Conhecimento dos resultados
reais de atividades de trabalho
Motivação para o trabalho interno
de alta
Autonomia Responsabilidade experiente
para resultados de trabalho
Variedade de
habilidades
Identidade tarefa
Significado tarefa
Significação experiente do
trabalho
Características Tabela 5.1 trabalho que motivam as pessoas
As pessoas vão ser mobilizados e engajados se eles podem ver o progresso.
Vitórias a curto prazo devem ser comunicados e progresso comemorado.

5.2 Organização Gestão e mudança das partes interessadas
Transição de Serviço'S de base papel é, com base acordada projeto, Para
implementar um serviço novo ou alterado, efetivamente tornando o organização
diferente do que era antes. Para uma mudança de qualquer significado, este
está entregando uma mudança organizacional, desde mover um pouco pessoal
para trabalhar em novas instalações até grandes alterações na natureza negócio
de trabalho, por exemplo, de face-a-face de varejo para web-based de
negociação.
Mudar é uma parte inevitável e importante da organização desenvolvimento e
crescimento. A mudança pode ocorrer em fases incrementais ou de repente,
afetando alguns ou todos de uma organização, seu povo e seus cultura. Sem
mudança, o progresso não acontece.
Esforços de mudança organizacional falhar ou aquém de suas metas porque as
mudanças e transições não são levados, gerenciado e monitorado de forma
eficiente em toda a organização e em toda a mudança processo. Essas lacunas
nos principais atividades organizacionais muitas vezes resultam em custos de
insatisfação, resistência e aumento. A mudança nunca é fácil, que normalmente
leva mais tempo do que o planejado e cria barreiras e resistência ao longo do
caminho. Os líderes eficazes e gestores de compreender o processo de
mudança e plano e levar em conformidade. Maior negativo impacto pode vir de
perder pessoal - as pessoas desiludidas deixando - o que traz riscos para a
organização, por exemplo, perda de conhecimento e falta de entrega.
Esta seção fornece mais detalhes sobre o envolvimento de Transição de Serviço
na gestão da mudança organizacional. Ele inclui garantia dos produtos mudança
de organização da Design de Serviços,das partes interessadas gestão e
comunicação e abordagens para lidar com a mudança durante transição.
5.2.1 O ciclo emocional da mudança
O que cria confusão e caos em organizações mais do que não conseguiu
mudança bem ou não conseguiu, afinal? A pesquisa mostra que os esforços de
mudança falham, ficam aquém de seus objetivos ou resultar em insatisfação e
ineficiência organizacional.
A pesquisa sobre Gestão da Mudança sugere fortemente que, sem o apoio de
pessoas, a mudança não vai acontecer. Os gerentes de negócios e agentes de
mudança devem compreender o impacto emocional que a mudança tem sobre
as pessoas e como administrá-lo de acordo. Muitas pesquisas têm sido feitas
sobre o impacto emocional da mudança.
O que isto significa é que a não considerar a mudança organizacional e como
isso afeta as pessoas é um fator importante em causar transições de falhar. A

fim de facilitar o aceitação de mudança, é importante compreender as "fases
emocionais" que uma pessoa precisa para passar antes da aceitação. Isto é
ilustrado na Figura 5.4.
Para todas as mudanças significativas, os indivíduos passam por este processo.
No início, eles entram em um grau de choque, antes de entrar em fuga. Isso
muitas vezes manifesta-se no aumento eficiência enquanto a situação é negado.
Este é geralmente um estádio acelerado, em que ponto atuação gotas como as
pessoas escolhem para "matar o mensageiro" e culpar os iniciadores de
mudança e da equipe de Transição de Serviço, seguido de auto-culpa como a
insegurança ea ameaça de a situação é sentida. O desempenho é agora em seu
mais baixo. Daqui resulta que o mais rápido da equipe de transição de serviço
pode levar as pessoas através do ciclo, o mais curtos os prazos antes
desempenho aceitação e ótima. Pode-se usar a experiência daqueles dentro da
área afetada para compreender as preocupações, ea natureza da resistência, a
fim de comunicar-se em estágios apropriados. Isto pode muitas vezes ter tempo
pessoal considerável da equipe de Transição de Serviço, para ouvir as
preocupações das pessoas, mas no final vai ter indivíduos engajados e atuando
em um tempo tão curto quanto possível.
Figura 5.4 O ciclo de mudança emocional
Comunicação adequada por estas fases de transição irá conduzir a energia de
indivíduos de alto a baixo, a obtenção de envolvimento e gerar uma atitude mais
positiva como a mudança acontece. Como enfatizado, este é um padrão seguido
por indivíduos, e pessoas diferentes vão passar por essas fases típicas em
velocidades diferentes, de modo a compreensão onde os indivíduos são nesta
curva e apoiar e progredindo-los pode ser um importante recurso compromisso
para Transição de Serviço.
5.2.1.1 A gestão eficaz da mudança

Há cinco ingredientes importantes de mudança: necessidade,
visão,plano,recursos e competência. Eles são discutidos separadamente neste
capítulo. Se não houver necessidade estabelecida, há muita resistência das
pessoas, se não há visão, há confusão entre os funcionários, se não há um
plano, há caos nas actividades e transição, Se não há / menos recursos, há uma
frustração entre os funcionários, e se não houver competência, há um medo do
fracasso entre os funcionários. Por isso, é extremamente importante prestar
atenção adequada e estabelecer o compromisso da administração para cuidar
adequada destes exigências da alteração.
5.2.2 Organização, funções e responsabilidades
Gestão da mudança e transição é de responsabilidade dos gestores e
executivos envolvidos nessa mudança. Eles devem ter a consciência de que a
mudança tem de ser gerido, que as pessoas têm de ser comunicadas de forma
aberta e honesta e que a resistência tem de ser procurado, ouviu e respondeu
de forma adequada. Este é especialmente o caso se uma mudança é em uma
escala que é significativo o suficiente para afetar a organização como um todo.
O Conselho de Administração e Executivo devem garantir que há conexões
adequadas e controles em toda a organização para alertar -los a todas as
barreiras e facilitar a transição para a sua meta.
Uma visão clara e estratégica que vem do Conselho de Administração e / ou
Executivo é imprescindível para conduzir e manter a mudança.
Papel 5.2.3 Transição de Serviço na mudança organizacional
Organizacional mudar É sempre um desafio. Fatores que impulsionam iniciativas
de mudança de sucesso ao nível da organização incluem:
• Liderança para a mudança
• Adoção organização
• Governo processo
• Capacidades de organização
• Negócios e serviços atuação medidas
• Um processo de comunicação forte com oportunidade regular de
feedback pessoal.
Embora Transição de Serviço não é responsável pela gestão global de negócios
e mudança técnica a Transição de Serviço proprietário do processo ou gerente é
uma chave das partes interessadas e precisa ser pró-ativa na relatar problemas
e riscos para os líderes da mudança, por exemplo, quando o volume de
alterações podem afetar Operação de Serviço "a capacidade de manter os
serviços a correr.

Adoção organizacional é um subconjunto de Gestão da Mudança prática. Ele
geralmente acontece em dois níveis: individual e organizacional. É importante
compreender o cultura das organizações e das pessoas envolvidas. Isso, muitas
vezes, ser bastante diversificada em diferentes culturas, unidade de negócioss,
geografias e incluindo:
• Cultura empresarial - esta pode ser diferente dependendo da indústria,
geografia, etc
• Cultura da organização do cliente (s)
• Cultura de provedor de serviços/ TI organização
• Cultura de fornecedor organização (ões)
• Personalidades individuais, especialmente de gerentes seniores e
campeões de mudança.
Cultural e organização avaliação e mudança projeto são de responsabilidade da
estratégia e design. No entanto, mais importante Transição de Serviços terá um
efeito sobre as práticas de trabalho e por isso requer uma mudança no
comportamento e atitudes de muitas equipes e das partes interessadas grupos.
Compreender os elementos de mudança organizacional de uma transição é,
portanto, vital. A avaliação dos riscos prováveis e sucesso é um elemento
importante da transição como um todo. Transição de Serviço serão envolvidos
no início do ciclo de vida para garantir que estes aspectos são avaliados e
incorporados ao projeto e construção da mudança organizacional.
Transição de Serviço devem estar ativamente envolvidos na mudança das
mentalidades de pessoas em todo o ciclo de vida para garantir que eles estão
prontos para desempenhar o seu papel em Transição de Serviço. Essas
pessoas irão incluir:
• Equipe Transição de Serviço
• Clientes
• Usuários
• Operação de Serviços pessoal
• Fornecedors
• Principais interessados.
Transição de Serviço incidirá sobre mensagens simples em qualquer momento
para garantir a coerência na implementação das mudanças. Por exemplo,
Transição de Serviço estaria interessado em ajudar as pessoas a:
• Compreender a necessidade de conhecimento e eficaz transferência de
conhecimento
• Compreender a importância da tomada de decisões na velocidade certa /
dentro do tempo adequado
• Compreender a necessidade de completar e rever configuração linha de
bases em tempo hábil

• Aplicar mais eficaz avaliação de risco e métodos de gestão de Transição
de Serviço
• Siga os prazos para a apresentação de alterações e lançamentos.
Design de Serviços irá realizar a avaliação do capacidade e capacidade da
organização de TI para a transição dos serviços novos ou alterados. Transição
de Serviço tem um garantia de qualidade papel para verificar se a organização e
das partes interessadass estão prontos para a mudança e que vai levantar
quaisquer questões e riscos relacionados à mudança organizacional que são
identificados, por exemplo, durante o teste, pilotos, desenvolvimento e apoio
início da vida.
Transição de Serviço também é responsável por assegurar que a mudança
organizacional acontece de acordo com a planos, que a mudança ainda é
relevante nas circunstâncias actuais, e que a mudança organizacional oferece o
previsto organização, Capacidades e recursos. Isso vai envolver a verificação de
que as mudanças estão sendo adotadas, por exemplo, que uma massa crítica
de clientes, usuários e Operação de Serviços funcionários aceitar a alteração e
fazer um compromisso pessoal para implementá-lo. Evidências sugerem que
uma vez que uma "massa crítica" de cerca de 70% das pessoas afetadas têm
aceitou a mudança em sua forma normal de trabalhar a mudança pode ser
realizada com segurança como um comportamento estabelecido. Se a taxa de
adoção é menor, então existe uma chance significativa de que uma organização
pode voltar a "velhas maneiras. O número real será muito influenciar pelo grau
de envolvimento pessoal com uma mudança em particular, por exemplo, alguns
funcionários-chave pode entregar uma influência desproporcionalmente grande
para aceitação ou rejeição.
Transição de Serviço alcançar sucesso requer povo organizado, competente e
bem motivada para construir, Implantar teste, e operar o serviço. Transições
Serviço de sucesso dependem de mudar a organização e as pessoas, e é
importante se concentrar em aspectos como avaliação de competências e
desenvolvimento, Recrutamento, desenvolvimento de competências,
transferência de conhecimento, formação de equipe, processo melhorias e
recurso implantação. Se existe uma lacuna na capacidade então Transição de
Serviço deverá contribuir para a parte relevante, por exemplo, projeto gestão,
Design de Serviços,Melhoria de Serviço Continuada.
5.2.3.1 Entendendo a cultura organizacional
Para Transição de Serviço de sucesso, uma organização necessita para
determinar os valores subjacentes e drivers que permitem uma gestão eficaz da
mudança. Cada organização e combinação de organizações é diferente, de
forma a abordagem Transição de Serviço para mudar é determinada, em parte,
pela cultura e assim pode variar em toda a organização.

A cultura organizacional é o conjunto das idéias, valores corporativos, crenças,
práticas e expectativas sobre o comportamento e os costumes diários que são
compartilhados pelos funcionários de uma organização. A cultura pode suportar
uma implementação ou pode ser a fonte de resistência.
Ao realizar atividades de Transição de Serviço é importante para ganhar uma
compreensão do tipo de cultura atualmente existente na organização e como
esta é susceptível de ser afetado por quaisquer mudanças propostas. Por outro
lado, é igualmente importante para compreender a cultura pode ter efeito atual
como uma "barreira" para realizar a mudança. Exemplos de questões chave a
serem colocadas para ajudar a identificar a cultura são apresentados na Tabela
5.2. Estas perguntas são úteis ao analisar o Estratégia de Serviço e Design de
Serviços entregas.
Aspecto
cultural
Pergunta
Linguagem Há uma língua comum ou língua compartilhada (s)? Será que a linguagem
inibir e reforçar as fronteiras ou facilitar uma mudança efetiva e transferência
de conhecimento? É o estilo de linguagem organizacional principalmente
formal ou informal?
Mudar A organização parecem resistir à mudança ou está em constante evolução?
Comunicação Quais são os modos de comunicação preferidos? Qual é o estilo eo
conteúdo das comunicações internas? Onde é que a comunicação oficial e
não oficial acontecer? São os canais de comunicação abertos e
democráticos ou fechado e hierárquico? Como é de conhecimento e
experiência compartilhada? São boatos / fofocas prevalente?
Fluxo de
conhecimento
Como as pessoas descrevem a forma como o conhecimento ea informação
é transferida em torno da organização? Como é fácil de encontrar o que
você precisa saber, quando você precisa dele? Como é fácil de encontrar a
pessoa certa com a experiência certa?
Comunidades Há identificáveis "comunidades" dentro da organização? Existe um líder
comunitário, por exemplo, gestão de problemas líder da comunidade? O que
é a estrutura e função dessas comunidades?
Redes São redes de um indivíduo bem desenvolvido, em geral? Que tipo de
informações são trocadas por essas pessoas?
Ambiente de
trabalho
Será que o trabalho ambiente criar as condições para a transferência de
conhecimento e de trabalho integrado, por exemplo, proximidade física e / ou
ferramentas eletrônicas? Como são mesas configurado? Como são áreas
comuns usados?
História Como a organização vê a sua própria história? Está valorizado e utilizado ou
rapidamente esquecida? Como é que o organização valor experiências
passadas, por exemplo, que as pessoas ainda se referir a sua antiga
empresa após uma fusão?
Reuniões São reuniões visto como produtivo? Como são tratadas? São eficazes? Será

que todo mundo se sentir seguro para falar? Como é opinião ou crítica
tratado? Como é a saída capturada ou tomado a frente?
Recompensas e
motivações
Como são pessoas / equipes recompensado ou reconhecido por partilha de
conhecimento / informação e experiência? O que motiva as pessoas na
organização? O que mais pode estar bloqueando engajamento de um
indivíduo / equipe, por exemplo, grande mudança outro, incidente grave
manipulação?
Tempo Quais são indivíduos, equipes e as atitudes organizacionais em tempos, por
exemplo, ocupado ou relaxado, pontual, rígida e imutável ou flexível?
Entendimento Tabela 5.2 a cultura das partes envolvidas

5.2.4 Estratégia e design para a gestão da mudança
organizacional
Como discutido na Estratégia de Serviço publicação, a idade de uma
organização e tamanho afetar sua estrutura.
Durante uma Transição de Serviço, Mudanças nos papéis, processos e relaçãos
devem ser feitas ou problemas irão surgir. Compreender as diferentes fases de
desenvolvimento do das partes interessadas organizações ajuda a Transição de
Serviço gerenciar as partes interessadas e usuários melhor.
5.2.5 Planejamento e implementação de mudança organizacional
Freqüentemente planos e os projetos para a gestão mudar não são equilibrados
e da organização e as pessoas do lado de mudança são omitidos (uma
ilustração bem conhecido disto é a McKinsey 7S modelo). Dentro de
departamentos de TI Gerentes de Projeto, muitas vezes se concentrar nas
atividades técnicas, em vez de as mudanças necessárias para a organização ou
indivíduos. É importante que os planos do projeto são revistos para assegurar
que as atividades de mudança organizacional estão incluídos.
A fim de gerir a mudança organização, é importante que as partes interessadas
e as equipes de entender o que é necessário e pode responder a estas
perguntas:
• Quais são os negócio organizacionais e direcionadores estratégicos,
personalidades e política mudanças?
• Quais os problemas que a mudança proposta resolver?
• O que fará o serviço novo ou alterado entregar?
• O que faz o serviço novo ou alterado parece?
• Como atual objetivos precisa ser modificado?
• Quais são os objetivos da mudança, tal como definido pela administração,
bem como o sucesso será julgado ao longo dos níveis da organização?
• Quais são os processos, modelos, pontos de decisão e sistemas para ser
usado e qual o nível de comunicação de dados é necessária para as
decisões a serem tomadas?
• Quem será envolvido e quem anteriormente envolvidos não serão mais?
• Que serão afetados dentro e fora da organização?
• Quais são as restrições - Faixa de tipo e flexibilidade - os horários,
equipamentos, pessoal e fornecedor disponibilidade?
• Qual é o prazo previsto?
• Quem ou o que pode ajudar na planejamento a implementação?
• Que habilidades e as medidas devem ser consideradas?
• Como será a vida 'normal' serão afetados?
• O que as consequentes alterações ser, por exemplo, de métodos de
negócio?

Como parte do garantia de qualidade e implementação, a das partes
interessadass equipes de TI e podem ser colhidas amostras para compreender e
esclarecer suas expectativas sobre esses aspectos.
5.2.6 Organizacionais produtos de mudança
A mudança na organização do estado atual para um novo estado pode exigir
uma combinação de elementos a ser alterada, a fim de realizar plenamente a
transformação da organização. O requerido serviço é definida na Pacote Service
Design. As seguintes trabalho-produtos são saídas típicas de Estratégia de
Serviço e Design de Serviços que auxiliam na gestão da mudança
organizacional durante a Transição de Serviço:
• Stakeholder mapa
• Organização atual e capacidade avaliação
• Competência atual e necessária modelo ea avaliação de competência
• As restrições (incluindo organização, capacidade, recursos)
• Serviço de Gestão de processo modelo
• Políticas, processos e procedimentos
• Funções e definições de responsabilidade, por exemplo, um RACI
(Responsável, responsável, Consultado, Informado) matriz
• Relação gestão
• Plano de Comunicação
• Fornecedor quadro, especialmente onde vários fornecedores estão
envolvidos.
Um exemplo de um RACI matriz de gestão da mudança durante o ciclo de vida
de serviços que suporte Transição de Serviço actividades é apresentada na
Tabela 5.3. Em muitos casos, no gráfico o 'R' para a responsabilidade aparece
em mais de uma coluna. Isso é indicativo da natureza hierárquica da
responsabilidade, com estratégico, tático e operacional responsabilidades e,
portanto, a ser necessário espalhar através de mais de uma única coluna.
Nestes casos, as ocorrências da esquerda são mais de gestão, os do lado
direito com foco na entrega.
Papel
Responsabilidade
Alterar
patrocinador,
por exemplo,
líderes de
negócios e TI
Mudança de
facilitador, por
exemplo,
proprietários de
processo, donos
de serviços
Agente de
mudança, por
exemplo, líder
da equipe
instruindo
mudança
Muda o alvo,
por exemplo,
indivíduo
realizando a
mudança
Articular uma visão
para a mudança de
negócios e serviços
em seu domínio
A / R A / R C Eu
Reconhecer e lidar A / R A A C

com a resistência à
mudança
Iniciar a mudança,
entender as alavancas
de mudança e os
obstáculos
A / R A / R C C
Gerir a mudança e de
entrada para alterar
plano
A / R A / R C C
Entrada para desenho
de alvo organização
ou estrutura, etc
A / R A / R C
Configurar uma
sistema para
comunicar as
alterações
A / R A / R C
Steer mudar A / R A A C
Mobilizar a
organização
A / R C C C
Mobilizar seu
departamento,
unidade de equipe,
A / R A / R C
Conduzir workshops e
análise de grupo dos
processos atuais
A / R A / R
Conduzir reuniões
eficazes
A / R A / R A / R A / R
Resolver problemas
em grupos
A / R A / R A / R
Exemplo de tabela de 5,3 RACI matriz de gestão da mudança
Transição de Serviço irá verificar que os produtos de mudança organizacional e
serviços são apto para o efeito. Para mudanças de larga escala, como fusões e
aquisições e terceirização, Isto incluirá validação da abordagem para:
• Desenvolvimento de carreira - são os planos de sucessão a ser
construído? Os indivíduos têm uma compreensão de suas perspectivas
de progressão?
• Atuação avaliação em nível de equipe, organização e individual - são
regulares revers conduzido? É a documentação formal, e há
demonstração de uma abordagem consistente?
• Recompensas e remuneração - Existe um benefício líquido para as
pessoas afetadas pela mudança?

• Recrutamento e seleção - Onde há qualquer diferença em todas as
funções necessárias, há uma justa e coerente processo à seleção,
incluindo o processo de circulação interna, bem como a seleção do
mercado externo?

Típico de trabalho de que a sub-produtos Transição de Serviço depends equipe
são apresentados na Tabela 5.4.
Modelo de organização
Nova ou alterada a estrutura organizacional
Estrutura de desenvolvimento de carreira
Recompensa e estrutura de compensação
Atuação avaliação estrutura
Estrutura de medição de desempenho
Competência projeto modelo detalhado
Lista de Competências
Competência /atividade matriz
Trabalho de destino, papel, Pessoal e competência exigênciaa matriz
Definição do trabalho e projeto
Definições de função e descrições
Pessoal plano
Individual
Avaliação individual
Competência de avaliação (incluindo papel e avaliação de habilidades)
Avaliação de desempenho
Melhoria de desempenho avaliação de necessidades
Aprender avaliação das necessidades
Educação e formação
Aprender abordagem
Aprendizagem teste aproximação
Melhoria de desempenho projeto
Definição de aprendizagem e design
Curso definição
Desempenho do projeto de apoio aprimoramento
Desempenho plano de apoio aprimoramento
Exemplo Tabela 5.4 da organização do trabalho-produtos da fase de construção

5.2.7 Avaliação de prontidão para a mudança organizacional
A lista de controlo apresentados na Tabela 5.5 pode ser utilizado para avaliar a
papel e habilidade exigências durante Transição de Serviço.
Verificar Evidência
Existe uma avaliação do número de efectivos e os
seus níveis de habilidade atuais?
Plano
Existe uma documentado visão/estratégia para
resolver quaisquer riscos em cada área (por exemplo,
recurso deficiências - começar a contratar ações, sub-
contratar ou terceirizar toda a área)?
Visão / estratégia
Já os papéis genéricos e interações em todo o
Transição de Serviço foi revisto?
Funções e
responsabilidades
matriz de interação
São os papéis específicos e medidas definidas? Atuação medidas por
papel
Tem as habilidades para cada área, ou seja,
conteúdo, aplicação, Técnica e negócio, Foram
definidos?
Habilidades requisitos
para cada área
Existe uma avaliação do pessoal da organização
contra os requisitos?
Relatório de avaliação
Ter pessoal de áreas no organização com excepção
das zonas abrangidas pela Transição de Serviço foi
considerado?
Relatório de avaliação
Tem o exigências para ambos desenvolvimento e
manutenção que suportar as necessidades de
negócios foi considerado?
Requisitos
Tem o nível de risco que se relaciona com o apoio
disponível para determinadas áreas foram
documentados? Também as áreas que não podem
ser suportados e os pressupostos que se aplicam à
análise?
Avaliação de risco
denunciar
Tabela 5.5 papel organizacional e habilidades lista de verificação de avaliação

5.2.8 Monitoramento do progresso de mudança organizacional
Para permitir que um Transição de Serviço programa para ser eficaz e bem
sucedida, o controlo regular / inquéritos devem ser realizados ao longo
diferentes níveis da organização. Tabela 5.6 mostra uma pesquisa de feedback
que pode ser usado em ambos, o indivíduo e as equipes envolvidas.
Aspecto Resposta
Reuniões de transição de serviço são devidamente gerida e
administrada de forma eficaz.
Eu tenho uma idéia clara do que é esperado de mim durante este
Estou confiante de que eu possa cumprir com sucesso o trabalho de
transição de serviço atribuído.
Meu gerente me incentiva a troca de ideias sobre como trabalhar
melhor e / ou melhorar os processos atuais.
Meu gerente está disposto a ouvir as minhas preocupações e idéias
e persegui-los em meu nome.
O Serviço de Transição comunicação métodos, frequência e
conteúdo satisfazer as minhas necessidades.
A atmosfera durante a Transição de Serviço é amigável e útil e
aberto.
Há um esforço suficiente sendo feitos para obter e avaliar as
opiniões e pensamentos de todos os membros da equipe de
transição de serviço.
Eu entender claramente a operacional necessidades deste
O trabalho que eu sou responsável por se reunirá a Transição de
Serviço e as necessidades operacionais do negócio usuários.
As exigências de trabalho me permite equilibrar a minha carga de
trabalho e vida pessoal.
Acredito que ações reais e Serviço consideração a gestão de
transição vai resultar de meu feedback capturado a partir de
pesquisas.
Exemplo de tabela de 5,6 de uma pesquisa de feedback

Os resultados de qualquer pesquisa deve ser útil para determinar o progresso
alcançado através de Transição de Serviço. Isso incluirá a estado de
comprometimento dos funcionários e as áreas de melhoria. Isso também irá
servir como uma ferramenta útil em vários marcos dentro da transição jornada.
Funcionários se sintam que suas opiniões contar em um momento crítico como
eles vão para o Transição de Serviço programa. Este é o lugar onde um
envolvimento positivo dos novos processos pode ser aumentada ", tendo a
maioria com você '.
Monitoramento é, naturalmente, apenas a primeira parte de um conjunto de
acções. As respostas obtidas devem ser analisadas e compreendidas. Quando
necessário, as questões devem ser abordados e resolvidos o mais rápido
possível. Respondentes à pesquisa deve ser mantido informado das alterações
que resultam de seu feedback. Só desta forma pode equipe tem confiança de
que o seu feedback é importante e proporciona melhorias.
Muitas vezes, as melhorias serão identificados na implementação de pós rever
do serviço mudar e pode alimentar Melhoria de Serviço Continuada.
5.2.9 Lidando com a organização e as pessoas em mudanças de
sourcing
Amudar no fornecimento de De serviços de TIs é um dos tipos mais importantes,
e muitas vezes mais traumática, de mudança organizacional. Vários diferente
impactos e efeitos sobre a equipe terá de ser considerado, planejada e
preparada.
Choque empregado
Uma das maiores mudanças que serão causados com a terceirização é "choque
empregado". Tal como descrito na secção de organização mantida pessoal,
muitos funçãos irá evoluir para preocupações mais genéricas, como projeto
gestão e gestão de negociação. Haverá também uma questão moral causado
pela transição de pessoal substituída pela função de fonte. Essas percepções
devem ser tratados cedo, no início da iniciativa, para que os funcionários são
completamente consciente do que está para acontecer. Falta de comunicação e
comportamento secreto só promove a suspeita e pode levar a atitudes negativas
e prejudiciais. Abastecimento é feito melhor em um ambiente aberto, onde todas
as opções são claras e identificadas.
Mudanças nos negócios
Outra mudança importante é a forma como os negócios são conduzidos.
Compartilhamento de "tudo" com um fornecedor de terceirização pode levar à
desconfiança, se não for apresentado nos termos corretos. Cuidados devem ser
tomados para garantir que a informação é passada para o fornecedor de

terceirização em uma "necessidade de saber '. Isto irá manter o relação
profissional.
Alteração de local
A localização do abastecimento também pode apresentar problemas e riscos
durante Transição de Serviço. Típicas locais de abastecimento são
apresentados a seguir e cada um representa uma diferença de onde o serviço
foi prestado antes de sourcing:
• Local existe terceirização na mesma área geográfica
• Global (-shore multi) terceirização escolhe a melhor solução não depende
de localização geográfica
• Perto da costa- fronteiras que adquirem o cliente língua local mesma
oferta, e zonas de tempo cultura
• Off-shore terceirização está localizado em uma localização geográfica
específica
• Combinações estão se tornando comuns com diferentes funçãos, ou
aspectos de funções, entregue em formas diferentes, por exemplo, 9-5
balcão de atendimento entregue no local, mas fora das horas de serviço
suportado a partir de off-shore.
As questões culturais e organizacionais relacionados com a mudança de
localização devem ser abordados para uma Transição de Serviço de sucesso.
Vinculação das atividades de terceirização de toda a organização
Em planejamento um Transição de Serviço para outra organização, a
terceirização estratégia é mapeado em todo o organização. Este é o lugar onde
o orçamento é ligada ao grupo financeiro, os serviços estão vinculados ao grupo
de prestação de serviços, segurança considerações são vinculados ao grupo de
segurança etc
Cada grupo que está ligado à iniciativa de terceirização deve fazer provisões
para a interação com o fornecedor de terceirização de modo que a terceirização
operação vai continuar a funcionar sem problemas. É importante obter o
compromisso das pessoas-chave, e técnicas de planejamento de compromisso
pode ser usado (ver secção anterior). As ligações devem ser testados em cada
fase de transição processo a fim de verificar que a ligação está a funcionar e
proporcionar a correcta transação entre a empresa eo fornecedor de
terceirização.
Por exemplo, se o negócio quer atualizar o software de segurança do sistemas
que o fornecedor de terceirização está usando para executar a informação
financeira do negócio, o grupo de segurança deve ter um contato estabelecido
com o fornecedor para transmitir essa necessidade.

Se o vendedor precisa aumentar o nível de habilidade específica de negócios de
um novo funcionário, eles devem ter um contato estabelecido para o
departamento de formação do negócio e / ou especialistas, dentro da
organização.
Todos os aspectos da operação de abastecimento no que se refere ao negócio
que ele suporta deve ser ligada à área apropriada / grupo dentro da empresa.
Esses links precisam ser identificados e estabelecidos no início ou no
abastecimento relação não será eficiente e terá muitos gargalos que irão afectar
a produtividade. Transição de Serviço terá de testar esses links tão cedo quanto
possível.

5.2.10 Métodos, práticas e técnicas
5.2.10.1 Sugestões e dicas de gestão da mudança
Há uma tendência para os executivos seniores para ignorar a necessidade de
organização mudar ditando comportamentos que deve ser feito e saqueando as
pessoas a passar a mensagem. Normalmente ele funciona no curto prazo, mas
depois se desfaz após as folhas executivo-chave ou se move para outra coisa.
Tabela 5.7 fornece conselhos úteis sobre os prós e contras de gestão da mudança.
Fazer Não
• Estabelecer um linha de
base e visão
• Desenvolver uma
comunicação estratégia e
verificar que as
comunicações são
entendidas
• Identificar impacto em
outros serviços, processos,
sistemas e as pessoas não
envolvidas em Transição de
Serviço
• Identificar impacto sobre os
clientes /usuários e outros
das partes interessadass
• Ser capaz de articular e
comunicar por que estamos
fazendo essa mudança
• Identificar novas
competências /
conhecimentos necessários
• Considerar desenvolvimento
exigências e como estes
requisitos serão abordados -
formação, coaching,
mentoring
• Promover a cultura certa
• Promover a disciplina
organizacional
• Integrar o suporte de RH
• Colocar as pessoas certas
no papel certo / trabalho
• Ajudar as pessoas a
gerenciar o estresse
• Incentivar as pessoas a
pensar que a situação pode
ser melhorada - que,
geralmente, pode ser
• Facilitar o acesso a
• Tente micro-gerenciar tudo
• Coloque pequenas mudanças através de
processos burocráticos
• Esqueça o grau acordado de exposição a risco -
Em muitas circunstâncias, a negócio é assumir
riscos comerciais como uma deliberada política,
Mas ele e outros estão a minar as justificativas
de negócios e políticas, tentando remover o risco
de sua componente de uma mudança de negócio
• Concentre-se apenas na TI - todos os
componentes de um serviço deve ser transferida
• Esquecer as pessoas
• Over-complicar as coisas - eles são mais difíceis
para as pessoas entenderem
• Ignorar os efeitos depois de mudanças falharam
em pessoas
• Negligenciar os custos de transição
• Validade em vez re-avaliar e relevância do
serviço ou a mudança - sucumbir à inércia
• Finja que não haverá perdedores.

informações sobre a
mudança
• Assegurar a documentação
nova ou alterada /
instruções são concisas e
compreensíveis para o
público-alvo.
Tabela 5.7 Dicas para gerir a mudança

5.2.10.2 JP Kotter "Oito passos para transformar a sua organização
JP Kotter "Oito passos para transformar a sua organização", apresentado na
Tabela 5.8, é uma abordagem bem-comprovada de gestão de transformação.
Este é um método útil para utilizar para identificar as lacunas de planos para a
gestão da mudança organizacional.
Liderando
mudança: oito
Passos
Desafio central Comportamento desejado
1. Estabelecer um
sentido de
urgência
Receba as pessoas "fora do bunker" e
pronto para avançar.
As pessoas começam a dizer
uns aos outros: "Vamos, temos
de mudar as coisas!"
2. Criar uma
coalizão orientando
Ter as pessoas certas no lugar com a
confiança, o compromisso emocional e
trabalho em equipe para orientar a
mudança difícil processo.
Um grupo poderoso o suficiente
para guiar grandes mudanças
influencia outros para aceitar a
mudança, e que funciona bem
em conjunto.
3. Desenvolver um
visão e estratégia
Obter a equipe de orientação para criar
a visão direita e estratégias para
orientar a acção em todas as demais
etapas da mudança. Isso requer ir
além números para resolver o criativo e
emocional componentes de visão.
A equipe de orientação
desenvolve a visão direita e
estratégia para o esforço de
mudança.
4. Comunique a
visão de mudança
(e, comunicá-lo
uma e outra vez)
Receba as pessoas o maior número
possível de atuação para tornar a visão
uma realidade.
As pessoas começam a comprar
para a mudança e isso mostra
em seu comportamento.
5. Capacitar ampla
ação
Remover os principais obstáculos que
impedem as pessoas de agir sobre a
visão.
Mais pessoas se sentem
capazes de agir, e agir, na
visão.
6. Criar vitórias a
curto prazo
Produzir o suficiente de curto prazo
(rápido) ganha rápido o suficiente para
energizar os ajudantes de mudança,
iluminar os pessimistas, desarmar os
cínicos e construir o impulso para o
esforço.
Momentum constrói como as
pessoas tentam cumprir a visão,
enquanto cada vez menos
resistem à mudança.
7. Consolidar
ganhos e produzir
mais mudanças
Continue com a onda após onda de
mudança, não parando até que a visão
é uma realidade - não importa quão
grande os obstáculos.
As pessoas permanecem
energizados e motivados para
empurrar a mudança para a
frente até a visão é cumprida -
plenamente realizados.
8. Abordagens
nova âncora na
cultura
Criar uma estrutura de apoio que
fornece raízes para as novas formas
de exploração.
Novo comportamento e
vencedora continua, apesar da
força da rotatividade de tradição,
de líderes de mudança, etc

Tabela 5.8 JP Kotter "Oito passos para transformar a sua organização
Mais detalhes sobre JP Kotter "Oito passos para transformar a sua
organização'É descrita no Melhoria de Serviço Continuada publicação. Estas são
etapas iterativas, e em cada comunicação evento, A compreensão das pessoas
precisa ser verificado.
5.2.10.3 organizacionais estratégias de mudança
Transição de Serviço estará interessado nas estratégias propostas para
gerenciar organizacional mudar. Estes podem ser usados para avaliar a
abordagem de Design de Serviços e gerir a mudança durante a Transição de
Serviço e identificar problemas e riscos relacionados à mudança organizacional.
Kotter e Schlesinger (1979) sugere as seguintes estratégias que funcionam bem
em prática:
• Educação e compromisso - Quanto mais cedo gerentes dar às pessoas
informações sobre a mudança e as implicações para eles, o mais bem
sucedido da implementação da mudança é provável que seja. Educação
e compromisso começar no início dos anos planejamento actividades. As
discussões geradas em torno dos prós e contras do plano irá ajudar a
dissipar o ceticismo sobre a necessidade de mudar e fazer alianças fortes
que podem ser usados como um agente de mudança.
• Participação e envolvimento - Permitir que as pessoas a participar na
mudança normalmente supera resistência. Por si só, não é suficiente,
mas deve ser usado em conjunção com um política de educação e
compromisso, para que as pessoas entendam a necessidade de
mudança, e eficaz monitoramento e rever para gerentes de ser capaz de
avaliar a impacto de mudança no Transição de Serviço programa. Não é
incomum que as pessoas reverter para familiares práticas de trabalho,
mesmo que apoiar as mudanças. "Fadiga Mudança" é um conceito bem
conhecido que pode ser esperado em algum momento e devem ser
monitorados.
• Facilitação e apoio - Os gestores devem estar prontos para responder
positivamente quando os medos e ansiedades sobre a mudança são
expressos. Falando com as questões e realizar uma habilidades análise
de lacunas pode ser suficiente, mas em outros momentos de formação
nos novos processos será necessário, de preferência antes da
implementação. O gestor deve promover constantemente os benefícios
da mudança, lembrando as pessoas da objetivos, e comunicar uma clara
visão do que a organização será semelhante no futuro e como
contribuição dos funcionários é importante para que isso aconteça.
Alguma resistência expressa pode ser positivo porque mostra que os
trabalhadores estão envolvidos e pode provavelmente ser movido ao
longo do ciclo (Figura 5.4), a um ponto de aceitação. Os funcionários que

mostram nenhuma emoção visível são os que precisam de atenção extra
para identificar as questões ocultas e lidar com eles, caso contrário
atividades secretas e subversivas pode resultar.
• Negociação e acordo - A mudança é mais fácil de implementar, se você
tem acordo; ganhar acordo sugere a negociação, para que os gestores
devem estar preparados para negociar, formalmente, se necessário. O
parente custar de ganhar o contrato deve ser definido contra a
importância da mudança. Transição de Serviço tem um papel importante
assegurar tal acordo seja adquirida após cada serviço ciclo de vida fase.
Envolvimento com sindicatos e de RH, será necessário, especialmente se
negativo impacto em indivíduos é esperado.
• Manipulação e cooptação - Às vezes é necessário para fechar acordos
com aqueles que se opõem à mudança, seja fazendo-os a par de
informações restritas ou por "compra-off ', ou seja, dando-lhes
recompensas extras (financeiros ou não) para ganhar a sua participação.
Esta abordagem deve ser utilizado com a ressalva de que ele é
susceptível de causar problemas mais tarde. Ele é frequentemente usado
quando o provedor de serviços mudanças e há uma risco ao operacional
serviços, se o pessoal-chave com o conhecimento insubstituível e licença
de experiência.
• Coerção explícita e implícita - Há ocasiões em que a coerção é a tática
adequada. Ela virá com custos associados, semelhante à abordagem
directiva do 'agir agora explicar mais tarde ". A coerção pode muito bem
ser contrárias aos valores e crenças de sua organização e, por inferência,
a indivíduos que nela trabalham. Uma liderança forte é necessário se
utilizar este estratégia, Juntamente com um conhecimento completo da
situação eo possível problemas que serão causados.
Outros métodos que os gerentes usam geralmente são:
• Comportamento desejável gratificante, enquanto, ao mesmo tempo
ignorando ou desencorajar o comportamento inadequado que é
prejudicial para o programa Transição de Serviço.
• Tratar 'ferir' sistemas, identificando o que é que as pessoas, cujo
compromisso é necessário, não gosta sobre o atual sistema e colocá-lo
direito. Os gerentes podem fazer isso para os indivíduos ou incentivá-los
a identificar as suas próprias soluções.
• Expondo os problemas de uma maneira sensível. As pessoas tendem a
tomar uma posição contra a mudança, se eles são feitos para sentir que
as suas preocupações são insignificantes ou eles estão sendo apoiada
em um canto. Realização de uma reunião informal e aberta em que há
minutos são tomadas, onde todas as questões são discutidas, a fim de
obter uma compreensão maior de um outro ponto de vista sobre os
serviços a data ea transição plano, Ajudará a evitar atitudes arraigadas.
• Sendo um papel modelo para a mudança. Os gestores devem se
comportar de maneiras que são congruentes com o esperado resultado,

Reforçando a visão da mudança. O entusiasmo pode ser infecciosa,
agindo como um agente positivo para a mudança.
• Usando a pressão do grupo de pares para convencer as pessoas de que
a mudança é boa para a organização. Os gerentes precisam identificar os
indivíduos que impõem respeito entre seus pares e obter o seu apoio. O
Princípio de Pareto de 80:20 é uma medida eficaz - uma vez que 80% das
pessoas vão deixar a mudança acontecer (ou até mesmo fazer a
mudança acontecer), você pode passar para a próxima fase, os outros
20% virão.
• Incentivar a partilha das mudanças positivas e comemorando o sucesso.
Permitindo que outros para ver que realmente funciona vai encorajá-los a
abraçar a mudança.
5.2.10.4 Técnicas de superar a resistência dos indivíduos para mudar
Rosabeth Moss Kanter identificou 10 razões por que as pessoas resistem às
mudanças e estratégias de opcionais que irão promover facilitadores mudança
positiva. Estas podem ser úteis para o Transição de Serviço equipe de entender
quando envolvidos na gestão das partes interessadas mudar para superar
problemas de indivíduos durante a transição. As 10 razões são:
• Perda de controlar - Quando você move as pessoas a partir de uma
processo com que são familiares para que eles pouco sabem, eles vão
experimentar uma sensação de perder o controle. Isso pode ser
superado, envolvendo-os na tomada de decisão, até mesmo permitindo-
lhes tomar decisões por si mesmos. É essencial para informar as pessoas
sobre as escolhas que eles têm - mesmo que eles são extremamente
limitados. Os gestores devem antecipar que é provável que se opõem às
mudanças e decidir como conquistá-los. Uma explicação detalhada do
benefício do negócio e da retorno sobre o investimento (ROI) vai atacar
um sentido de urgência e consciência de como o novo Transição de
Serviço irá apoiar as necessidades do negócio.
• Incerteza pessoal excessiva - A primeira pergunta que a maioria das
pessoas vai perguntar é "O que é que isto vai significar para o meu
trabalho?" Isto pode ser respondido de forma eficaz, explicando a
necessidade e implicação, a mudança, tanto de negócios como a nível
pessoal, incluindo a freqüência questão difícil de estimar quanto tempo o
período de incerteza vai durar. Honestidade é a melhor política.
• Evite surpresas - As pessoas gostam de ser dada a oportunidade de
pensar as implicações da mudança de / para eles; surgindo novas idéias
sobre eles irá criar ceticismo.
• O efeito de diferença - As pessoas constroem suas identidades em torno
de muitas facetas de seu trabalho - sua papel, O trabalho, o edifício, o
nome da empresa - que lhes dá um senso de tradição. Gerentes só deve
mudar o que deve, mantendo símbolos familiares sempre que possível.

• Perda de face - As pessoas não gostam movendo-se de uma posição de
competência para uma de incompetência, que muitas vezes pode
acontecer quando novos processos, sistemas e formas de trabalho são
introduzidos. Os gerentes podem aliviar este problema reconhecendo a
competência da pessoa sob o antigo regime e deixá-los participar na
decisão sobre o processo de mudança. Isso também pode ser feito
permitindo que a responsabilidade conjunta de pessoal objetivo criação.
Isso irá gerar envolvimento precoce como as transições de mudança.
• Medo em torno competência - Algumas pessoas vão acreditar que eles
não podem adotar as novas formas de trabalhar - "Você não pode ensinar
a um cachorro velho novos truques! 'A solução é dar-lhes a formação /
orientação que precisam antes que o novo sistema é implementado,
permitindo-lhes ter corridas de prática antes de o sistema entrar viver de
modo que provar a sua competência para si, criando assim melhores
níveis de confiança. Isso pode ter a vantagem adicional de aumentar seu
desejo de mudança, e responsabilidade pessoal de seu próprio
desenvolvimento de carreira.
• Ripples - O efeito inesperado de uma medida tomada em uma área na
outra. Gerentes seria ingênuo pensar que a mudança planejada é livre de
problemas, às vezes é impossível prever com precisão o efeito de uma
mudança terá em outra parte do organização. Durante o planejamento
pessoas de fase devem ser encorajados a pensar amplamente e de forma
divergente, considerando possibilidades improváveis, bem como provável
quando se tenta predizer resultados; esta catástrofe planejamento pode
ajudar a minimizar o efeito cascata.
• Aumento em carga de trabalho - Mude frequentemente resulta em mais
trabalho. Se esta é a realidade, deve ser reconhecido e recompensado,
se possível.
• Ressentimentos do passado - Se a mudança proposta está associada a
um indivíduo ou organização sobre a qual a pessoa tem uma queixa eles
vão resistir à mudança. Permitindo-lhes expor os seus ressentimentos, os
gestores terão a oportunidade de remover ou reparar eles.
• Real ameaças - Há momentos em que a mudança vai ter um impacto
negativo impacto no indivíduo, e são justificados em resistir. Fingindo que
vai ficar tudo bem não ajuda; gerentes precisam agir primeiro e agir
rápido, conversando com eles o mais rápido possível, e envolvê-los na
solução.

5.3 Gestão de Stakeholders
Stakeholder Management é um fator crucial de sucesso no Transição de
Serviço. A nova ou mudada serviço deve apoiar e entregar das partes
interessadas requisitos para ser considerado bem sucedido e o seu
envolvimento activo irá aumentar a probabilidade de realização, conforme
necessário. A falha em identificar corretamente todos os grupos interessados
torna quase inevitável que muitos dos afetados não terá consciência das
mudanças propostas e incapaz de registrar suas preocupações e desejos, nem
serão capazes de ser solidários se eles não estão incluídos.
5.3.1 estratégia de gerenciamento das partes interessadas
A gestão de stakeholders estratégia de Design de Serviços estabelece:
• Quem são os envolvidos
• O que os seus interesses e influências são susceptíveis de ser
• Como o projeto ou programa vai se envolver com eles
• Que informação será comunicada
• Como feedback será processado.
É útil para Transição de Serviço se das partes interessadass são listados em
categorias como 'usuários / beneficiários "ou" prestadores ". Cada categoria
pode então ser dividida, se necessário. Categorias devem ser reconhecidos
grupos, em vez de os abstratos, por exemplo, "os funcionários com base em
uma localização geográfica" são um grupo facilmente identificável, enquanto que
"os membros do público que apoiam os direitos humanos" não são. Algumas
categorias podem identificar os mesmos indivíduos, mas muitas vezes é útil para
diferenciar entre partes interessadas usando chapéus diferentes ", como os
mostrados na Figura 5.5.

Figura 5.5 potenciais interessados
5.3.2 mapa de stakeholders e análise
As partes interessadas têm inevitavelmente diferentes áreas de interesse na
mudança global, por exemplo, alguns vão estar preocupados com a forma como
a mudança vai afetar seu trabalho ambiente, Outros vão querer influenciar as
mudanças na forma como os clientes são tratados. A matriz das partes
interessadas (ver Figura 5.6) é uma forma útil de mapear as diversas partes
interessadas contra seus interesses na Transição de Serviço, suas atividades e
resultados. Transição de Serviço deve trabalhar com Design de Serviços para
assegurar que existe um mapa dos interessados precisa e pertinente, ou
equivalente.

Figura 5.6 Exemplo interessados mapa
Exemplos de pessoas que podem ser afetados são:
• Patrocinadores da mudança de serviço, por exemplo, atualização de
tecnologia
• Aqueles afetados pela mudança de serviço ou Transição de Serviço
• Fornecedors de bens ou serviços para o serviço pacote ou pacote de
serviços
• Serviço de Gestão de equipes envolvidas no serviço novo ou alterado
• Clientes ou consumidores que serão afetados pela Transição de Serviço
ou o serviço novo ou alterado
• Relação equipe de gestão
• Interna e / ou externa auditar
• Informações segurança
• Unidade de fraude
• Gestão de risco
• Acionistas, administradores e funcionários da organização
• Grupos de trabalho / sindicatos
• Órgãos políticos ou regulamentares
• A comunidade em geral, tais como o público em geral
• Projeto e programa equipas de gestão de entrega dos projetos dentro do
serviço geral ciclo de vida.
Adas partes interessadas A análise ajuda a garantir que não há conhecimento
suficiente da parte interessada exigências e interesse da parte interessada, e
impacto ligada, a mudança. Posições das partes interessadas (em termos de
influência e impacto) pode ser racional e justificável, ou emocional e infundadas.
No entanto, todos eles devem ser levados em conta, pois, por definição, os
interessados podem afetar a mudança processo e, portanto, o Transição de
Serviço.

Muitas vezes há um elemento de re-utilizável do mapa de stakeholders e
análise. Por exemplo, onde muitos projetos estão entregando em um serviço
compartilhado e infra-estrutura, os interessados pode ser o mesmo: incluindo o
negócio patrocinador, o Operação de Serviçoo gerente, o chefe da Serviço de
Gestão de e os membros do Alterar Conselho Consultivo.
A análise das partes interessadas ajuda a garantir que os canais de
comunicação são direcionados de forma adequada e que mensagens, mídia e
níveis de detalhe refletir as necessidades das partes interessadas. Os canais de
comunicação podem necessitar para acomodar os interessados que não podem
ser contratados diretamente com a Transição de Serviço. Em muitos casos,
trabalha através de parceiros, grupos industriais, órgãos reguladores, etc pode
ser necessária. Muitas vezes, uma abordagem maior comunicação, abrangendo
todas as áreas, pode ajudar a fornecer uma mensagem consistente e mais forte
do que ao operar a nível funcional.
Uma técnica para analisar as partes interessadas é considerar cada parte
interessada, em termos de sua importância para a Transição de Serviço e do
impacto potencial da mudança sobre eles e "enredo"-los em uma matriz (ver
Figura 5.7). Isto irá orientar as atividades que Transição de Serviço devem
adotar. Por exemplo, um patrocinador empresarial terá um 'alto' estado de
importância para a mudança de serviço em geral, e, dependendo da escala e
oportunidades para qualquer retorno do seu investimento, o impacto do novo
serviço ou alterados pode ser "baixo", "médio" ou "alto".

Figura 5.7 matriz de impacto de energia
Os interessados podem se mover para cima ou para baixo a matriz como o
pacote de serviços progride através do ciclo de vida, Por isso é importante rever
o trabalho de análise das partes interessadas em especial durante o
planejamento detalhado para a Transição de Serviço. Partes interessadas
responsáveis podem e devem melhorar e até mesmo alterar o curso da
5.3.2.1 mudanças Stakeholder
Durante o ciclo de vida do serviço, os interessados podem ir e vir. As principais
partes interessadas, tais como os patrocinadores da mudança, deve (espero!)
permanecem constantes ao longo. Mas suficiente registros e documentação
será mantida para permitir efetiva entrega no evento indivíduos são substituídos;
suficiente é apanhado de acordo com o negócio risco e custar.
Alguns interessados poderão participar em papéis de consultoria ou garantia,
outros será importante para avaliar a realização dos benefícios, outros terão um
auditar perspectiva.

5.3.3 Mudanças no compromisso das partes interessadas
Figura 5.8 é um exemplo compromisso plano. Isso mostra o nível de
comprometimento atual de indivíduos e grupos, e como esse compromisso deve
mudar se o transição É para ser bem sucedido.
Figura 5.8 Exemplo gráfico de planejamento compromisso
Cada indivíduo é classificado com um "O" para indicar sua posição atual e um 'X'
para indicar o grau de compromisso necessário com eles. Às vezes eles
precisam dar um passo atrás, por exemplo, o diretor partida de cliente na tabela
teria que entregar a liderança papel.
6 Organizador Transição de Serviço
Uma característica de um processo é que todas as atividades relacionadas não
precisa necessariamente ser limitada a uma unidade organizacional específica.
SACM, por exemplo, pode ser conduzida em departamentos como Operação de
Serviço,gerenciamento de aplicativos, Gerenciamento de rede, sistemas de
desenvolvimento e não os departamentos de TI, como aquisições. Como os
processos e suas atividades são executados através de uma organização como
um todo, as atividades devem ser mapeados para os departamentos de TI
existentes ou seções e coordenado pelo gerente de processos. Uma vez
detalhadas procedimentos e instrução de trabalhos foram desenvolvidos, uma
organização irá mapear o seu pessoal para as atividades do processo.
Definições claras de prestação de contas e responsabilidade são fatores críticos
de sucesso para qualquer processo de implementação. Sem isso, os papéis e
responsabilidades dentro do processo novo ou modificado pode ser confuso, e
indivíduos podem reverter para a forma como as atividades foram tratadas antes
dos procedimentos novos ou alterados foram postas em prática.

6,1 papéis genéricos
Responsabilidade de cada um processo e serviço deve ser alocada para a
prestação efectiva de que o serviço ou processo. Todo o pessoal envolvido no
processo de entrega e serviço precisam entender estes papéis e estar ciente de
que a responsabilidade onde se encontra. Esses papéis proprietário não são,
necessariamente, uma pessoa dedicada para cada processo ou serviço. Os dois
papéis fundamentais, proprietário do processo e proprietário do serviço, São
indicados a seguir.
6.1.1 Processo de papel de dono
O proprietário do processo é responsável por garantir que todas as atividades
definidas no processo são realizadas e é responsável por:
• Definir o processo de estratégia
• Ajudar com processo projeto
• Assegurar que a documentação do processo apropriado disponível e
atual
• Definição de políticas adequadas e padrãos para ser utilizado em todo o
processo de
• Periodicamente auditoria do processo para garantir observância para
política e padrões
• Periodicamente revisar a estratégia de processo para garantir que ainda é
apropriado e altere como necessário
• Comunicação de informações de processo ou mudanças apropriadas
para garantir a sensibilização
• Fornecendo processo recursos para apoiar as atividades necessárias ao
longo do Serviço de Gestão de ciclo de vida
• Garantir processo técnicos têm o conhecimento necessário ea
compreensão técnicas e de negócio para entregar o processo, e
compreender a sua papel no processo
• Revisão oportunidades para melhorias de processo e para a melhoria da
eficiência e eficácia do processo
• Enfrentar problemas com o funcionamento do processo de
• Fornecendo a entrada para o curso plano de melhoria do serviço.
6.1.2 papel de dono de serviço
O proprietário do serviço é responsável perante o cliente para a iniciação,
transição e manutenção e suporte de um determinado serviço.
O proprietário do serviço tem as seguintes atribuições:
• Para atuar como principal contato com o cliente para todas as questões
relacionadas com os serviços e as questões

• Para garantir que a prestação de serviços e suporte contínuos atender
cliente concordou exigências
• Para identificar oportunidades de melhorias no serviço, discutir com o
cliente e aumentar a RFC para avaliação se for caso disso
• Para colaborar com a adequada proprietário do processos ao longo do
Serviço de Gestão de ciclo de vida
• Para solicitar necessários dados, estatísticas e relatórios para análise e
para facilitar o serviço eficaz monitoramento e atuação
• Para prestar contas com o diretor de TI ou Serviço de Gestão de diretor
para a entrega do serviço.

6,2 contexto organizacional para a transição de um serviço
Outras unidades organizacionais e terceiros precisa ter relação claramente
definida e pontos de entrega com Transição de Serviço para garantir a entrega
do definido entregas dentro do cronograma acordado.
Programas, projetos, Design de Serviços e fornecedors são responsáveis pelo
fornecimento de serviço ativos e componentes, de acordo com os requisitos do
Design de Serviços, SLAs e contratos, além de iniciar quaisquer mudanças que
afetem um serviço liberar ou desenvolvimento.
Transição de Serviço irá adquirir mudanças, ativos de serviços e componentes
desses partidos. Um exemplo de serviço de Transição organização encontra-se
ilustrada na Figura 6.1, além de outras equipas no interior da De serviços de
TIsorganização.
Figura 6.1 Exemplo de organização de Transição de Serviço e suas interfaces
Como mostrado acima, existem interfaces para projetos e operações comerciais
que precisam ser claramente definidas. É essencial que todo o Serviço de
Gestão de ciclo de vida há clara interação e compreensão de responsabilidade
por tudo o que nenhum elemento pode funcionar isoladamente. É fundamental
que os projectos têm uma compreensão clara do Design de Serviços,transição e
operações exigências objetiva e de entrega, e vice-versa.

Muitas vezes, projetos e programas vai trabalhar de forma isolada Transição de
Serviço e operações, acreditando que eles não têm nenhum papel a
desempenhar na prestação de serviços em curso. Da mesma forma, a transição
e operações pode ignorar projeto em andamento atividade, Trabalhando na base
de que eles só vão se preocupar com isso, uma vez que é "por sua vez a sua"
para lidar com isso. Esta é uma abordagem muito míope e que deve ser
removido.
Cooperação, entendimento e respeito mútuo são fundamentais para garantir que
a entrega nova, alterados e contínua de serviços à cliente são otimizard.
Figura 6.2 ilustra a interação necessária entre os programas, projetos e Serviço
de Gestão de elementos.
Figura 6.2 interfaces organizacionais para uma Transição de Serviço
Durante o liberar e desenvolvimento haverá interacções com o negócio, Clientes
e usuários e essas responsabilidades são definidas nesta seção.

6,3 modelos de organização para apoiar a Transição de
Serviço
Muitas pessoas e processos estão envolvidos na Transição de Serviço. Alguns
de a principal organização exigências que suportam a aplicação de ITIL
melhores práticass para a Transição de Serviço são descritos nesta seção.
6.3.1 Gerenciamento de Transição de Serviço
Transição de Serviço requer uma gestão activa, com o reconhecimento da sua
chave papel na entrega eficaz De serviços de TIs dentro de uma organização.
Um elemento-chave deste reconhecimento é a atribuição do papel de Transição
de Serviço gerente.
Um exemplo de um função ou estrutura organizacional para a Transição de
Serviço é mostrado na figura 6.3.
Figura 6.3 Exemplo de uma organização para a Transição de Serviço
6.3.2 Serviço de Transição papéis e responsabilidades
Os papéis e responsabilidades específicos abrangidos nesta secção referem-se
principalmente à Transição de Serviço, embora eles vão ser utilizados, em certa
medida por outros processos dentro do Serviço de Gestão de ciclo de vida.
Estes são os seguintes:
• Transição de Serviço gestão

• Planejamento e apoio
• Ativo de Serviço e Gerenciamento de Configuração e Gestão da Mudança
• Atuação e risco avaliação
• Serviço Gestão do Conhecimento
• Serviço teste gestão
• Solte e desenvolvimento
• Embalagem e lançamento construir
• Desenvolvimento
• Apoio início da vida
• Construir e ambiente de teste gestão.
Dependendo do tamanho do organização e a escopo do serviço sendo a
transição, alguns destes papéis serão combinados e realizados por um
indivíduo. No entanto, o teste de serviço de teste de gestão e física deve ser
sempre realizada por recursos independentes da outra funçãos ou processos.
É essencial reconhecer que todo o pessoal envolvido na Transição de Serviço
são responsáveis por:
• Identificação e obtenção de riscos e problemas, que podem directamente
relacionados com a sua área de processo ou pode ser algo que eles
observam em outros lugares, dentro ou fora de Transição de Serviço
• Estar constantemente atento e compreender o contexto de negócio em
que eles estão trabalhando e entender o negócio do cliente precisa dos
serviços que estão fornecendo
• Ser plenamente consciente projetos em curso ea entrega do serviço
esperada desses projetos, incluindo potencial impacto em sua área de
responsabilidade
• Garantir que eles seguem o publicado padrãos para a documentação,
mudança, ativos e Gerenciamento da Configuração e Gestão do
Conhecimento processos assim o incidente e Gerenciamento de
Problemas processos. Onde não existem padrões, levantando-a como um
risco na primeira oportunidade.
6.3.2.1 O gerente de Transição de Serviço
O Transição de Serviço gerente tem dia-a-dia de gestão e controlar das equipes
de serviço de transição e suas atividades. As responsabilidades principais para
este papel são os seguintes:
• Global planejamento e gestão da prestação de Transição de Serviço
incluindo Melhoria de Serviço Continuada
• Gestão e coordenação da Transição de Serviço funçãos
• Orçamento e contabilidade para atividades de serviço de transição da
equipe e recursos

• Agindo como a principal interface para a gerência sênior em termos de
planejamento Transição de Serviço e relatórios
• Fazer uma recomendação final para o negócio e TI a respeito das
decisões para liberar e implementar em produção
• Assegurar todas as políticas organizacionais e procedimentos são
seguidas durante todo transição
• Garantindo a entrega final atenda o acordado cliente e das partes
interessadas exigências especificado no Desenho de Serviço.
6.3.2.2 Planejamento e apoio
Planejamento e apoio não pode ser uma responsabilidade direta do gerente de
Transição de Serviço, como em algumas organizações esta função pode ser
consolidados em um total Serviço de Gestão de escritório / planejamento de TI
responsabilidade. Independentemente de onde essa função se senta, o papel
ainda devem ser realizadas.
Esta função fornece suporte para o Transição de Serviço equipes e pessoas. As
atividades incluem:
• A definição dos requisitos, processos e ferramentas para planejamento de
transição e suporte
• Manutenção e integração de nível inferior planos para estabelecer os
planos globais integradas de transição, incluindo os valores reais vs
planejadas
• Manutenção e monitoramento progresso nas mudanças Transição de
Serviço, problemas, riscos e desvios incluindo acompanhando o
progresso em ações e mitigação de riscos
• Manter registros em e fornecendo gestão da informação na utilização de
recursos, projetoProgresso de transição / serviço, orçado e real gastar
• Gestão e coordenação de pedidos de recursos
• Coordenar as atividades de Transição de Serviço através de projetos,
fornecedors e equipes de serviço quando necessário
• Transição de Serviço Publishing atuação estatísticas e identificar áreas-
chave para a melhoria
• Compromisso formal qualidade revisões da Transição de Serviço, liberar
e implantação planos e concordou transição atividades de acordo com o
plano de gestão da qualidade
• Apoio a gestão de ferramentas e processos de Transição de Serviço
• Comunicação com das partes interessadass.
6.3.2.3 Ativo de Serviço e Gerenciamento de Configuração e Mudança
As funções de gerenciamento

Design de Serviços é responsável pela concepção do linha de bases apropriado
para o serviço e para identificar o relevante ativoss e cis com a entrada do
gerente de mudança de negócio (s) e outros que têm responsabilidades de
prestação de serviços e manutenção negócio continuidade.
Durante as primeiras fases de um projeto do programa ou escritório de projetos
pode ser responsável pela administração do Gerenciamento da Configuração
processo, Mantendo cópias de documentação relevante sobre a CEI, e controlar
a liberação de itens de configuração após aprovações apropriadas. Em pontos
de libertação definidas para um serviço e pacote de serviços, O escritório do
programa ou projeto passará responsabilidade de Transição de Serviço, que vai
assumir a responsabilidade para gerenciamento de configuração da
documentação CI.
Responsabilidades para revisão e aprovação ativos e CIs todo o serviço ciclo de
vida e durante a implantação precisam ser definidos e atribuídos a indivíduos
com competências adequadas e autoridade.
Papel especificaçãos para o Gestão da Mudança e Ativo de Serviço e
Gerenciamento de Configuração equipes precisam ser desenvolvidos. Funções
típicas incluem:
• Serviço de ativos gerente
• Gerenciador de configuração
• Analista de configuração
• Configuração do administrador / bibliotecário
• CMS / ferramentas de administrador
• Alterar gerente.
Atribuir o gerente de configuração e outras funções-chave como o mais cedo
possível, porque os indivíduos podem ser atribuídos envolvidos na
implementação. Para alguns operacional atividades Gerenciamento da
Configuração exigirá que o pessoal que vai adotar uma abordagem diligente e
prestar a devida atenção aos detalhes.
O gestor de activos serviço
O serviço ativo gerente tem as seguintes atribuições:
• Obras para a geral objetivos acordado com o De serviços de TIs gerente;
implementa serviço da organização Gestão de Ativos política e padrãos
• Avalia Asset Management existente sistemas e a projeto, Implementação
e gestão de sistemas novos / melhorados para eficiência e eficácia,
Incluindo estimativas e planejamento o trabalho e recursos envolvidos, e
monitoramento e relatar o progresso contra o plano

• Concorda escopo dos processos de gerenciamento de ativos, função, Os
itens que devem ser controlados, e as informações que devem ser
registados; desenvolve Asset Management padrãos, planos de gestão de
ativos e procedimentos
• Monta uma campanha de sensibilização para ganhar apoio para novos
procedimentos de gestão de ativos; garante que alterações dos métodos
de gestão de ativos e processos estão devidamente aprovada e
comunicada ao pessoal antes de ser implementado; planos, divulga e
supervisiona a implementação de novos sistemas de gestão de ativos
• Organiza recrutamento e formação de pessoal
• Gerencia a avaliação de ferramentas de gerenciamento de ativos de
propriedade e recomenda aqueles que melhor atender à organização
orçamento, Recurso, os requisitos de escala temporal e técnica
• Gerencia de Gestão de Ativos plano, Princípios e processos e sua
implementação
• Concorda ativos a ser identificados exclusivamente com as convenções
de nomeação, garante que os funcionários cumpram as normas de
identificação para os tipos de objetos, ambientes, processos, ciclo de
vidas, documentação, versãos, formatos, linha de bases, lançamentos e
modelos
• Propõe e / ou concorda interfaces com Gestão da Mudança,gestão de
problemas, Gerenciamento de rede, gerenciamento de liberação,
Operações de computador, logística, finanças e funções de administração
• Planos população do DB activo; gerencia o banco de dados ativo,
bibliotecas centrais e ferramentas; garante limpeza regular da DB de
ativos
• Fornece relatórios, incluindo relatórios de gestão (que indica ação
sugerida para lidar com as deficiências atuais ou previstos), impacto
relatórios de análise e de ativos estado relatórios
• Inicia ações necessárias para garantir fundos para melhorar os níveis de
infra-estrutura e de pessoal, a fim de lidar com o crescimento e mudança
• Auditores assistências para auditar as actividades da Gestão de Ativos
equipe para observância com laid-down procedimentos; garante a acção
correctiva é executada.
O gerenciador de configuração
O gerente de configuração tem as seguintes atribuições:
• Obras para os objectivos globais acordado com o gerente de serviços de
TI; implementa a organização Gerenciamento da Configuração política e
padrãos
• Avalia existentes Sistema de Gerenciamento da Configuraçãos e a
projeto, Implementação e gestão de novos / melhorados sistemas para
eficiência e eficácia, Incluindo estimativas e planejamento o trabalho e

recursos envolvidos, e monitoramento e relatar o progresso contra o
plano
• Concorda escopo dos processos de gerenciamento de configuração,
função, Os itens que devem ser controlados, e as informações que devem
ser registados; desenvolve padrões de gerenciamento de configuração,
Planos de Gerenciamento de Configuração e procedimentos
• Monta uma campanha de sensibilização para ganhar apoio para nova
Gerenciamento da Configuração procedimentos, garante que as
mudanças nos métodos de gerenciamento de configuração e processos
estão devidamente aprovados e comunicados ao pessoal antes de ser
implementado; planos, divulga e supervisiona a implementação de novos
sistemas de gestão de configuração
• Organiza recrutamento e formação de pessoal
• Gerencia a avaliação de ferramentas de configuração de propriedade de
Gestão e recomenda aqueles que melhor atender a organização de
orçamento,recurso, Calendário e técnico exigências
• Gerencia o Plano de Gerenciamento de Configuração, princípios e
processos e sua implementação
• Concorda CIs a ser identificado exclusivamente com as convenções de
nomeação, garante que os funcionários cumpram as normas de
identificação para os tipos de objetos, ambientes, processos, ciclo de
vidas, documentação, versãos, formatos, linha de bases, liberars e
modelos
• Propõe e / ou concorda interfaces com Gestão da Mudança,gestão de
problemas, Gerenciamento de rede, gerenciamento de versão, operações
de computador, logística, finanças e funções de administração
• Planos população do CMS; gerencia CMS, bibliotecas centrais,
ferramentas, códigos comuns e dados; garante limpeza regular do CMS
• Fornece relatórios, incluindo relatórios de gestão (que indica ação
sugerida para lidar com as deficiências atuais ou previstos), impacto
relatórios de análise e configuração estado relatórios
• Inicia ações necessárias para garantir fundos para melhorar os níveis de
infra-estrutura e de pessoal, a fim de lidar com o crescimento e mudança
• Auditores assistências para auditar as atividades da equipe de
gerenciamento de configuração para observância com laid-down
procedimentos; garante a acção correctiva é executada.
O analista de configuração
O analista de configuração tem as seguintes atribuições:
• Propõe escopo do Activo e processos de configuração, gestão de função,
os itens que devem ser controlados, e as informações que devem ser
registados; desenvolve de Ativos e Gerenciamento da Configuração
padrãos, planos e procedimentos

• Trens de Ativos e especialistas de Gerenciamento de Configuração e
outros funcionários de Ativos e princípios de gerenciamento de
configuração, processos e procedimentos
• Apoia a criação do Activo e Gerenciamento da Configuração Planos e
princípios e sua implementação
• Cria processos de Ativos e Configuração e procedimentos de gestão, que
inclui os procedimentos de inscrição; CI controles de acesso e privilégios;
garante que as funções corretas e responsabilidades são definidas no
Activo e Planos de Gerenciamento de Configuração e procedimentos
• Propõe e concorda com o ativo e CIs de configuração do gerenciador de
ser identificado exclusivamente com as convenções de nomeação,
garante que os desenvolvedores e configuração sistema usuários cumprir
as normas de identificação para os tipos de objetos, ambientes,
processos, ciclo de vidas, documentação, versãos, formatos, linha de
bases, lançamentos e modelos
• Trabalha em coordenação com o administrador de configuração /
bibliotecário sobre a população do activo e CMS; gerencia ativos e CMS,
bibliotecas centrais, códigos comuns e dados; garante limpeza regular do
ativo e CMS
• Utiliza ou fornece o ativo e CMS para facilitar impacto avaliação para
RFCs e para garantir que as mudanças implementadas são como
autorizado; cria uma mudança registros, configuração linha de bases,
embalagem e registro de liberaçãos, a fim de especificar o efeito sobre
CIs de uma mudança autorizada; garante quaisquer alterações para
mudar os registros de autorização estejam sujeitos a procedimentos de
Gerenciamento de Mudança; garante que o ativos e CMS é atualizado
quando uma mudança é implementada
• Usa o ativo e CMS para ajudar a identificar outros CIs afetados por uma
culpa que está afetando um IC
• Executa a configuração auditars para verificar se o inventário de TI física
é consistente com o ativo e CMS e inicia qualquer ação corretiva
necessária
• Cria e preenche projeto bibliotecas e CM sistema, Cheques itens e grupos
de itens para as ferramentas CM
• Aceita linha de based produtos de terceiros e distribui produtos
• Constrói linhas de base do sistema de promoção e liberar
• Mantém projeto estado informações e Relato da situação registros e
relatórios
• Monitores problemas (teste incidentes) e mantém banco de dados para
recolha e comunicação de métricas.
O administrador de configuração / bibliotecário
O administrador de configuração / bibliotecário é o guardião e guardião de todas
as cópias mestre de software, ativos e CIs documentação registrada com Ativos

e Gerenciamento da Configuração. As principais tarefas desta papel são os
seguintes:
• Controlar o recebimento, identificação, armazenamento e retirada de
todos os itens de configuração suportada
• Fornecer informações sobre o estado de CIs
• Número, recorde, armazenar e distribuir de Ativos e questões de
gerenciamento de configuração.
O administrador de configuração / bibliotecário tem as seguintes atribuições
específicas:
• Assistências de Ativos e Gerenciamento da Configuração para preparar o
Plano de Gestão de Ativos e Configuração
• Cria um esquema de identificação para as bibliotecas de Gerenciamento
de Configuração e as Biblioteca de Mídia Definitiva (DML)
• Cria um esquema de identificação de ativos e as peças de reposição
definitiva (DS)
• Cria bibliotecas ou outras áreas de armazenamento para manter CIs
• Auxilia na identificação de produtos e CIs
• Mantém informações sobre o estado atual em CIs
• Aceita e registra o recebimento de novas configurações ou revistas para a
biblioteca apropriada
• Arquivos substituído cópias CI
• As cópias mestre
• Administra configuração controlar processo:
• Distribui mudar pedidos para os membros da equipe para impacto
avaliação
• Valida integridade dos pedidos de mudança
• Rotas solicitações de mudança de autoridade competente para
aprovação
• Progride e rastreia pedidos de mudança até a conclusão
• Relatórios sobre pedidos de mudança
• Decisões sobre registros de solicitações de mudança
• Questões de cópias de produtos para rever, Correção de mudança
ou informação quando autorizado a fazê-lo
• Mantém uma registro de todas as cópias de emissão
• Notifica titulares de quaisquer alterações às suas cópias
• Coleta e retém informações que irão ajudar na avaliação do que
CIs são afetados por uma mudança para um produto
• Produz configuração estado contabilidade relatórios
• Assiste na condução de configuração auditars
• Trabalha em coordenação com outras bibliotecas de configuração onde
CIs são comuns a outras sistemas.
O administrador do CMS / ferramentas

O administrador do CMS / ferramentas tem as seguintes atribuições:
• Avalia Ativos proprietário e ferramentas de gerenciamento de
configuração e recomenda aqueles que melhor atender a organização de
orçamento,recurso, Calendário e técnico exigências; direta ou
indiretamente customiza ferramentas proprietárias para produzir de Ativos
e eficaz Gerenciamento da Configuração ambientes em termos de bases
de dados e bibliotecas de software, fluxos de trabalho e geração de
relatórios
• Monitora o atuação e capacidade de ativos existentes e Gerenciamento
da Configuração sistemas e recomenda oportunidades de melhoria e
compromete limpeza padrão e multa afinação sob a mudança controlar
• Trabalha em coordenação com o analista de configuração e administrador
/ bibliotecário sobre a população do ativos e CMS; fornece administração
e suporte técnico para o ativo e CMS, bibliotecas centrais, códigos de
ferramentas "comuns e dados; compromete limpeza técnica regular do
activo e CMS
• Garante o integridade e operacional o desempenho dos sistemas de CM.
O Conselho de Controle de Configuração
O Conselho de Controle de Configuração é necessário para garantir que a
intenção global e políticas de gerenciamento de configuração são empregados
em todo o Serviço de Gestão de ciclo de vida e com consideração específica
para cada aspecto do processo completo serviço. O Conselho de Administração
tem as seguintes atribuições:
• Define e controla a configuração do serviço linha de bases em termos de
núcleo e serviços de apoio, aplicaçãos, informação, serviço, técnica, infra-
estrutura - a garantia de que cumprem o exigências estabelecidos na
Design de Serviços
• Comentários mudanças na configuração do serviço para observância com
normas, requisitos contratuais e interna
• Origina mudanças de requisitos para configuração do serviço para
cumprir contrato mudar pedidos.
Em algumas organizações, o Conselho de Controle de Configuração será
combinado com mudar, Proporcionando assim uma visão holística dos serviços
atuais e propostas e serviços modelos, permitindo um melhor controle, altere
avaliação,impacto avaliação e compreensão.
A autoridade de mudança
Formal autorização é obtida para cada alteração de uma autoridade de mudança
que pode ser um papel, Pessoa ou um grupo de pessoas. Os níveis de
autorização para um determinado tipo de mudança deve ser julgado pelo tipo,

tamanho ou risco da alteração, por exemplo, mudanças em uma empresa de
grande porte que afetam vários sites distribuídos pode precisar de ser autorizada
por uma autoridade mudança de nível superior como um Conselho Global
Change ou do Conselho de Administração.
O cultura do organização ditames, em grande parte, a maneira pela qual as
alterações são autorizados. Estruturas hierárquicas podem muito bem impor
muitos níveis de autorização mudança, enquanto estruturas mais planas podem
permitir uma abordagem mais racionalizada.
Um certo grau de autoridade delegada pode muito bem existir dentro de um
nível de autorização, por exemplo, delegar autoridade a um gerente de mudança
de acordo com parâmetros pré-definidos relativos a:
• Risco do negócio antecipado
• Implicações financeiras
• Escopo da alteração (por exemplo, efeitos internos apenas, dentro das
finanças de serviços, serviços específicos de terceiros).
Um exemplo de hierarquia autorização é mostrada na Figura 4.5, Exemplo de
uma autorização de mudança modelo.
O gerente de mudança
As principais atribuições do gestor de mudança, alguns dos quais podem ser
delegadas, estão listados abaixo:
• Recebe, registra e aloca um prioridade, Em colaboração com o iniciador,
para todos os RFC; rejeita quaisquer RFCs que são totalmente
impraticáveis
• Mesas de todos os RFCs para uma reunião CAB, as questões de uma
agenda e circula todos os RFCs para os membros do CAB, antes das
reuniões para permitir consideração prévia
• Decide que as pessoas venham a que as reuniões, que recebe RFCs
específicas, dependendo da natureza do RFC, o que deve ser mudado, e
as áreas de atuação das pessoas
• Convoca reuniões urgentes CAB ou ECAB para todos os RFCs urgentes
• Preside todas as reuniões CAB e ECAB
• Depois de considerar o conselho dado pelo CAB ou ECAB, autoriza
mudanças aceitáveis
• Questões alteração de horários, através da balcão de atendimento
• Trabalha em coordenação com todas as partes necessárias para
coordenar a mudança de construção, teste e implementação, de acordo
com os horários

• Atualiza o log de alterações com todo o progresso que ocorre, incluindo
quaisquer ações para corrigir problemas e / ou a ter possibilidades de
melhorar o serviço qualidade
• Comentários todas as mudanças implementadas para garantir que eles
encontram seu objetivos; remete qualquer que foram apoiadas ou tenham
falhado
• Comentários pendentes aguardando todos os RFCs consideração ou
aguardando ação
• Análises alterar o registros para determinar quaisquer tendências ou
problemas aparentes que ocorrem; procura retificação com as partes
relevantes
• Fecha RFCs
• Produz relatórios de gestão regulares e precisas.
Alterar Conselho Consultivo
AAlterar Conselho Consultivo (CAB) é um órgão consultivo. Ele precisa ter
apropriado termos de referência (Por exemplo regularidade reunião, escopo de
influência, e links para programa de gestão).
Para entender mais sobre o específico papel e as responsabilidades do CAB,
ver o ponto 4.2.6.8.
6.3.2.4 Avaliação de desempenho e gestão de risco
As funções a seguir tudo que contribua para a atuação e risco avaliação do
Transição de Serviço processos e decisões-chave, por exemplo, parar ou
segurar o desenvolvimento.
O gerente de avaliação de desempenho e risco
O atuação e risco avaliação gerente tem as seguintes atribuições:
• Usa Design de Serviços e liberar embalagem para desenvolver a
avaliação plano a entrada para o teste de serviço
• Estabelece riscos e problemas associados com todos os aspectos da
Transição de Serviço através de oficinas de risco etc
• Fornece relatório de avaliação para a entrada de Gestão da Mudança.
6.3.2.5 Serviço de Gestão do Conhecimento
Gestão do Conhecimento requer a posse efetiva e autoridade dentro de uma
organização. O papel da Gestão do Conhecimento proprietário do processo é
crucial, na medida em que irá projeto, Entregar e manter a Gestão do
Conhecimento estratégia,processo e procedimentos.

O processo de Gestão de Conhecimento proprietário
O processo de Gestão de Conhecimento proprietário tem as seguintes
atribuições:
• Compromete-se o papel de Gestão do Conhecimento, assegurando
observância com as políticas da organização e processos
• É o arquiteto de identificação do conhecimento, captura e manutenção
• Identifica, controles e lojas de qualquer informação considerada
pertinente para os serviços prestados, que não está disponível através de
quaisquer outros meios
• Mantém os itens de conhecimento controlados para garantir a moeda
• Garante que todos os itens de conhecimento são acessíveis a quem
deles precisa de uma forma eficiente e eficaz
• Monitores de publicidade sobre as informações de conhecimento para
garantir que a informação não é duplicada e é reconhecido como uma
fonte central de informação, etc
• Atua como um consultor de negócios e pessoal de TI em matéria de
Gestão do Conhecimento, incluindo política decisões sobre o valor,
armazenamento, etc vale a pena
6.3.2.6 gerente de teste do serviço
Gestão de teste de serviço é o principal responsável pelo apoio de teste ea
equipe de teste (s) funçãos envolvidos com o específico Transição de Serviço. O
serviço teste gerente se reportará ao gerente de Transição de Serviço assim
como o liberar e desenvolvimento gestor, no entanto, estas funções devem ser
sempre realizados por pessoas diferentes, e nunca ser combinados, para
garantir que haja sempre testes independentes e teste verificação.
O gerente de teste de serviço tem as seguintes atribuições:
• Define o teste estratégia
• Projetos e planos de teste condições, scripts de teste e dados de ensaios
conjuntos para garantir a cobertura adequada e suficiente e controlar
• Aloca e supervisiona teste recursos, garantindo políticas de teste são
cumpridas
• Fornece relatórios de gestão no teste teste de progresso, resultados, as
taxas de sucesso, problemas e riscos
• Realiza testes, tal como definido nas plantas de teste e projeto
• Registros, análises, diagnósticos, relatórios e gerencia teste eventos,
incidentes, problemas e reteste dependente de critérios acordados
• Gerencia ambiente de teste exigências
• Verifica testes realizados pela liberar e desenvolvimento equipes
• Administra teste ativoss e componentes.

Suporte de teste
A principal responsabilidade da equipe de suporte de teste é fornecer o teste
independente de todos os componentes entregues dentro do Transição de
Serviço programa ou projeto. Responsabilidades exigidas para oferecer testes
de serviço de sucesso incluem o seguinte, no entanto, nem todos estes são de
responsabilidade direta da equipe de suporte de teste:
• O gerente de mudança é responsável por garantir que os testes são
desenvolvidos apropriado para as mudanças aprovadas e que
concordaram estratégia de ensaio e política é aplicado a todas as
alterações.
• Analistas de teste realizar a testes, tal como estabelecido nos planos de
teste e / ou pacote de serviços.
• O desenvolvedor /fornecedor é responsável por estabelecer a causa raiz
de teste falhas - o culpa no componente de serviço que fez o teste
falhará. Para situações complexas este pode requerer a colaboração
entre o pessoal de testes e desenvolvimento/construir/ Pessoal
fornecedores. Deve sempre ser aceite como uma possibilidade de que as
falhas podem estar dentro do projeto de teste, bem como dentro de
concepção / desenvolvimento.
• Design de Serviços irá projetar o teste, como um elemento do design de
serviço geral. Para muitos serviços, os testes padrão existirá, talvez
contido no interior da transição modelo escolhido como já aceite como
apropriada para o tipo de serviço novo ou modificado sob consideração.
• Clientes e usuários realizar cliente e usuário aceitação teste. Tal usuário
recurso deve ser capaz de cobrir toda a gama de perfil do usuário e
exigências, e adequadamente assinar a conformidade de um novo ou
alterado serviço. Usuários já terá desempenhado um importante papel
para ajudar a projetar as abordagens de teste de aceitação durante a fase
de projeto.
6.3.2.7 Lançamento e implantação
Solte e desenvolvimento é o principal responsável pela gestão de todos os
aspectos de final-de-final processo de liberação. O gerente de lançamento e
implantação apresentará um relatório ao Transição de Serviço gerente como
será o gerente de teste do serviço, no entanto esses papéis deve ser sempre
efectuada por pessoas diferentes, e nunca ser combinados, para garantir que
não é sempre independente de testes e teste verificação.
O gerente de lançamento e implantação
O liberar e gerente de implantação é responsável pela planejamento, Projeto,
construção, configuração e testes de todos os softwares e hardware para criar o
pacote de liberação para a entrega de, ou alterações a, o serviço designado.

A liberação e desenvolvimento gerente tem as seguintes atribuições:
• Gerencia todos os aspectos do fim-de-final processo de liberação
• Atualiza o SKMS e CMS
• Garante a coordenação das construir e ambiente de teste equipe e liberar
equipes
• Garante equipes seguem políticas estabelecidas da organização e
procedimentos
• Fornece relatórios gerenciais sobre o progresso de liberação
• Lançamento ea implementação de serviços política e planejamento
• Ofertas com design pacote de lançamento, construção e configuração
• Lida com a aceitação de lançamento do pacote incluindo negócio sign-off
• Lida com serviço de método de planejamento roll-out, incluindo a
implantação de
• Lida com testes de liberação de pacote aos critérios de aceitação pré-
definidos
• Sinais fora do pacote de lançamento para a implementação
• Lida com a preparação, comunicação e treinamento
• Auditorias hardware e software antes e depois da implementação de
mudanças do pacote de liberação
• Instala hardware novo ou atualizado
• Lida com o armazenamento ea rastreabilidade / auditabilidade do
software controlada em ambos centralizada e distribuída sistemas
• Lida com liberar, Distribuição e instalação de software empacotado.
No entanto, algumas dessas responsabilidades serão delegadas à equipe de
lançamento relevante sub-processo.
O principal componentes para ser controlada são:
• Documentação de serviço, incluindo:
• Catálogo de serviços
• Acordo de nível de serviço, Olas e UCs
• Design de Serviços e especificação
• Aplicação programas desenvolvidos em casa
• Software desenvolvido externamente (incluindo padrão off-the-shelf
software, bem como costume escrito software)
• Utilidade software
• FornecedorFornecido sistemas software
• Especificações de hardware, e hardware
• Montagem instruções e documentação, incluindo usuário manuais.
Todos entregas precisam ser geridos de forma eficaz, a partir de
desenvolvimento ou adquirir, através da personalização e configuração, através
de testes e implementação, para operação no ambiente ao vivo.

6.3.2.8 embalagem Lançamento e construir
Embalagem e lançamento construir gestão é o fluxo de trabalho (criar
exigências, a de projetar, construir, implantar, operar e otimizar) Para entregar
aplicações e infra-estrutura que atendam aos requisitos de design de serviço.
A embalagem de lançamento e construção de gerente
O liberar gerente de embalagens e construção tem as seguintes atribuições:
• Estabelece a configuração versão final (por exemplo, o conhecimento, a
informação, hardware, software e infra-estrutura)
• Constrói a entrega versão final
• Testa a entrega final antes do teste independente
• Estabelece e relatórios pendentes erro conhecidos e solução alternativas
• Fornece a entrada para a implementação final sign-off processo.
A embalagem liberação e gerente de compilação não pode realizar esse papel
em isolamento; outro funçãos com o qual haverá interface significativa são:
• Gestão de Segurança
• Gerenciamento de testes
• Alterar e Serviço de Gerenciamento de Configuração de Ativos
• Gerenciamento de capacidade
• Gerenciamento de disponibilidade
• Gerenciamento de incidentes
• Qualidade gestão.
6.3.2.9 Implantação
Desenvolvimento funcionários têm as seguintes responsabilidades:
• Lidar com a entrega física final da implementação do serviço
• Coordenar liberar documentação e comunicação, incluindo a formação e
cliente, Serviço de Gestão de e notas de lançamento técnicos
• Planejar a implantação em conjunto com mudar e Gestão do
Conhecimento e SACM
• Prestar assistência técnica e aplicação orientação e apoio durante todo o
processo de liberação, Incluindo erro conhecidos e solução alternativas
• Fornecer feedback sobre o eficácia da libertação
• Métricas recorde de implantação para garantir dentro de SLAs acordados.
6.3.2.10 apoio Início da vida
É muitas vezes acredita que apoio início da vida começa quando o serviço foi
realmente transferida para operacional usar. Este não é o caso. Suporte de vida

precoce deve ser considerada como um papel integral no interior do liberar e
implantação de fase.
Início da vida pessoal de apoio têm as seguintes atribuições principais:
• Fornecer De serviços de TI e apoio às empresas funcional de antes para
a final aceitação por Operação de Serviços
• Garantir a entrega de documentação de suporte adequado
• Fornecer aceitação liberação para a prestação de apoio inicial
• Proporcionar o apoio inicial em resposta às incidentes e erros detectado
dentro de um novo serviço ou alterados
• Adaptar e aperfeiçoar elementos que evoluem com o uso inicial, tais
como:
• Usuário documentação
• A documentação de suporte, incluindo balcão de atendimento os
scripts
• Gerenciamento de dados, incluindo o arquivamento
• Incorporar atividades para um serviço novo ou alterado
• Lidar com formais transição do serviço de Operações de Serviço e CSI
• Monitorar incidentes e problemas, e empreender gestão de problemas
durante a liberação e implantação, levantando RFCs como necessário
• Fornecer inicial atuação elaboração de relatórios e realizar o serviço
avaliação de risco com base no desempenho.
6.3.2.11 Build e gestão de ambiente de teste
O construir e ambiente de teste função é principalmente para assegurar que
todas as pessoas relevantes têm os ambientes adequados, teste dados, etc
software com versão disponível no momento em que eles precisam e para o
propósito certo. Como ambiente recursos são, normalmente, limitado, isto papel
executa um papel de coordenação e, por vezes arbitrária para garantir que
recursos são utilizados para o efeito máximo.
Construir e testar equipe ambiente têm as seguintes atribuições principais:
• Garantir infra-estrutura de serviços e aplicações são construídas para
projeto especificação
• Aquisição plano de implementação, construção e manutenção de infra-
estruturas TIC
• Certifique construir entrega componentes são controlados a partir de
fontes
• Desenvolver um sistema integrado aplicação software e infra-estrutura
construir
• Entregar construção apropriado, operações e documentação de suporte
para a construção e ambiente de testes antes da entrega ao Operação de
Serviços

• Construir, entregar e manter ambientes de testes necessários.

Transição de Serviço 6,4 relacionamento com os estágios do
ciclo de vida de outros
Transição de Serviço apresenta-se como uma discreta ciclo de vida passo, mas
isto não deve ser tomado como implicando que ele pode estar sozinho.
Transição de Serviço existe para prestar os conceitos documentadas dentro
Design de Serviços através de Operação de Serviços para o dia-a-dia de gestão,
e assim, sem design e operações que não tem propósito.
6.4.1 relações a montante de Transição de Serviço
6.4.1.1 mobilidade do pessoal Lógico
Transição de Serviço toma sua forma e entrada do estratégia definido pela
organização e dos serviços novos ou alterados é acusado de pôr em viver
operação, Ou seja, por a saída do Design de Serviços fase. Sua própria
natureza, é, portanto, dependente de sua relação com "áreas a montante».
Na maioria das organizações, muitos funcionários vai entregar tarefas
apropriadas para mais de uma ciclo de vida fase. Na verdade, as habilidades ea
experiência acumulada pela Transição de Serviço e pessoal de operações de
serviço será tipicamente valioso nas fases a montante do seu foco nominal.
Figura 6.4 Fluxo de experiência
Especificamente, Transição de Serviço dependerá experiência adequada de
operações de pessoal qualificado para fornecer grande parte do conhecimento
necessário para tomar decisões importantes, com base na previsão de
probabilidade de sucesso prática com base no comportamento anterior sistemas
em situações semelhantes, como mostrado na Figura 6.4.
Quando Design de Serviços estabelece o melhor transição abordagem, e
quando, dentro de Transição de Serviço, a viabilidade dessa abordagem é
avaliada Transição de Serviço e Operação de Serviço estão em melhor posição
para jogar a papel da entrada de especialista no assunto, e fornecer ao
avaliação e avaliação de viabilidade inicial e contínua do design.

Operação de Serviço pessoas estarão envolvidas em operações de tarefas
(design e) diretamente através da população Serviço do Sistema de Gestão do
Conhecimento com precedentes e experiências detectadas durante as fases de
operação do serviço - por exemplo, através de incidenteproblemaErro de ciclos.
Isto irá conduzir decisão informada e correta de fazer os processos e facilitar a
Transição de Serviço mais eficaz.
A fim de conservar e fazer uso eficaz de experiências, a equipe pode muito bem
encontrar-se alocado (total ou parcialmente) de tarefas de operações para
apoiar um exercício de design e depois seguir esse serviço através de Transição
de Serviço. Eles podem, em seguida, através apoio início da vida atividades,
mover-se em apoio dos serviços novos ou alterados foram envolvidos na
concepção e implementação no viver ambiente.
Consultoria especializada em transição (como com o design e operações)
também irá contribuir com conhecimentos para o desenvolvimento e
manutenção de Estratégia de Serviço.
6.4.1.2 Processo de comunicações
Muitas das capacidades de um serviço que requerem testes e aceitação com
transição são estabelecidos e abordagem e medidas definidas no design. Como
descrito acima, este exercício é provável que tenha envolvido equipe de
transição de serviço, quer através do envolvimento directo (talvez mesmo
destacamento formal) ou através de consulta e aconselhamento especializado.
6.4.2 processo de Downstream e influência procedimento
Muitos elementos iniciadas ou aperfeiçoadas durante Transição de Serviço será
estabelecido e se transformam em elementos-chave dentro Operação de
Serviço.
Durante o teste de transição incidentes será detectado que revelam erros dentro
do serviço novo ou alterado. A natureza e identificado resolução desses erros
dará entrada direta para as operações de serviço procedimentos para apoiar o
serviço novo ou alterado em viver usar. Entrada de Transição de Serviço é
susceptível de afectar a maioria das áreas do palco operações.
Testes irão partilhar com processos operações, possivelmente com algumas
variações no processo, por exemplo, para acomodar as diferentes exigências e
risco ambientes de análise e rectificação de erros nos testes e viver ambientes.
Onde o teste detecta erros em um novo serviço ou alterados que não são
significativos o suficiente para impedir que o liberar do serviço, esses erros são
liberados no ao vivo banco de dados de erros conhecidosE notificação é

passada para Melhoria de Serviço Continuada, Através dos quais, SKMS CSI
farão uso extensivo de.

7 considerações de tecnologia
A tecnologia tem um grande papel a desempenhar na Transição de Serviço, E
isso deve ser projetado, e mecanismos de manutenção e maximização de
benefícios que a tecnologia deve estar no lugar.
Há duas maneiras em que Transição de Serviço é suportado pela tecnologia:
• De toda a empresa de ferramentas que suportam o mais amplo sistemas
e processos em que Transição de Serviço oferece suporte
• Ferramentas voltado mais especificamente a apoiar Transição de Serviço
ou partes de Transição de Serviço.
A seguir sistemas, suportando a maior escopo, Irá fornecer suporte
automatizado para alguns elementos da gestão de Transição de Serviço:
• IT Service Management sistemas:
o Empresa estruturas que fornecem capacidades de integração para
integrar e vincular no CMDB ou ferramenta
o Rede do sistema, e gerenciamento de aplicativos ferramentas
o Serviço painel de instrumentoss e ferramentas de informação
• Tecnologia de ITSM e ferramentas específicas que compreende:
o Serviço do Sistema de Gestão do Conhecimento
o Colaboração, gerenciamento de conteúdo, ferramentas de fluxo de
trabalho
o Ferramentas de mineração de dados
o Extrair, carregar e ferramentas de transformação de dados
o Sistemas de medição e elaboração de relatórios
o Gerenciamento de testes e ferramentas de teste
o Banco de dados e ferramentas de teste de gerenciamento de
dados
o Copiar e publicar ferramentas
o Solte e desenvolvimento tecnologia
o Implantação e sistemas de logística e ferramentas.
Existem muitas ferramentas de apoio que podem ajudar Gestão da
Mudança,Gerenciamento da Configuração e Gerenciamento de Liberação. Estes
podem vir de uma variedade de combinações e incluem:
• Sistema de Gerenciamento da Configuraçãos e ferramentas
• Versão controlar ferramentas
• DocumentoSistemas de gestão
• ExigênciaA análise e projeto ferramentas, sistemas arquitetura e
ferramentas CASE, o que pode facilitar impacto a partir de uma análise
perspectiva de negócios

• Gerenciamento de banco de dados auditar ferramentas para controlar
bancos de dados físicos
• Distribuição e ferramentas de instalação
• Ferramentas de comparação (arquivos de software, diretórios, bancos de
dados)
• Construir e ferramentas de libertação (que fornecem listas de entrada e
saída de CIs)
• Instalação e desinstalação ferramentas (que fornecem listas de IC
instalado)
• Ferramentas de compressão (para economizar espaço de
armazenamento)
• Listagem e configuração linha de base ferramentas (por exemplo, listas
de diretórios completos com data e hora selos e somas de verificação)
• Descoberta e ferramentas de auditoria (também chamados de "inventário"
de ferramentas)
• Detecção e recuperação ferramentas (onde a construção é devolvido a
um estado conhecido)
• Mapeamento, visualização e representações gráficas com drill-down
• Ferramentas de relatórios, incluindo os que acessam objetos de várias
bases de dados, fornecendo relatórios integrados em sistemas.

7,1 Ferramentas de Gestão do Conhecimento
Gestão do Conhecimento ferramentas de atender as necessidades de uma
organização para a gestão para o processamento de informações e promulgar
conhecimento. Gestão do Conhecimento ferramentas de atender aos requisitos
de manutenção registros e documentos eletronicamente. Os registros são
distinguidos dos documentos pelo fato de que eles funcionam como evidências
de atividades, ao invés de evidências de intenções. Os exemplos de
documentos que incluem política declarações, planos, procedimentos, acordo de
nível de serviços e contratos.
• A gestão de documentos - Define o conjunto de recursos para suportar
o armazenamento, proteção, arquivamento, classificação e retirada de
documentos e informações
• Gerenciamento de registros - Define o conjunto de recursos para
suportar o armazenamento, proteção, arquivamento, classificação e
aposentadoria de registros
• Gerenciamento de conteúdo - O capacidade que gerencia o
armazenamento, manutenção e recuperação de documentos e
informações de um sistema ou site. O resultado é muitas vezes um
conhecimento ativos representado em palavras escritas, figuras, gráficos
e outras formas de apresentação do conhecimento. Exemplos de serviços
de conhecimento que apoiam directamente o gerenciamento de conteúdo
são:
o publicação de ferramentas da web
o conferência web, wikis, blogs etc
o processamento de textos
o dados e análise financeira
o ferramentas de apresentação
o de criação de fluxogramas
o conteúdo gestão da informaçãos codificar (, organizar, versão
controlar,documento arquiteturas)
o Publicação e distribuição.

7,2 Colaboração
A colaboração é a processo de compartilhamento de conhecimento tácito e
trabalhar juntos para atingir objetivos declarados e objetivos. A seguir, uma lista
de serviços de conhecimento, hoje amplamente disponíveis, que, quando
devidamente implementado, pode melhorar significativamente a produtividade
das pessoas, simplificando e melhorando a forma como colaborar:
• Calendários partilhados e tarefas
• Fóruns de discussões
• Mensagens instantâneas
• Branco-embarque
• Vídeo ou teleconferência
• E-mail.
7.2.1 Comunidades
Comunidades estão rapidamente se tornando o método de escolha para grupos
de pessoas espalhadas em diferentes fusos horários e limites do país para se
comunicar, colaborar e compartilhar conhecimento. Estas comunidades são
normalmente facilitada através de um meio online, como uma intranet ou
extranet e da comunidade, muitas vezes funciona como o ponto de integração
para todos os serviços de conhecimento prestados aos seus membros. Bem
administradas comunidades normalmente eleger um líder para gerenciar e
executar a comunidade e um grupo de especialistas no assunto para contribuir e
avaliar o conhecimento ativoss dentro da comunidade. Exemplos de serviços e
funçãos desde dentro da comunidade on-line típico são:
• Portais de comunidades
• E-mail gestão apelido
• Grupos de foco
• Propriedade intelectual, melhores práticas, Exemplos de trabalho e
repositório de modelos
• On-line eventos e mostra líquidos.
Comunidades bem-sucedidas costumam implementar uma recompensa e
reconhecimento programa para seus membros. Tal programa é um meio para
reconhecer e recompensar a contribuição dos ativos de conhecimento valiosos.
Esses ativos são enviadas pelos membros da comunidade e são avaliadas pelo
líder da comunidade e os especialistas eleitos assunto. O autor (es) são então
reconhecido dentro da comunidade e significativamente recompensado de
alguma forma pela sua contribuição. Esta é uma forma altamente eficaz de
incentivar os membros a partilhar os seus conhecimentos e se mover passado o
velho paradigma de que o conhecimento é poder e trabalho segurança e,
portanto, precisa ser acumulado. Além disso, é altamente recomendado que a
alta administração participa ativamente destas comunidades para promover uma

cultura e ambiente que recompensa o compartilhamento de conhecimento e
colaboração.
7.2.2 gestão de fluxo de trabalho
Gestão de fluxo de trabalho é outra área ampla de serviços de conhecimento
que fornece suporte sistêmico de gestão de ativos de conhecimento através de
um fluxo de trabalho pré-definido ou processo. Ativos de conhecimento de
muitos hoje passam por um processo de fluxo de trabalho que cria, modifica,
aumenta, informa, ou aprova os aspectos do ativo. Por exemplo, na esfera de
gerenciamento de aplicativos, Um Requisição de Mudança (RFC) é um ativo de
conhecimento que se move através de um fluxo de trabalho que cria, modifica,
avalia ele, estima que, aprova-lo e, finalmente, implanta-lo. Fluxo de trabalho
aplicaçãos fornecer a infra-estrutura e apoio necessários para implementar um
processo altamente eficiente para realizar estes tipos de tarefas. Típicos
serviços de fluxo de trabalho oferecido nesta serviços categoria incluem:
• Fluxo de trabalho projeto
• Objetos de roteamento
• Serviços de eventos
• Portão de manter em postos de controle de autorização
• Estado transição serviços.

7,3 Sistema de Gerenciamento da Configuração
Muitas organizações têm alguma forma de Gerenciamento da Configuração em
operação, Mas é muitas vezes baseados em papel. Para infra-estruturas
grandes e complexas, Gerenciamento de Configuração vontade operar mais
eficácia quando suportada por uma ferramenta de software que seja capaz de
manter um CMS. O CMS contém detalhes sobre o atributos e da história de
cada CI e detalhes do importante relaçãos entre CIs. Idealmente, qualquer
CMDB deve ser ligada ao DML. Muitas vezes, várias ferramentas precisam ser
integradas para fornecer a solução totalmente automatizada em todas as
plataformas, por exemplo, federado CMDB.
O Sistema de Gerenciamento da Configuração Deve evitar alterações sejam
feitas no Infra-estrutura de TI ou serviço configuração linha de base sem
autorização válida por meio de Gestão da Mudança. A autorização registro deve
automaticamente 'dirigir' a mudança. Na medida do possível, todas as alterações
devem ser registados no CMS, pelo menos, no momento em que a mudança
seja implementada. O estado (Por exemplo, 'viver',' Arquivo ', etc) de cada IC
afetado por uma alteração deve ser atualizado automaticamente, se possível.
Exemplo maneiras em que esta gravação automática de mudanças poderiam
ser implementadas incluem a atualização automática do software CMS quando é
movida entre as bibliotecas (por exemplo, de "teste de aceitação" ao "viver', Ou
de' live 'para uma' biblioteca de arquivo '), quando o catálogo de serviços é
mudado, e quando um liberar é distribuído.
O Sistema de Gerenciamento da Configuração devem, além disso, proporcionar:
• Suficiente segurança controles para limitar o acesso com base na
necessidade de saber
• Suporte para CIs de complexidade variável, por exemplo, todo sistemas,
lançamentos, itens de hardware individuais, módulos de software
• Relações hierárquicas e de rede entre os ICs; mantendo informações
sobre as relações entre itens de configuração, ferramentas de
gerenciamento de configuração facilitar a impacto avaliação de RFCs
• Fácil adição de novo CIS e exclusão de itens de configuração de idade
• Automático validação de dados de entrada (por exemplo, são todos
nomes CI único?)
• Determinação automática de todas as relações que podem ser
estabelecidas automaticamente, quando novos itens de configuração são
adicionados
• Suporte para CIs com diferentes modelo números, versão números, e
números de cópias
• Identificação automática de CIs afetada quando qualquer outro CI é o
tema de uma incidente relatório / registro, registro de problema,registro de
erro conhecido ou RFC

• Integração de gestão de problemas dados dentro do CMS, ou pelo menos
uma interface do Sistema de Gestão de Configuração para qualquer
banco de dados de problemas distintos de gestão que possam existir
• Atualização automática e gravação do número de versão de um IC se o
número de versão de qualquer componente CI é alterado
• Manutenção de um histórico de todos os itens de configuração (tanto a
histórica registro da versão atual - como a data de instalação, registros de
alterações, locais anteriores, etc - e de versões anteriores)
• Apoio à gestão e uso da configuração linha de bases (correspondente a
cópias, versões definitivas, etc), incluindo suporte para a reversão para
versões confiáveis
• Facilidade de interrogatório do CMS e instalações boas reportagens,
incluindo análise de tendência (por exemplo, a capacidade de identificar o
número de RFCs que afetam CIs particular)
• Facilidade de relatórios do inventário CI, de modo a facilitar a
configuração auditars
• Ferramentas de relatórios flexíveis para facilitar a impacto análises
• A capacidade de mostrar graficamente os modelos de configuração e
mapas de ICs interligado, e para inserir informações sobre o novo CIS
através de tais mapas
• A capacidade de mostrar a hierarquia de relaçãos entre 'pai' CIs e
'criança' IC.
Para o software, ferramentas de suporte deve permitir controlar ser mantida,
para aplicações de software, desde o início da análise de sistemas e projeto até
à viver execução. Idealmente, as organizações devem utilizar a mesma
ferramenta para controlar todas as fases do ciclo de vida, Embora isso possa
não ser possível se a todas as plataformas não pode ser suportado por uma
ferramenta de software. Se isto não for possível, então, a infra-estrutura ITSM
Gerenciamento da Configuração ferramenta deve, pelo menos, permitir a
configuração Gestão da informação a ser transferidos a partir de um software
desenvolvimento Sistema de Gerenciamento da Configuração no CMS, sem a
necessidade de re-digitação.
Estas ferramentas individuais e soluções podem ser integradas com o principal
Serviço de Gestão de sistema ou o Sistema de Gestão de Configuração, onde o
esforço de integração é benéfica. Caso contrário, a integração pode ser
realizada a nível processual ou dados.
Automatizar a descoberta e configuração inicial auditars aumenta
significativamente o eficiência e eficácia de Gerenciamento de Configuração.
Estas ferramentas podem determinar que hardware e software é instalado e
como os aplicativos são mapeados para a infra-estrutura.
Isto significa uma maior cobertura de CIs auditados com o recursoestá
disponível, e os funcionários podem se concentrar em lidar com as exceções em

vez de fazer as auditorias. Se o DML não está integrado com o CMDB pode
valer a pena automatizar a comparação do conteúdo com o CMDB DML.

8 Transição de Serviço Implementação
Implementar Transição de Serviço numa situação de Greenfield, ou seja, um
ponto de partida, onde nenhuma transição de serviço existe, só seria provável se
uma nova provedor de serviços está sendo estabelecida. Portanto, a tarefa para
a maioria das organizações prestadoras de serviços será um dos melhoria de
serviço, uma questão de avaliar a sua abordagem atual para os processos de
transição de serviços e estabelecer as melhorias mais eficazes e eficientes de
fazer, priorizados de acordo com o benefício de negócios que pode ser
alcançado. Orientação considerável sobre este tópico está contido dentro do ITIL
Melhoria de Serviço Continuada publicação, mas o ciclo será tal como ilustrado
na Figura 8.1.

Figura 8.1 Passos para melhorar os processos de Transição de Serviço
Introdução de processos novos ou melhorados ST será uma mudança
significativa organizacional e uma introdução de melhores serviços prestados
pelo provedor de serviços. A partir desse contexto, grande parte da orientação
nesta publicação na prestação de serviços novos ou alterados é directamente
aplicável à introdução de Transição de Serviço em si. Fazer isso é, em si, um
exercício de Transição de Serviço, uma vez que está mudando os serviços
prestados pelo provedor de serviços.

8,1 Estágios da Transição de Serviço introduzindo
As fases de introdução de Transição de Serviço irá corresponder a de outros
serviços, exigindo uma justificação para a sua introdução (considerações
estratégicas), o projeto da Transição de Serviço componentes e, em seguida, a
sua introdução à organização (Trânsito) antes que possam rodar no modo
normal (operações).
8.1.1 Transição de Serviço Justificando
Transição de Serviço é um fator chave para a capacidade do provedor de
serviços para entregar qualidade serviços para o negócio. Eles são o
mecanismo de entrega entre o trabalho de projeto, E os cuidados do dia-a-dia
entregue por operações. No entanto, os processos de transição de serviços nem
sempre são visíveis para os clientes, e isso pode fazer a justificação financeira
difícil. Quando da criação de Transição de Serviço, a atenção precisa ser dada à
maneira de quantificar e mensurar os benefícios, tipicamente como um equilíbrio
entre impacto para o negócio (positivo e negativo) e custar (Em termos de
dinheiro / pessoal recursos) e em termos do que seria evitada pela aplicação de
recurso a qualquer específico transição, Tais como desviar recursos de pessoal
ou atrasar a implementação.
A recolha de provas sobre o custo de Transição de Serviço atual inadequada é
um exercício válido e útil, abordando questões como:
• Custo das mudanças falharam
• Custo extra de transição real em comparação com os custos orçados
• Erros encontrados no viver execução que poderia ter sido detectado
durante a transição de teste.
8.1.2 Transição de Serviço Projetando
Design da Transição de Serviço processos e como eles se encaixam dentro de
uma organização são abordados ao longo desta publicação. Fatores úteis a
considerar ao projetar Transição de Serviço estão descritos abaixo.
8.1.2.1 normas e políticas
Considere como as políticas acordadas, padrãoA legislação e vai restringir o
projeto de Transição de Serviço. Considerações podem incluir exigências para a
independência e responsabilidade visível, como são comumente encontrados
controlar empresas do setor financeiro ou na legislação, como a Lei Sarbanes-
Oxley (SOX).
8.1.2.2 Relacionamentos

Outros serviços internos de apoio
Em transição muitas situações Serviço deve trabalhar em conjunto com outras
áreas que estão em transição outros elementos de um negócio mudar, Como
RH, gestão de instalações, Telecomunicações, produção controlar, Educação e
formação. Os processos serão projetados para facilitar estes relaçãos.
O objetivo deve ser o de garantir que a propriedade para cada componente do
total pacote de serviços é definido e, posteriormente, a responsabilidade da
gestão é clara.
Programa e gerenciamento de projetos
Grandes transições podem ser geridos como programas ou projetos, Transição
de Serviço e vai entregar a sua papel dentro do guarda-chuva apropriado. Áreas
claras de delimitação e colaboração entre programas, projetos e Transição de
Serviço serão necessárias, e estas precisam ser definidas e acordadas no
âmbito da organização. Para assegurar a adequada transição é entregue, a
equipe de transição de serviço serão envolvidos no programa concordando
chave e os marcos do projeto e calendários e ST deve ser configurado para
adotar este papel. Por exemplo, se um projeto deve entregar um grande liberar
no final do mês, ST deve proporcionar suficiente e atempada recursos para linha
de base e liberar o pacote de serviços, no tempo acordado e de acordo com o
acordado qualidade níveis.
Para ser eficaz, Transição de Serviço deve ter uma visão mais ampla em
projetos, combinando transições e libera para fazer o melhor uso dos recursos
disponíveis.
Transição de Serviço irá configurar e manter (trabalhar CSI) uma abordagem
para lidar com um fluxo contínuo de tarefas (Transições de Serviço) que deve
ser entregue, programação, combinando a partilha de recursos e, conforme
apropriado. O estratégia deve procurar estabelecer esse papel para a ST em
conjunto com a autoridade delegada e escalada canais que lhe permitam
proporcionar.
Equipes internas de desenvolvimento e fornecedores externos
Canais de comunicação terá de lidar com defeitos, riscos e problemas
descobertos durante a transição processo, E.g. erros encontrado durante os
testes. Canais para ambas as equipes internas e externas fornecedors terá de
ser identificados e mantidos.
Clientes / utilizadores

Comunicação com os clientes e usuários é importante para assegurar que a
transição serviço irá manter o foco em requisitos de negócios atuais. Os
requisitos de transição real pode evoluir a partir das necessidades identificadas
no projeto palco e os canais de comunicação com o cliente será a fonte de
identificação de tais alterações. Comunicação eficaz irá beneficiar de uma
estratégica acordada das partes interessadas contacte mapa (ver parágrafo
5.3.2). Em muitas circunstâncias, esta comunicação será encaminhado através
do serviço ou de gestão de conta ou SLM, mas esses canais precisam ser
identificados e projetados para os processos de transição de serviço também.
Outras partes interessadas
Os outros interessados precisam fazer a interface com ST, e estes devem ser
identificados para todas as circunstâncias previsíveis, incluindo em desastre
recuperação cenários, e assim por ligação com ITSCM devem ser atendidas.
Outras considerações possíveis podem incluir:
• TI, e.g. redes, TI segurança, Gerenciamento de dados
• Fora dele, mas dentro da organização, por exemplo, gestão de
instalações, RH, segurança física
• Fora da organização, E.g. latifundiários, a polícia e os órgãos
reguladores.
8.1.2.3 Orçamento e recursos
As tarefas necessárias para entregar Transição de Serviço deve entregar um
benefício líquido geral para a organização (ou devem ser revisitado e revisado),
mas mesmo assim eles precisam de financiamento, ea ST estratégia deve
abordar a origem e controlar de provisão financeira.
Abordagem de financiamento
Um mecanismo para controlar o financiamento do transição infra-estrutura deve
ser estabelecida, incluindo:
• Ambientes de teste - Em muitos grupos de organizações de teste
(incluindo aspectos de testes especializados, tais como usabilidade teste)
não estão sob o controle direto de transição. O relação e autoridade para
contratar e alocar recursos precisa ser estabelecido, entendido, mantido e
gerenciado.
• SCM e Serviço do Sistema de Gestão do Conhecimentos - Estes exigem
especificamente o financiamento para a tecnologia e as competências
essenciais para a sua eficácia.
O custeio de transição objetivos tem de ser uma parte integrante da projeto. Isto
aplica-se qualquer que seja o mecanismo de financiamento pode ser, e

envolverá transição atendido e clientes que trabalham com design. Tipicamente
as opções de transição será orçado e um negócio riscoBaseada em decisão
tomada.
Recursos
Da mesma forma que as opções e os problemas enfrentados quando se
considera a fonte de financiamento, e controlar de outra recursos terá de ser
tratada no âmbito da estratégia de ST, tais como:
• Pessoal, por exemplo, a atribuição de projeto de recursos para atividades
de transição
• Infra-estrutura central, por exemplo:
• Central de dados de teste compromisso, entre amplamente
aplicável e re-utilizáveis contra focada em serviços individuais /
recursos
• Os recursos de rede de distribuição de software, documentação e
para o teste de elementos de rede de serviços a ser transferida.
Ambiente de teste gestão é um dos principais itens de despesas e um elemento
significativo de recursos em muitas organizações. Sub-financiamento e / ou falta
de recursos aqui (ou por falta de números ou falta de habilidades necessárias)
pode causar muito caro erros e problemas no apoio viver serviços, e têm graves
efeitos prejudiciais sobre a actividade global da organização capacidade.
8.1.3 Transição de Serviço Apresentando
A experiência mostra que não é aconselhável para tentar adaptar um novo
transição'Práticas s na projetos em curso, os benefícios das melhores (e ainda
não comprovada) práticas são susceptíveis de compensar a interrupção
causada pela mudança de cavalos no meio do caminho. Se uma transição
particular é especialmente problemático, e pode ser relevante para forçar uma
mudança de atitude, em seguida, uma exceção pode ser justificado.
Uma técnica que tem trabalhado em organizações é capturar "em voo"
iniciativas e colocá-los em linha com a nova abordagem. Isso envolve projetos
de ajuste atualmente passando por design / transição e ajustar a sua
planejamento se encaixar com o novo procedimentos, normalmente no teste de
aceitação / go palco ao vivo. Para que isso seja bem sucedido ", rotas de
transição velhos" forma de conversão estratégias para os novos procedimentos
devem ser considerados, projetado (e testados, sempre que possível), como
parte da responsabilidade design.

8.1.4 Culturais aspectos de mudança
Mesmo formalização de procedimentos existentes na maior parte vai entregar
cultural mudar; Se implementar Transição de Serviço num organização significa
a instalação de processos formais que não estavam lá antes da mudança
cultural é significativo. A experiência mostra que o pessoal que trabalha em
Gestão da Mudança, E mesmo aqueles evangelizar mudança entre outros, são
potencialmente tão resistentes à mudança em suas próprias áreas como
qualquer outra pessoa.
Embora importante se concentrar em obter o apoio de pessoal do Serviço de
Transição trabalhando diretamente na Transição de Serviço é igualmente
importante que as pessoas de apoio, e sendo apoiado por, Transição de Serviço
entender por que as mudanças nos procedimentos estão sendo feitos, os
benefícios para si e para o organização e suas funções alteradas. A mudança
cultural programa deve abordar todos das partes interessadass e deve continuar
ao longo e depois da transição, para assegurar que as mudanças de atitudes
foram integradas e não visto como um acessório de moda que pode ser
dispensado depois que o perfil inicial alto desapareceu.
Consideravelmente mais informações sobre a mudança cultural pode ser
encontrada no Capítulo 5.
8.1.5 Risco e valor
Tal como acontece com todas as transições, as decisões em torno transição do
serviço de transição não deve ser feita sem a compreensão adequada dos riscos
e benefícios esperados. Nesta situação específica, os riscos podem incluir:
• Alienação de pessoal de apoio
• Custos excessivos para o negócio
• Atrasos inaceitáveis para benefícios comerciais.
Os riscos e os valores benéficos requerem um linha de base da situação atual,
se as mudanças são para ser mensurável. Medidas do valor acrescentado de
Transição de Serviço podem incluir:
• Cliente e usuário satisfação
• Reduzido incidente e falha taxas de transição para serviços
• Reduzido custar de transição.

9 Desafios, fatores críticos de sucesso e riscos
9,1 Desafios
A complexidade de serviços em todo o cadeia de suprimentos está aumentando
e isso leva a desafios para qualquer prestador de serviços que implementa
novos serviços ou mudanças serviços existentes. TI dentro de e-business não só
apoia o principal processo de negócioes, mas faz parte do principal negócio
processos.
Esta posição privilegiada traz uma ampla gama de desafios para o sucesso do
Transição de Serviço, Tais como:
• Ativando quase todos os negócios processo e serviço em TI, resultando
em um grande cliente e das partes interessadas grupo que está envolvido
e impactado por Transição de Serviço
• Gerenciando muitos contatos, interfaces e relaçãos através de Transição
de Serviço, incluindo uma variedade de diferentes clientes, usuários,
programas, projetos, fornecedors e parceiros
• Não havendo harmonização pouco e integração dos processos e
disciplinas que Transição impacto de serviço, por exemplo, finanças,
engenharia, humana recurso gestão
• Não havendo diferenças inerentes entre o legado sistemas novas
tecnologias, aos elementos humanos que resultam em dependências
desconhecidas e são arriscados para mudar
• Alcançar um equilíbrio entre a manutenção de um estável ambiente de
produção e responder à necessidades do negócio para mudar os serviços
• Atingir um equilíbrio entre o pragmatismo e da burocracia
• Criação de um ambiente que promove a partilha de simplificação,
padronização e conhecimento
• Ser um facilitador de mudanças do negócio e, portanto, um integrante
componente dos programas de mudança de negócios
• Estabelecer os líderes para defender as mudanças e melhorias
• Estabelecer "quem faz o quê, quando e onde" e "quem deve fazer o quê,
quando e onde '
• O desenvolvimento de um cultura que incentiva as pessoas a colaborar e
trabalhar juntos com eficácia e uma atmosfera que estimula a cultural
deslocars necessário para obter buy-in de pessoas
• Desenvolver padrão atuação medidas e métodos de medição em todo
projetos e fornecedores
• Assegurar que o qualidade de entrega e suporte corresponde ao uso
comercial da nova tecnologia
• Assegurar que o tempo de Transição de Serviço e orçamento não é
afetado por eventos anteriormente no serviço ciclo de vida (Por exemplo,
cortes de orçamento)

eficaz gestão de risco dentro de uma organização
• Compreender e ser capaz de avaliar, o equilíbrio entre gestão risco e
assumir riscos, pois afeta a geral estratégia da organização e
incompatibilidade potencial entre projeto riscos e negócio risco
• Avaliando o eficácia de informação em relação à gestão de riscos e
corporativos governo.

9,2 Fatores críticos de sucesso
Prestação de serviços, em todas as organizações, precisa estar de acordo com
as demandas de negócios atuais e em rápida mudança. O objetivo é o de
melhorar continuamente o qualidade de serviço, alinhada ao negócio exigências,
o custo-benefício. Para atingir esse objetivo, o seguinte fator crítico de sucessos
devem ser considerados para Transição de Serviço:
• Compreender e gerir os diferentes das partes interessadas perspectivas
que sustentam a gestão de riscos eficaz dentro de uma organização e
estabelecer e manter as partes interessadas "buy-in" e comprometimento
• Manter os contatos e gerenciamento de todos os relaçãos durante a
transição de serviço
• Integração com as outras fases do ciclo de vida de serviços, processos e
disciplinas que Transição de Serviço impacto
• Compreender as dependências inerentes entre o legado sistemas novas
tecnologias, aos elementos humanos que resultam em dependências
desconhecidas e são arriscados para mudar
• Automatizar processos para eliminar erros e reduzir o tempo de ciclo
• Criação e manutenção de novos conhecimentos e atualização de uma
forma que as pessoas podem encontrar e usar
• Desenvolvimento de sistemas de boa qualidade, ferramentas, processos
e procedimentos necessários para gerenciar uma Transição de Serviço
prática
• Bom Serviço de Gestão de e Infra-estrutura de TI ferramentas e
tecnologia
• Ser capaz de apreciar e explorar o ambiente cultural e político
• Ser capaz de entender as configurações de serviço e técnicos e suas
dependências
• Desenvolver uma compreensão profunda dos fatores rígidos (processos e
procedimentos) e moles (habilidades e competências), fatores
necessários para gerenciar uma prática Transição de Serviço
• Desenvolvimento de uma força de trabalho com o conhecimento e
habilidades, formação adequada e ao direito cultura de serviço
• Definição de responsabilidades claras, papéis e responsabilidades
• Estabelecer uma cultura que permite que o conhecimento seja
compartilhado livremente e voluntariamente
• Demonstrando o tempo de ciclo melhorado de realizar uma mudança e
menos variação no tempo, custar e qualidade previsões durante e depois
transição
• Demonstrando cliente melhorada e usuário índices de satisfação durante
• Demonstrando que os benefícios da criação e da melhoria da prática
Transição de Serviço e processos superam os custos (em toda a
organização e serviços)

• Ser capaz de comunicar a atitude da organização de risco e abordagem
gestão de risco de forma mais eficaz durante as atividades de Transição
de Serviço
ou podem impactar Transição de Serviço de sucesso de serviços na
Portfólio de Serviços.

9,3 Riscos
Implementação da prática Transição de Serviço não deve ser feita sem
reconhecer o risco potencial para serviços actualmente em fase de transição e
os lançamentos que estão previstos. A linha de base avaliação Transições de
serviço atual e planejado projetos vai ajudar Transição de Serviço para
identificar os riscos de implementação.
Estes riscos podem incluir:
• Mudança na prestação de contas, responsabilidades e práticas de
projetos existentes que de motivar a força de trabalho
• Alienação de alguns de suporte e equipe de operações
• Os custos adicionais não planejados para serviços em transição
• Resistência à mudança e de evasão dos processos devido à burocracia
percebida.
Riscos de implementação incluem:
• Custos excessivos para a empresa devido à excessivamente avessos ao
risco Transição de Serviço práticas e planos
• Compartilhamento de conhecimento (como as pessoas erradas podem ter
acesso à informação)
• Falta de maturidade e integração de sistemas e ferramentas resultando
em pessoas 'culpando' tecnologia para outras deficiências
• Deficiente integração entre os processos - causando processo isolamento
e uma abordagem de silo para entregar ITSM
• Perda de horas produtivas, custos mais elevados, perda de receita ou,
talvez, até mesmo as empresas falha como resultado de processos de
transição pobre.

9,4 Transição de Serviço em condições difíceis
Em algumas circunstâncias, a Transitions Serviço será exigido em condições
atípicas ou difíceis, tais como:
• Curto espaço de tempo
• Finanças restritas
• Restringido recurso disponibilidade - Não basta as pessoas ou a falta de
ambientes de teste, ferramentas inadequadas etc
• Ausência de habilidades esperados define
• Dificuldade política interna, os desincentivos pessoal, tais como:
• Redundância/terceirização ou similar ameaças
• Cultura corporativa difícil de estilo de gestão de confronto
• Rivalidades internas e competitividade
• Dificuldades externas, como clima, instabilidade política, pós-desastre,
legislação.
Claramente, algumas destas circunstâncias coincidem com a continuidade
planejamento, E muitas das abordagens constantes do Design de Serviços
publicação será relevante para o sucesso transição em circunstâncias difíceis.
Se as dificuldades são antecipados, então as medidas que atenuem serão
identificados e fazem parte da pacote de serviços, Planejando a rota através de
transição dentro da transição modeloFatores, como seria qualquer previstas
susceptíveis de influenciar transição.
É perfeitamente possível, no entanto, que as dificuldades serão inesperada,
talvez devido à mudança das condições, e irá requerer 'na mosca' adaptação.
Esta seção apresenta algumas das circunstâncias constrangedoras que podem
exigir a modificação, adaptação ou compromisso, e elementos da abordagem
que ajudariam sucesso. Um elemento chave comum para a maioria (se não
todas) dessas situações é ter uma compreensão clara do que constitui sucesso.
Quando as circunstâncias são difíceis prioridades são freqüentemente focadas
em aspectos específicos da serviço,cliente etc base - depois de entregar as
prioridades aceitos nas circunstâncias restritas, muitas vezes, requerem
compromissos em outras áreas.
9.4.1 Quando a velocidade é mais importante do que a precisão
ou suavidade
Em situações críticas, o tempo de implementação de um novo ou alterado
serviço pode ser mais importante do que um certo grau de ruptura. Esta é uma
forma eficaz gestão de risco decisão, e geral risco princípios de gestão
aplicáveis. Alguns dos principais fatores que auxiliam com a entrega de sucesso
neste contexto são:

• Empowerment - com pessoal, dada a autoridade para tomar níveis
adequados de risco. Em setores voláteis Transição de Serviço deve agir
de uma forma que reflete a cultura de risco corporativo e não suprimir ou
comprometer as decisões de risco do negócio.
• A necessidade de saber o corte absoluto fora de data / hora que
Transição de Serviço deve entregar por - muitas vezes "margens de
segurança" Ou são construídos em significando um produto é entregue no
início que poderia ter sido melhorado, ou as pessoas presumem que há
alguma margem de manobra e lá isn 't - o que significa prazos críticos são
perdidas. Muitas vezes, é melhor ser totalmente aberta e confiar em
equipe principal.
• Decidir qual componentes do serviço de transição deve estar disponível
na data de corte, e que podem ser adicionados mais tarde.
• Como separáveis são os componentes e quais são as dependências?
Que elementos podem ser necessárias, embora não inicialmente na lista
dos 'fundamentos'?
• Que usuários / clientes / etc locais devem estar no local na data de corte?
• O que realmente acontece se você falhar? Mais uma vez, a honestidade é
sempre a melhor política aqui. Considere:
• Negócio impacto
• Dinheiro
• Vidas
• Embaraço político
• Reputação.
Entendimento gestão de crises pode ser muito útil no enfrentamento e
principalmente a compreensão de que as regras para a gestão de crises são
diferentes daqueles para o gerenciamento de todos os dias. Basta estar
consciente das duas primeiras leis da gestão de crises (após Larry Niven) pode
ajudar a tranquilizar as pessoas de que a situação é sobreviver:
Regra 1: Não entre em pânico.
Regra 2: Um gerente de boa crise toma decisões instantaneamente e age sobre
eles. Se eles mais tarde acabam por ter sido correta, tanto melhor, mas a
velocidade é muitas vezes mais importante do que eficiência em uma situação
de crise.
O sucesso nessas circunstâncias depende:
• Capacitação e apoio posterior, e uma crença em que o apoio. A equipe
deve estar ciente dos seus níveis de capacitação e realmente acredito
que a organização irá apoiar suas escolhas - não estar com medo de uma
abordagem "corte marcial".

• Canais de autorização e os canais abertos e rápida. Não deve ser
acordado ações se os canais não funcionam - por exemplo, autoridade
delegada aumento, escalada, Canais de suporte alternativos.
• Seguindo o procedimentos, perceber que há risco, E não culpar depois -
se não a necessária flexibilidade e rapidez de resposta é limitada.
9.4.2 recursos restritos
Quando recursos estão em falta, um aspecto chave aqui é decidir o que medir e
aderindo a essa decisão eo quadro para a prestação, por exemplo:
• Qual é o parâmetro importante - velocidade ou baixa custar ou o que
quer? E sabendo que será a medida de importância depois, por exemplo
nenhuma culpa por ele ser caro quando o entendimento era "entrar no por
três horas a qualquer custo '.
• Estabelecimento de uma hierarquia de medidas aplicáveis - velocidade - o
dinheiro - etc funcionalidade completa com os subordinados que têm
alguns limites absolutos, por exemplo, o mais rapidamente possível, mas
não mais do que £ 12.500, ou o mais barato possível, mas deve ser em
até 30 de Setembro. Isto requer que envolve orçamento titulares,
tomadores de decisões comerciais etc para garantir os parâmetros
corretos são construídos dentro
• Conscientização e documentação. Todo o pessoal realmente e
potencialmente conscientes precisam estar cientes de exigências, e um
mecanismo para manter os funcionários informados rapidamente sobre
alterações a esses requisitos é essencial.
9.4.3 serviços de segurança críticas e ambientes de alto risco
Sempre cada vez mais, De serviços de TIs apoiar diretamente ou realmente
prestar serviços em que vidas dependem, como serviços hospitalares, serviços
de chamadas de emergência levando inundação, controlar e aeronaves "fly-by-
wire". Extra segurança e abordagens infalíveis são necessários, com recursos
como:
• Documentação adequada, o que é essencial e muitas vezes inclui os
contra-cheques de assinaturas e extras sobre a aprovação fase, no
entanto, a documentação excessiva pode ser contra-produtivo; alta risco
muitas vezes pode ser encontrada em conjunto com tempo restrito (por
exemplo, situações de emergência coordenação de serviços), que
significa cuidadoso equilíbrio de segurança e velocidade é necessária, em
circunstâncias habilidade e experiência e / ou treinamento extensivo é um
fator importante
• Precisão tipicamente tendo prioridade sobre a velocidade
• Mais testes rigorosos, longos períodos de tempo e dados mais detalhados
coletadas e mantidas dentro do CMS

• Medidas de segurança com precisão avaliados por uma autoridade
aceita, por exemplo, o que constitui a níveis aceitáveis, tais como as
doses de radiação de segurança dentro de raios-X ou radioactivos
ambientes
• Definindo a autoridade sign-off, e assegurar que os responsáveis não são
excessivamente influenciados por pressões indevidas, como a
preocupação com os bônus de empresas de lucro ou pessoal ao invés de
arriscar vidas humanas
• Em circunstâncias extremas garantindo mais do que um indivíduo deve
ser envolvido para determinadas ações a serem tomadas (por exemplo,
normalmente o procedimentos para o lançamento de armas nucleares
requerem confirmação simultânea de dois oficiais treinados)
• Considere 'veto' direitos para sub-grupos em que aqueles que controlam
qualquer tecla componente do serviço pode parar a execução - como um
"no-go" de um de uma dúzia de equipes pode parar um lançamento de
um ônibus espacial.
9.4.4 Trabalhando com clientes difíceis
É claro que não há tal coisa como um cliente ruim, realmente, mas muitas vezes
há clientes que não estejam claras de sua papel como cliente e assim agir de
uma forma que impede que, em vez de suportar uma implementação bem
sucedida. Exemplos incluem clientes que:
• Sentimos a necessidade de envolver demais no detalhe de como as
coisas são feitas, em vez de julgar pelo serviço prestado
• Não são capazes de entregar as decisões e escolher as opções para
atender às suas necessidades de negócio
• Não faça pessoal e recursos disponíveis para facilitar a transição de
serviço efectivo, por exemplo, fornecer dados e do pessoal de serviço
para avaliar a transição, ou para efectuar usuário teste.
Esses tipos de situação muitas vezes pode ser melhorada através de
conscientização e educação:
• Clientes
• Usuários
• Equipe de transição (por exemplo, a paciência e as habilidades de
diplomacia)
• Gerenciamento de contas a trabalhar com os clientes para tranquilizar os
clientes e verificar a sua exigências
• Cuidado orçamental controlar, De modo que os clientes possam ver o
valor de retorno para o seu investimento de tempo pessoal e outros
recursos.

Posfácio
Esta publicação faz parte da ITIL série que apresenta boa prática e bons
conselhos para as organizações que reconhecem a importância de Serviço de
Gestão de para o seu sucesso global.
Esta publicação, como os outros, oferece dicas gerais de som, mas isso - por si
só - não é suficiente. Esse conselho deve ser compreendida dentro do contexto
que organização se encontra.
Gerente de TI serviços deve gerenciar serviços dentro das circunstâncias em
que se encontram - por algum segurança será a preocupação eminente, outros
vão considerar a velocidade, rentabilidade ou usabilidade ou algum outro fator
como seu principal motorista. Cumprindo eficaz Transição de Serviço é um
desafio para todos, entregando Transição de Serviço eficaz em qualquer
organização específica requer a compreensão do princípio da Transição de
Serviço, e entender o negócio apoiado e os serviços que estão sendo
introduzidos, alterados ou aposentard.
Esta publicação foi escrita para fornecer uma base para os profissionais de
ITSM para implementar serviços sólida e eficaz para apoiar seus clientes em
seus negócios, e para continuar a fazer o que a longo prazo.

Apêndice A: Descrição dos tipos de ativos
Gestão
Gestão é um sistema que inclui liderança, administração, políticas, atuação
medidas e incentivos. Esta camada cultiva, coordena e controla todas as outras
ativos tipos. Gestão inclui elementos idiossincráticos, como a filosofia, as
crenças centrais, valores, estilo de tomada de decisão e as percepções de risco.
É também o tipo mais característico e inimitável de ativos profundamente
enraizado na organização. [O termo organização é usado aqui para se referir à
empresa ou empresa e não o organização tipo de ativo. A maneira mais
provável em que os activos de gestão podem ser parcialmente extraído de uma
organização é pela caça ilegal de indivíduos-chave que foram fundamentais na
definição e desenvolvimento de um determinado gestão da informação.] Serviço
de Gestão de em si é um tipo de gestão de activos especializados, como outros,
tais como projeto pesquisa, gestão e desenvolvimentoE gestão de produção
Organização
Ativos da organização são configurações de ativos de pessoas, processos,
aplicaçãos e infra-estrutura que realizar todos organizacional atividade através
dos princípios da especialização e coordenação. Este categoria de ativos inclui
as hierarquias funcionais, redes sociais de grupos, equipes e indivíduos, e os
sistemas que utilizam para trabalhar em alinhamento com metas comuns e
incentivos. Organização ativos incluem os padrões em que as pessoas,
aplicações, informações e infra-estrutura de implantar ou por projeto ou por auto-
adaptativo processo maximizar a criação de valor para as partes interessadas.
Alguns serviço organizações são superiores a outras, simplesmente em virtude
de organização. Por exemplo, redes de pontos de acesso sem fio,
armazenamento sistemas, ponto-de-venda de terminais, bases de dados, lojas
de ferragens e remotas apoio instalações. A localização estratégica de ativos por
si só é uma base para um desempenho superior e vantagem competitiva
Processo
Processo activos são feitos de algoritmos, métodos procedimentos, e rotinas que
orientam a execução e controlar de atividades e interações. Há uma grande
diversidade de ativos de processo, que são especializados em diferentes graus
de processos de gestão muito genéricos a sofisticados algoritmos de baixo nível
embutidos em aplicações de software e outras formas de automação. Ativos de
processos são os mais dinâmica de tipos. Elas significam ação e transformação.
Alguns deles são também os meios pelos quais ativos da organização e gestão
de coordenar e controlar uns aos outros e interagir com o ambiente de negócios.
Pessoas, processos e ativos de aplicação executá-los; ativos de conhecimento e
informações enriquecê-los, aplicações e ativos de infra-estrutura habilitá-los.

Exemplos de ativos de processo são a ordem cumprimento, Contas a receber,
gerenciamento de incidentes,Gestão da Mudança e teste
Conhecimento
Ativos de conhecimento são acumulações de consciência, experiências,
informações, visão e propriedade intelectual que estão associados com as ações
e contexto. Gestão, organização, processos e aplicações de recursos e ativos de
conhecimento de uso de loja. Os bens das pessoas armazenar o conhecimento
tácito na forma de experiência, habilidades e talentos. Esse conhecimento é
adquirido principalmente através da observação, experiência e formação.
Movimento de equipes e indivíduos é uma maneira eficaz de transferir
conhecimento tácito dentro e entre organizações (Argote, 2000). Ativos de
conhecimento em forma tácita são difíceis para os rivais para reproduzir, mas
fácil para os proprietários de perder. Organizações procuram se proteger da
perda de codificação do conhecimento tácito em formas explícitas, como o
conhecimento incorporado em processos, aplicações e ativos de infra-estrutura.
Ativos de conhecimento são difíceis de gerir, mas pode ser altamente
alavancadas com retornos crescentes e praticamente zero custo de
oportunidades (Baruch Lev., 2001). Ativos de conhecimento incluem políticas,
planos, projetos, configurações, arquiteturas, definições de processos, métodos
analíticos, serviço de definições, análises, relatórios e pesquisas. Eles podem
ser de propriedade como propriedade intelectual e protegidos por direitos
autorais, patentes e marcas registradas. Ativos de conhecimento também pode
ser alugado para uso em regime de licenciamento e de serviços contratos
Pessoas
O valor dos bens das pessoas é a capacidade para a criatividade, análise,
percepção, aprendizagem, julgamento, liderança, comunicação, coordenação,
empatia e confiança. Esta capacidade é em equipes e indivíduos dentro da
organização, Devido ao conhecimento, experiência e habilidades. Habilidades
podem ser habilidades conceituais, técnicas e sociais. Os bens das pessoas
também são os absorvedores mais convenientes e portadores de todas as
formas de conhecimento. Eles são o mais versátil e potente de todos os tipos de
ativos por causa de sua capacidade de aprender e se adaptar. Os bens das
pessoas representam capacidades de uma organização e recursos. Se os
recursos são a capacidade de ação, os bens das pessoas são os atores. A partir
da perspectiva das capacidades, os bens das pessoas são o único tipo que pode
criar, combinar e consumir todos os outros tipos de ativos. Sua tolerância de
ambiguidade e incerteza também compensa as limitações dos processos,
aplicações e infra-estrutura. Por causa do seu enorme potencial, os bens das
pessoas são muitas vezes os mais caros em termos de desenvolvimento,
Manutenção e motivação. Eles também são ativos que podem ser contratados
ou alugados, mas não pode ser detida. Os clientes valorizam serviços que
melhoram a produtividade ou potencial de bens das pessoas.

Os bens das pessoas também são recursos com capacidade produtiva.
Unidades de custar, Tempo e esforço medir sua capacidade de equipes e
indivíduos. Eles são móveis, multi-propósito e altamente adaptável, com a
capacidade inata de aprender. Contratos de pessoal, agentes de software e
clientes, usando de auto-atendimento opções de aumentar a capacidade de os
bens das pessoas
Informações
Informações ativoss são coleções, padrões e abstrações significativas de dados
aplicados em contextos como clientes, contratos, serviços, eventos, projetos e
operações. Eles são úteis para diversos fins, incluindo a comunicação, a
coordenação e controlar de negócio actividades. Ativos de informação existe em
várias formas, tais como documentos, registros, mensagens e gráficos. Todos os
tipos de ativos produzi-los, mas de gestão, processos, conhecimentos, pessoas
e aplicações consomem principalmente eles. O valor dos ativos de informação
podem variar de acordo com local, data e formato, e depreciam muito
rapidamente. Alguns serviços de criação de valor através do processamento de
informações e disponibilizá-lo conforme a necessidade de gestão, processos,
pessoas e bens aplicações. Os critérios de
eficácia,eficiência,disponibilidade,integridade,confidencialidade,confiança e
observância pode ser usado para avaliar a qualidade dos ativos de informação
Aplicações
Aplicaçãos ativos são diferentes em tipo e vários artefactos, automação e
ferramentas utilizadas para apoiar o atuação de outros tipos de ativos.
Aplicações são compostas por software, hardware, documentos, métodos,
procedimentos, rotinas, scripts e instruções. Eles automatizar, codificar, permitir,
melhorar, manter ou imitar as propriedades, funçãos, e as atividades de gestão,
organização, processos, conhecimentos, pessoas e ativos de informação.
Aplicações derivam seu valor em relação a esses outros ativos. Processo ativos,
em particular, comumente existe dentro de aplicações. Ativos aplicações
consumir, produzir e manter os ativos de conhecimento e informação. Eles
podem ser de vários tipos, como de uso geral, multi-propósito e para fins
especiais. Alguns aplicativos são análogas às ferramentas industriais, máquinas
e equipamentos, porque melhoram o desempenho dos processos. Outros são
análogos aos equipamentos de escritório e aparelhos de consumo, porque
melhoram a produtividade pessoal dos bens das pessoas. Exemplos de
aplicações são contabilidade software, correio de voz de imagem, sistemas,
dispositivos de cifragem, controle de processo, Controle de estoque, eletrônico
projeto automação, telefones móveis e leitores de código de barras. As
aplicações são próprios suportada por infra-estrutura, pessoas e ativos de
processo. Um dos mais poderosos atributo de aplicações é que eles podem ser
combinados de forma criativa e integrada com outros tipos de ativos,
particularmente outras aplicações para criar novos ativos valiosos.

Infra-estrutura
A infra-estruturas têm a propriedade peculiar de existir sob a forma de camadas
definidas em relação aos activos que eles suportam, especialmente pessoas e
aplicações. Incluem tecnologia da informação ativos, tais como aplicações de
software, computadores, sistemas de armazenamento, dispositivos de rede,
equipamentos de telecomunicações, cabos, ligações sem fios, de acesso
controlar dispositivos e monitoramento sistemas. Este categoria de ativos
também inclui instalações tradicionais, tais como edifícios, eletricidade, calor,
ventilação, ar condicionado (HVAC) e abastecimento de água, sem a qual seria
impossível para as pessoas, aplicações e ativos de infra-estrutura para operar.
Ativos de infra-estrutura por si só pode ser composto principalmente de
aplicações e ativos de infra-estrutura. Activos vistos como aplicações em um
nível pode ser utilizada como infra-estrutura de uma outra. Este é um princípio
importante, que permite orientação a serviços de ativos
O capital financeiro
Os ativos financeiros são necessários para apoiar a propriedade ou utilização de
todos os tipos de ativos. Eles também medem o valor econômico e atuação de
todos os tipos de ativos. Os ativos financeiros incluem caixa, equivalentes de
caixa e outros ativos, como títulos e valores mobiliários e os recebíveis que
conversíveis em dinheiro com graus de certeza e facilidade. Adequação dos
recursos financeiros ativoss é uma preocupação importante para todas as
organizações, agências governamentais e organizações sem fins lucrativos. A
promessa eo potencial de outros activos não é realizado na íntegra, sem ativos
financeiros

Outras informações
Referências
Argote, Linda Transferência de Conhecimento (2000): A base para a vantagem competitiva nas
empresas. Comportamento Organizacional e Processos de Decisão Humanos. Vol. 82, No. 1,
Mai, pp 150-169.
Baruch Lev. (2001) Intangíveis: Gestão, medição e relatórios. A Instituição Brookings.
BS 7799-3:2006, Segurança da Informação Sistemas de Gestão - Diretrizes para Informação de
Gestão de Riscos de Segurança.
BSI (2003) Gestão da Cultura e do Conhecimento - Um Guia de Boas Práticas, o Comitê KMS /
1, Rob Young (presidente), PD 7501, British Standards Institution, em Londres.
BSI Guia (2003) para medições em Gestão do Conhecimento, Comitê KMS / 1, Rob Young
(presidente), PD 7502, British Standards Institution, Londres.
BSI Gestão do Conhecimento (2001). Um Guia de Boas Práticas, British Standards Institution,
Londres.
COBIT ® (2005) COBIT Framework, Objetivos de Controle para Informações e Tecnologia
Relacionada, Auditoria de Sistemas de Informação e Control Association (ISACA) e do IT
Governance Institute (ITGI), Rolling Meadows, Illinois, EUA.
CMMI (2006) Capability Maturity Model ® versão Integração (CMMI) 1.2, agosto, Software
Engineering Institute (SEI), Carnegie Mellon Universidade,Pittsburgh.
Drake, P. Ação (2005a) Comunicativa em Sistemas de Segurança da Informação: Uma
Aplicação da Teoria Social em um domínio técnico, Casco Negócio Escola,Universidade de
Casco,Casco.
Drake, P. (2005b) Socialização do domínio da segurança da informação, ou introspecção, vol.
18, No. 3, pp 15-23, Sociedade de Pesquisa Operacional, da Universidade de Hull, Hull.
Pato, JD mudança de gestão (2000): a arte de equilíbrio, Harvard Business Review, novembro-
dezembro.
Dugmore, J. e Lacy, S. (2006), Alcançar a norma ISO / IEC 20000, British Standards Institution,
Londres.
BIP 0005 Guia de um gerente para o Serviço de Gestão
BIP 0030 decisões de gestão e de documentação
BIP 0031 Por que as pessoas Matéria
BIP 0032 Métricas de tornar o trabalho
BIP Fim de Gestão 0033 a fim de serviço
BIP 0034 Finanças para Gestores de Serviço
Mudança BIP 0035 Ativação
BIP 0036 Mantendo o Serviço Indo
BIP Gerenciamento da Capacidade 0037
BIP 0038 Integrando Gestão de Serviços

Hambling, B. (org.) Teste de Software (2007), uma fundação do ISEB, com P. Morgan, Samaroo
A., G. Thompson e Williams P., British Computer Society, Swindon.
Hackman, JR e Oldham, GR (1980) Redesenho Trabalho (Organização para o
Desenvolvimento), Addison-Wesley, Leitura,Missa,EUA.
IEEE 829-1998, Padrão para Documentação de Software.
Instituto de Auditores Internos (2005) Guia de Auditoria Global Technology 2: Mudança e
controles de gerenciamento de patch: Crítica para o sucesso organizacional, Instituto de
Auditores Internos, Altamonte Springs, Flórida, EUA.
ISO 9001:2000, Sistemas de Gestão da Qualidade - Requisitos.
ISO 10007:2003, Sistemas de Gestão da Qualidade - Diretrizes para Gerenciamento de
Configuração.
ISO 14001:2004, Gestão Ambiental.
ISO 15489-1:2001, Informação e Documentação - Gerenciamento de registros - Geral.
ISO / IEC 12207:1995, Tecnologia da Informação - Processos do Ciclo de Vida de Software.
ISO / IEC 15288:2002, Engenharia de Sistemas - Processos do Ciclo de Vida do Sistema.
ISO / IEC 19770-1:2006, Gestão de Ativos de Software - Processos.
ISO / IEC 20000-1:2005, Tecnologia da Informação - Serviço de Gestão Parte 1: Especificação.
ISO / IEC 20000-2:2005, Tecnologia da Informação - Serviço de Gestão Parte 2: Código de
Prática.
ISO / IEC 27001:2005, Tecnologia da Informação - Técnicas de segurança - Sistemas de
Informação de Gestão de Segurança - Requisitos.
ISO / IEC 17799:2005, Tecnologia da Informação - Técnicas de segurança - Código de prática
para a gestão da segurança da informação.
Kanter, R. M. (2001) Evolve! Sucedendo na Cultura Digital do Amanhã, Harvard Negócio Escola
Pressione, Boston,MA.
Kotter, J. P. (1996) Mudança principal, Harvard Negócio Escola Pressione, Boston,MA.
Kotter, JP e Schlesinger, LA (1979) A escolha de estratégias de mudança, Harvard Business
Review, vol. 57, No. 2, p. 106.
Kotter, JP (1999) a mudança acontecer, em F. Hesselbein e Cohen P., Leader to Leader,
Drucker Foundation, de Nova York.
Kotter, JP mudança (2000) Líder: por que os esforços de transformação falhar, Harvard Business
Review, janeiro-fevereiro.

McKinsey modelo 7S: Peters, T., Waterman, R. (1982) Em Busca da Excelência, Harper & Row,
Nova Iorque e Londres.
Magretta, J. (2002) o que é gestão: Como funciona e porque é de todos. The Free Press, Nova
Iorque.
OGC (2003) Managing Successful Programmes, Office of Government Commerce, TSO (The
Stationery Office), Norwich.
OGC Gestão (2007) de Risco: Orientação para Profissionais, o Office of Government Commerce,
TSO Norwich.
OGC (2005) Gerenciando Projetos de Sucesso com PRINCE2, Office of Government Commerce,
TSO Norwich.
PMBOK ® (2006) Project Management Body of Knowledge, 3 ed, Project Management Institute,
Pensilvânia.
Szulanski, G. (1992) Conhecimento Fixo: Barreiras à Sabendo na empresa, Sage Publications,
Londres.
Szulanski, G. (1996) Explorando aderência interna: os obstáculos à transferência das melhores
práticas dentro da empresa, Strategic Management Journal, 17 (edição especial de verão), pp
27-43.
Sirkin, HL, Keenan, P. e Jackson, A. (2005) O lado duro de Change Management, Harvard
Business Review, Outubro.
Vogel (2005) o cumprimento eficaz regulamentação exige Gerenciamento de Configuração, o
Gartner Inc. Investigação ID: G00127752, o Gartner Inc., Stamford,Connecticut.
Whitmore Coaching (1992) para o desempenho, Nicholas Brealey Publishing, Londres.

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
acordado
(Desenho de Serviço) Um sinônimo de horas de serviço, comumente
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
de
(Desenho de Serviço) (Operação de Serviço) A Função responsável
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
Provider
(Desenho de Serviço) Um provedor de serviço externo que fornece
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
Dimensionamento
(Desenho de Serviço) A Atividade responsável por entender as
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
Automática de
Chamadas
(Operação de Serviço) O uso da Tecnologia da Informação para
direcionar uma chamada telefónica para a pessoa mais adequada no
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
Disponibilidade
(Desenho de Serviço) O Processo responsável pela definição, análise,
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
Sistema de
Informação de Gestão
(Desenho de Serviço) Um repositório virtual de todos os dados de
gerenciamento de disponibilidade, normalmente armazenados em
vários locais físicos. Veja também Serviço de Sistema de Gestão do
Conhecimento.
Plano de
disponibilidade
(Desenho de Serviço) Um plano para garantir que os requisitos de
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
Capacidade de
negócios
(Desenho de Serviço) No contexto do ITSM, Negócios Gerenciamento
da Capacidade é a Atividade responsável por entender Requisitos de
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
Continuidade de
Negócios
(Desenho de Serviço) O processo de negócio responsável pela gestão
de riscos que podem afectar gravemente o negócio. BCM
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
Continuidade de
Negócios
(Desenho de Serviço) Um Plano que define os passos necessários
para restaurar os processos de negócios após uma interrupção. O
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
no Negócio
(Estratégia de Serviço) BIA é a atividade em Gestão de Continuidade
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
comerciais
(Estratégia de Serviço) O dia-a-dia de execução, monitoramento e
gerenciamento de processos de negócios.
Perspectiva de
Negócios
(Melhoria de Serviço Continuada) Uma compreensão do prestador de
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
Relacionamento com
Empresas
(Estratégia de Serviço) O Processo ou Função responsável por manter
um relacionamento com a empresa. Gestão de Relacionamento de
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
Management
(Estratégia de Serviço) (Desenho de Serviço) Uma abordagem para o
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
Capacidade
(Desenho de Serviço) O Processo responsável por garantir que a
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
Sistema de
Informação de Gestão
(Desenho de Serviço) Um repositório virtual de todos os dados de
gerenciamento de capacidade, normalmente armazenados em vários
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
Capacidade
(Desenho de Serviço) a atividade dentro de Gerenciamento da
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
Consultivo
(Transição de Serviço) Um grupo de pessoas que aconselha o Gerente
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
Mudança
Veja Requisição de 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-
shelf
(Desenho de Serviço) O software aplicativo ou Middleware que pode
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
Capacidade
componente
(Desenho de Serviço) (Melhoria de Serviço Continuada) O processo
responsável por entender a capacidade de utilização e desempenho
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
de Impacto falha
(Desenho de Serviço) Uma técnica que ajuda a identificar o impacto da
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
Configuração
(Transição de Serviço) A Atividade responsável por coletar
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
Configuração
(Transição de Serviço) O Processo responsável por manter
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
Gerenciamento da
Configuração
(Transição de Serviço) Um conjunto de ferramentas e bases de dados
que são usados para gerenciar dados de um provedor de serviços de
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
Continuada
(Melhoria de Serviço Continuada) Uma fase no Ciclo de Vida de um
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
contínua
(Desenho de Serviço) Uma abordagem ou desenho para atingir 100%
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
perspectiva
(Estratégia de Serviço) Uma abordagem para a gestão de serviços de
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-
Benefício
Uma atividade que analisa e compara os custos e os benefícios
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
Sucesso
Algo que deve acontecer se um processo, projeto, plano ou Serviço de
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
instrumentos
(Operação de Serviço) Uma representação gráfica do desempenho
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
Demanda
Atividades que compreendem e influenciar a demanda de clientes por
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
Desenvolvimento
(Desenho de Serviço) Um Ambiente utilizada para criar ou modificar
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
carregamento
Uma técnica usada para apoiar Gestão de Demanda cobrando valores
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
Capacidade para
prestadores de
serviços
(Estratégia de Serviço) Uma estrutura para ajudar os provedores de
serviços desenvolvem as suas capacidades de gestão de serviços de
TI a partir de uma perspectiva de serviço de sourcing. eSCM-SP foi
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
Incidente Expandido
(Gerenciamento de Disponibilidade) etapas detalhadas no ciclo de vida
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
externo
(Estratégia de Serviço) Um provedor de serviço de TI que faz parte de
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
Falhas
(Desenho de Serviço) (Melhoria de Serviço Continuada) Uma técnica
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
imediata
(Desenho de Serviço) Uma opção de recuperação que também é
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
Incidentes
(Operação de Serviço) O Processo responsável por gerenciar o ciclo
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
da Informação
(Desenho de Serviço) O Processo que garante a confidencialidade,
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
Segurança
(Desenho de Serviço) O quadro de políticas, processos, normas,
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
da Informação
(Desenho de Serviço) A política que governa abordagem da
Organização de Gestão de Segurança da Informação.
Tecnologia da
Informação
O uso da tecnologia para o armazenamento, comunicação ou
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-
estrutura
Um serviço de TI que não é usado diretamente pela empresa, mas é
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
Intermediário
(Desenho de Serviço) Uma opção de recuperação que também é
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
interno
(Estratégia de Serviço) Um provedor de serviço de TI que faz parte da
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
Internacional para
Padronização
A Organização Internacional de Normalização (ISO) é a maior
desenvolvedora mundial de Normas. ISO é uma organização nã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
Continuidade do
Serviço
(Desenho de Serviço) O Processo responsável por gerenciar os riscos
que poderiam afetar seriamente Serviços de TI. ITSCM garante que 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
Continuidade do
Serviço
(Desenho de Serviço) Um Plano que define os passos necessários
para recuperar um ou mais serviços de TI. O Plano também vai
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
Management
A implementação e gestão da Qualidade de Serviços de TI que
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
de TI
(Estratégia de Serviço) Um prestador de serviços que fornece serviços
de TI para clientes internos ou clientes externos.
Grupo de
Coordenação de TI
Um grupo formal, que é responsável por garantir que as empresas e
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
Indicator
(Desenho de Serviço) (Melhoria de Serviço Continuada) Uma métrica
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
Conhecimento
(Transição de Serviço) Um banco de dados lógico que contém os
dados utilizados pelo Sistema de Gerenciamento de Serviços de
Conhecimento.
Gestão do
Conhecimento
(Transição de Serviço) O Processo responsável pela coleta, análise,
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
falhas
(Desenho de Serviço) Uma Métrica para medir e relatar Confiabilidade.
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
Incidentes de Serviço
(Desenho de Serviço) A métrica usada para medir e informar
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
restaurar o serviço
O tempo médio para restaurar um Item de Configuração ou Serviço de
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
Commerce
OGC é dona da marca ITIL (direitos autorais e marca registrada). OGC
é 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
Operacional
(Desenho de Serviço) (Melhoria de Serviço Continuada) um acordo
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
passivo
(Operação de Serviço) O monitoramento de um item de configuração,
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
de Negócios
(Estratégia de Serviço) Um perfil de carga de trabalho de uma ou mais
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
Desempenho
(Melhoria de Serviço Continuada) O Processo responsável pelo dia-a-
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
planejado
(Desenho de Serviço) Acordado momento em que um serviço de TI
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
comentário
Uma revisão que ocorre depois de uma mudança ou um projeto foi
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
sucesso
Uma atividade que precisa ser concluída, ou uma condição que
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
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
Processo
Um papel responsável por garantir que um processo está apto para o
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
Qualidade
(Melhoria de Serviço Continuada) O conjunto de processos
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
reciprocidade
(Desenho de Serviço) uma opção de recuperação. Um acordo entre
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
recuperação
(Desenho de Serviço) Uma estratégia para responder a uma
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
Relacionamento
A ISO / IEC 20000 Processo de grupo que inclui Gestão de Negócios e
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
Liberação e
Implantação
(Transição de Serviço) O Processo responsável tanto Gerenciamento
de Liberação e Implantação.
Gerenciamento de
Liberação
(Transição de Serviço) O Processo responsável por planejar,
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
Lançamento
(Transição de Serviço) A Record no CMDB que define o conteúdo de
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
Mudança
(Transição de Serviço) Uma proposta formal de alteração a ser feita.
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
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
resposta
A medição do tempo necessário para responder a qualquer coisa. Este
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
Serviço
Veja Restaurar.
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
Investimento
(Estratégia de Serviço) (Melhoria de Serviço Continuada) Uma medida
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
funcionamento
Veja Custo Operacional.
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
preocupações
(Estratégia de Serviço) Uma abordagem para a criação de uma
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
de serviços
(Transição de Serviço) Um conjunto de critérios utilizados para garantir
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
Capacidade de
serviço
(Desenho de Serviço) (Melhoria de Serviço Continuada) A Atividade
responsável por entender o desempenho ea capacidade de serviços
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
Continuidade do
Serviço
Veja TI Gestão da 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
de Serviço
(Desenho de Serviço) documento (s) a definição de todos os aspectos
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
serviço
(Desenho de Serviço) Uma Atividade que identifica as causas
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
Serviço
(Melhoria de Serviço Continuada) um plano formal para implementar
melhorias a um processo ou serviço de TI.
Serviço do Sistema
de Gestão do
Conhecimento
(Transição de Serviço) Um conjunto de ferramentas e bases de dados
que são usados para gerenciar conhecimento e informação. Os SKMS
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
Serviço
(Desenho de Serviço) (Melhoria de Serviço Continuada) um acordo
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
Nível de Serviço
(Desenho de Serviço) (Melhoria de Serviço Continuada) O Processo
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
Serviço
(Estratégia de Serviço) Um nível definido de Utilidade e Garantia para
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
Serviço
(Desenho de Serviço) (Melhoria de Serviço Continuada) uma exigência
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
serviço
(Desenho de Serviço) (Melhoria de Serviço Continuada) Um
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
ciclo de vida
Uma abordagem para IT Service Management, que enfatiza a
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
serviço
(Melhoria de Serviço Continuada) um papel que é responsável pela
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
de Serviços
(Estratégia de Serviço) O Processo responsável por gerenciar o
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,
simulação
(Desenho de Serviço) (Melhoria de Serviço Continuada) Uma técnica
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
requisitos
(Desenho de Serviço) Um documento contendo todas as exigências
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
de Dados Contrato
(Desenho de Serviço) Um banco de dados de documentos ou
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
Fornecedores
(Desenho de Serviço) O Processo responsável por garantir que todos
os contratos com fornecedores de suportar as necessidades do
negócio, e que todos os fornecedores cumpram os seus compromissos
contratuais.
Cadeia de
suprimentos
(Estratégia de Serviço) As Atividades em uma Cadeia de Valor
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
apoio
(Operação de Serviço) O terceiro nível em uma hierarquia de grupos
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
Propriedade
(Estratégia de Serviço) Uma metodologia usada para ajudar a tomar
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
Vital
(Desenho de Serviço) uma função de um processo de negócio que é
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.

Itil v3 transição de serviço

Mais conteúdo relacionado

Mais procurados (20)

Destaque (20)

Semelhante a Itil v3 transição de serviço (20)

Itil v3 transição de serviço