• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Itil v3 transição de serviço
 

Itil v3 transição de serviço

on

  • 7,273 views

 

Statistics

Views

Total Views
7,273
Views on SlideShare
7,273
Embed Views
0

Actions

Likes
4
Downloads
307
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

Itil v3 transição de serviço Itil v3 transição de serviço Document Transcript

  • 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. ITIL V3 - Transição de Serviço - Página: 2 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 3 de 424
  • 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.3 Valor para os negócios...........................................................................................67 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 4.2.3 Valor para os negócios...........................................................................................83 ITIL V3 - Transição de Serviço - Página: 4 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 5 de 424
  • 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 Triggers interfaces de entrada e saída, e entre processos...................................155 4.3.6.1 Processo de relacionamentos ................................................................................... 155 4.3.7 Gestão da informação ..........................................................................................155 4.3.8 Principais indicadores de desempenho e métricas...............................................156 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.3 Valor para os negócios.........................................................................................160 4.4.4 Políticas, princípios e conceitos básicos...............................................................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 as atividades de processo, métodos e técnicas....................................................170 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 ITIL V3 - Transição de Serviço - Página: 6 de 424
  • 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.6 Triggers interfaces de entrada e saída, e entre processos...................................210 4.4.7 Gestão da informação ..........................................................................................212 4.4.8 Principais indicadores de desempenho e métricas...............................................213 4.4.8.1 clientes ou negócios.................................................................................................. 213 4.4.8.2 Os prestadores de serviços....................................................................................... 213 4.4.9 Desafios, fatores críticos de sucesso e riscos ......................................................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.3 Valor para os negócios.........................................................................................217 4.5.4 Políticas, princípios e conceitos básicos...............................................................218 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 4.5.5 as atividades de processo, métodos e técnicas....................................................246 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 ITIL V3 - Transição de Serviço - Página: 7 de 424
  • 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 4.5.7 Gestão da informação ..........................................................................................251 Os dados de teste.....................................................................................................................................252 Ambientes de teste ...................................................................................................................................252 4.5.8 Principais indicadores de desempenho e métricas...............................................253 4.5.8.1 primário (de valor para o negócio / clientes) .............................................................. 253 4.5.8.2 secundário (interno) .................................................................................................. 254 4.5.9 Desafios, fatores críticos de sucesso e riscos ......................................................255 Avaliação 4,6............................................................................................................... 257 4.6.1 Finalidade, finalidade e objectivo..........................................................................257 4.6.2 Âmbito ..................................................................................................................257 4.6.3 Valor para os negócios.........................................................................................257 4.6.4 Políticas, princípios e conceitos básicos...............................................................258 Políticas.....................................................................................................................................................258 Princípios ..................................................................................................................................................258 Conceitos básicos..........................................................................................................258 4.6.5 as atividades de processo, métodos e técnicas....................................................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.8 Gestão da informação ..........................................................................................268 4.6.9 Principais indicadores de desempenho e métricas...............................................268 4.6.9.1 Desafios ................................................................................................................... 268 4,7 Gestão do Conhecimento..................................................................................... 270 4.7.1 Finalidade, finalidade e objectivo..........................................................................270 4.7.2 Âmbito ..................................................................................................................270 4.7.2.1 Inclusões .................................................................................................................. 271 4.7.2.2 Exclusões ................................................................................................................. 271 4.7.3 Valor para os negócios.........................................................................................271 4.7.4 Políticas, princípios e conceitos básicos...............................................................272 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 as atividades de processo, métodos e técnicas....................................................274 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 ITIL V3 - Transição de Serviço - Página: 8 de 424
  • 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 Principais indicadores de desempenho e métricas...............................................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 ITIL V3 - Transição de Serviço - Página: 9 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 10 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 11 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 12 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 13 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 14 de 424
  • Sharon Taylor Arquiteto Chefe, Práticas ITIL Service Management ITIL V3 - Transição de Serviço - Página: 15 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 16 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 17 de 424
  • 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: ITIL V3 - Transição de Serviço - Página: 18 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 19 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 20 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 21 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 22 de 424
  • 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). ITIL V3 - Transição de Serviço - Página: 23 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 24 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 25 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 26 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 27 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 28 de 424
  • 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) ITIL V3 - Transição de Serviço - Página: 29 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 30 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 31 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 32 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 33 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 34 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 35 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 36 de 424
  • 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: ITIL V3 - Transição de Serviço - Página: 37 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 38 de 424
  • 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: ITIL V3 - Transição de Serviço - Página: 39 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 40 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 41 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 42 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 43 de 424
  • 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). ITIL V3 - Transição de Serviço - Página: 44 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 45 de 424
  • • 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: • Gestão da Mudança • Ativo de Serviço e Gerenciamento de Configuração • Gestão do Conhecimento. 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 ITIL V3 - Transição de Serviço - Página: 46 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 47 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 48 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 49 de 424
  • É 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. ITIL V3 - Transição de Serviço - Página: 50 de 424
  • 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 Transição de Serviço Política: ITIL V3 - Transição de Serviço - Página: 51 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 52 de 424
  • 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 Gerenciamento da Configuração. • 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: ITIL V3 - Transição de Serviço - Página: 53 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 54 de 424
  • • 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. Melhores práticass: ITIL V3 - Transição de Serviço - Página: 55 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 56 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 57 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 58 de 424
  • • 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 Gerenciamento da Configuração. • 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. ITIL V3 - Transição de Serviço - Página: 59 de 424
  • • 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: ITIL V3 - Transição de Serviço - Página: 60 de 424
  • • 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. Melhores práticass: • 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. ITIL V3 - Transição de Serviço - Página: 61 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 62 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 63 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 64 de 424
  • 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 • Gestão da Mudança • Ativo de Serviço e Gerenciamento de Configuração • Gerenciamento de Liberação e Implantação • Serviço de validação e teste • Avaliação • Gestão do Conhecimento. 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. ITIL V3 - Transição de Serviço - Página: 65 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 66 de 424
  • • 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. 4.1.3 Valor para os negócios 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. ITIL V3 - Transição de Serviço - Página: 67 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 68 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 69 de 424
  • 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 Transição de Serviço 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. ITIL V3 - Transição de Serviço - Página: 70 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 71 de 424
  • 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: ITIL V3 - Transição de Serviço - Página: 72 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 73 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 74 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 75 de 424
  • 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? ITIL V3 - Transição de Serviço - Página: 76 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 77 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 78 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 79 de 424
  • • 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 Transição de Serviço • 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. ITIL V3 - Transição de Serviço - Página: 80 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 81 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 82 de 424
  • 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. 4.2.3 Valor para os 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: ITIL V3 - Transição de Serviço - Página: 83 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 84 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 85 de 424
  • 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 4.2.4 Políticas, princípios e conceitos básicos 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 ITIL V3 - Transição de Serviço - Página: 86 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 87 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 88 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 89 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 90 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 91 de 424
  • 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. 4.2.6 as atividades de processo, métodos e técnicas 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 ITIL V3 - Transição de Serviço - Página: 92 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 93 de 424
  • Figura 4.2 Exemplo de fluxo de processo para uma mudança normal ITIL V3 - Transição de Serviço - Página: 94 de 424
  • Figura 4.3 Exemplo de fluxo de processo para solicitação de implantação padrão ITIL V3 - Transição de Serviço - Página: 95 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 96 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 97 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 98 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 99 de 424
  • 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? ITIL V3 - Transição de Serviço - Página: 100 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 101 de 424
  • • 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 Categoria de risco: 4 Baixo impacto Alta probabilidade Categoria de risco: 3 Probabilidade Exemplo de tabela de 4,5 de um impacto de mudança e matriz de classificação dos riscos ITIL V3 - Transição de Serviço - Página: 102 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 103 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 104 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 105 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 106 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 107 de 424
  • 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- ITIL V3 - Transição de Serviço - Página: 108 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 109 de 424
  • 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: ITIL V3 - Transição de Serviço - Página: 110 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 111 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 112 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 113 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 114 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 115 de 424
  • 4.2.7 Triggers interfaces de entrada e saída, e entre processos 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 ITIL V3 - Transição de Serviço - Página: 116 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 117 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 118 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 119 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 120 de 424
  • 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. 4.2.8 Principais indicadores de desempenho e métricas 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 ITIL V3 - Transição de Serviço - Página: 121 de 424
  • • 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) ITIL V3 - Transição de Serviço - Página: 122 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 123 de 424
  • 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: ITIL V3 - Transição de Serviço - Página: 124 de 424
  • • 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. 4.3.3 Valor para os negócios 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. 4.3.4 Políticas, princípios e conceitos básicos Em ambientes distribuídos e serviços compartilhados, os componentes de serviços individuais existir dentro de diversos serviços e estrutura de ITIL V3 - Transição de Serviço - Página: 125 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 126 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 127 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 128 de 424
  • 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 serviços • 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). ITIL V3 - Transição de Serviço - Página: 129 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 130 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 131 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 132 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 133 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 134 de 424
  • 4.3.5 as atividades de processo, métodos e técnicas 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. ITIL V3 - Transição de Serviço - Página: 135 de 424
  • 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: • Papéis e responsabilidades • 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 ITIL V3 - Transição de Serviço - Página: 136 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 137 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 138 de 424
  • Figura 4.11 (a) Repartição Exemplo de configuração para um serviço de computação de usuário final ITIL V3 - Transição de Serviço - Página: 139 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 140 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 141 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 142 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 143 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 144 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 145 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 146 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 147 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 148 de 424
  • '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. ITIL V3 - Transição de Serviço - Página: 149 de 424
  • 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 • Gestão da Mudança • 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. ITIL V3 - Transição de Serviço - Página: 150 de 424
  • 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 '. ITIL V3 - Transição de Serviço - Página: 151 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 152 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 153 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 154 de 424
  • 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. 4.3.6 Triggers interfaces de entrada e saída, e entre processos 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. ITIL V3 - Transição de Serviço - Página: 155 de 424
  • 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. 4.3.8 Principais indicadores de desempenho e métricas 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%) ITIL V3 - Transição de Serviço - Página: 156 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 157 de 424
  • "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. ITIL V3 - Transição de Serviço - Página: 158 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 159 de 424
  • • 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. 4.4.3 Valor para os negócios 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 Políticas, princípios e conceitos básicos 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 ITIL V3 - Transição de Serviço - Página: 160 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 161 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 162 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 163 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 164 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 165 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 166 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 167 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 168 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 169 de 424
  • 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 as atividades de processo, métodos e técnicas 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 ITIL V3 - Transição de Serviço - Página: 170 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 171 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 172 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 173 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 174 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 175 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 176 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 177 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 178 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 179 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 180 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 181 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 182 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 183 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 184 de 424
  • • 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 • Gestão da Mudança • Ativo de Serviço e Gerenciamento de Configuração • 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: • Papéis e responsabilidades • 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 ITIL V3 - Transição de Serviço - Página: 185 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 186 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 187 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 188 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 189 de 424
  • 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, ITIL V3 - Transição de Serviço - Página: 190 de 424
  • é 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 ITIL V3 - Transição de Serviço - Página: 191 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 192 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 193 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 194 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 195 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 196 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 197 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 198 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 199 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 200 de 424
  • 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: ITIL V3 - Transição de Serviço - Página: 201 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 202 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 203 de 424
  • 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: ITIL V3 - Transição de Serviço - Página: 204 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 205 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 206 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 207 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 208 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 209 de 424
  • • 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. 4.4.6 Triggers interfaces de entrada e saída, e entre processos 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. ITIL V3 - Transição de Serviço - Página: 210 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 211 de 424
  • • 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. 4.4.7 Gestão da informação 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. ITIL V3 - Transição de Serviço - Página: 212 de 424
  • 4.4.8 Principais indicadores de desempenho e métricas 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. 4.4.9 Desafios, fatores críticos de sucesso e riscos 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. Fator crítico de sucessos incluem: • O serviço novo ou alterado capacidade e os recursos são construídas no alvo ambiente ou desenvolvimento grupo. ITIL V3 - Transição de Serviço - Página: 213 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 214 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 215 de 424
  • 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 Transição de Serviço. 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 ITIL V3 - Transição de Serviço - Página: 216 de 424
  • • 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. 4.5.3 Valor para os negócios 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 ITIL V3 - Transição de Serviço - Página: 217 de 424
  • 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 Políticas, princípios e conceitos básicos 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. ITIL V3 - Transição de Serviço - Página: 218 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 219 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 220 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 221 de 424
  • 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: ITIL V3 - Transição de Serviço - Página: 222 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 223 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 224 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 225 de 424
  • • Identificação de itens a serem testados: • Pacote de serviços • 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 ITIL V3 - Transição de Serviço - Página: 226 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 227 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 228 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 229 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 230 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 231 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 232 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 233 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 234 de 424
  • • 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? ITIL V3 - Transição de Serviço - Página: 235 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 236 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 237 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 238 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 239 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 240 de 424
  • 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? ITIL V3 - Transição de Serviço - Página: 241 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 242 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 243 de 424
  • 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: ITIL V3 - Transição de Serviço - Página: 244 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 245 de 424
  • 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. 4.5.5 as atividades de processo, métodos e técnicas 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. ITIL V3 - Transição de Serviço - Página: 246 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 247 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 248 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 249 de 424
  • • 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: ITIL V3 - Transição de Serviço - Página: 250 de 424
  • • 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 4.5.7 Gestão da informação 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 ITIL V3 - Transição de Serviço - Página: 251 de 424
  • 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: ITIL V3 - Transição de Serviço - Página: 252 de 424
  • • 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 Principais indicadores de desempenho e métricas 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 ITIL V3 - Transição de Serviço - Página: 253 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 254 de 424
  • 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. 4.5.9 Desafios, fatores críticos de sucesso e riscos 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. Fator crítico de sucessos incluem: • Entender o diferente das partes interessadas perspectivas que sustentam eficaz gestão de risco para a mudança impacto actividades de avaliação e teste • 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 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: ITIL V3 - Transição de Serviço - Página: 255 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 256 de 424
  • 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 4.6.1 Finalidade, finalidade e objectivo 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. 4.6.3 Valor para os negócios 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 ITIL V3 - Transição de Serviço - Página: 257 de 424
  • 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. 4.6.4 Políticas, princípios e conceitos básicos 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 as atividades de processo, métodos e técnicas 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 ITIL V3 - Transição de Serviço - Página: 258 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 259 de 424
  • Tabela 4,13 termos-chave que se aplicam ao processo de avaliação de serviços 4.6.5.2 Processo de avaliação ITIL V3 - Transição de Serviço - Página: 260 de 424
  • Figura 4.34 Processo de avaliação ITIL V3 - Transição de Serviço - Página: 261 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 262 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 263 de 424
  • 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 Gestão da Mudança. 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 Gestão da Mudança. 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. ITIL V3 - Transição de Serviço - Página: 264 de 424
  • É 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 ITIL V3 - Transição de Serviço - Página: 265 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 266 de 424
  • 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: ITIL V3 - Transição de Serviço - Página: 267 de 424
  • • Comente e fechar transição • Gestão do Conhecimento. 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: • Pacote de serviços • SDP e SAC • Os resultados do teste e relatório. Saídas: • Relatório de avaliação de Gestão de Mudança. 4.6.8 Gestão da informação • Portfólio de Serviços • Pacote de serviços • SDP, SAC • Os resultados do teste e relatório • Relatório de avaliação. 4.6.9 Principais indicadores de desempenho e métricas 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: ITIL V3 - Transição de Serviço - Página: 268 de 424
  • • 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 • Entender o diferente das partes interessadas perspectivas que sustentam 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 • A construção de uma compreensão completa dos riscos que impactaram ou podem impactar sucesso Transição de Serviço de serviços e lançamentos • Incentivar uma gestão de risco cultura onde as pessoas compartilham informações. ITIL V3 - Transição de Serviço - Página: 269 de 424
  • 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. 4.7.1 Finalidade, finalidade e objectivo 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, é ITIL V3 - Transição de Serviço - Página: 270 de 424
  • 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. 4.7.3 Valor para os negócios 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 ITIL V3 - Transição de Serviço - Página: 271 de 424
  • • 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 Políticas, princípios e conceitos básicos 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 ITIL V3 - Transição de Serviço - Página: 272 de 424
  • 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: ITIL V3 - Transição de Serviço - Página: 273 de 424
  • • 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 as atividades de processo, métodos e técnicas 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: ITIL V3 - Transição de Serviço - Página: 274 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 275 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 276 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 277 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 278 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 279 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 280 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 281 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 282 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 283 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 284 de 424
  • 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. 4.7.7 Principais indicadores de desempenho e métricas 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. ITIL V3 - Transição de Serviço - Página: 285 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 286 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 287 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 288 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 289 de 424
  • 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? ITIL V3 - Transição de Serviço - Página: 290 de 424
  • • 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 ITIL V3 - Transição de Serviço - Página: 291 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 292 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 293 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 294 de 424
  • Figura 5.3 Exemplo de etapas de transição para a terceirização de serviços ITIL V3 - Transição de Serviço - Página: 295 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 296 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 297 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 298 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 299 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 300 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 301 de 424
  • 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á ITIL V3 - Transição de Serviço - Página: 302 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 303 de 424
  • 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? ITIL V3 - Transição de Serviço - Página: 304 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 305 de 424
  • 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? ITIL V3 - Transição de Serviço - Página: 306 de 424
  • • 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? ITIL V3 - Transição de Serviço - Página: 307 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 308 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 309 de 424
  • 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 Transição de Serviço. 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 Transição de Serviço. 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 ITIL V3 - Transição de Serviço - Página: 310 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 311 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 312 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 313 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 314 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 315 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 316 de 424
  • 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 ITIL V3 - Transição de Serviço - Página: 317 de 424
  • 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, ITIL V3 - Transição de Serviço - Página: 318 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 319 de 424
  • • 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. ITIL V3 - Transição de Serviço - Página: 320 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 321 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 322 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 323 de 424
  • 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". ITIL V3 - Transição de Serviço - Página: 324 de 424
  • 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 Transição de Serviço. 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. ITIL V3 - Transição de Serviço - Página: 325 de 424
  • 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. ITIL V3 - Transição de Serviço - Página: 326 de 424
  • 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 p