002_itil_v3_design De Serviços.pdf 2q1w53

ITIL Versão 3 Design de Serviços

ITIL V3 - Service Design - Página:

1 de 477

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 - Service Design - Página:

2 de 477

INDICE Prefácio ............................................................................................................. 10 Prefácio da OGC........................................................................................................... 10 Prefácio Arquiteto Chefe............................................................................................... 10

Prefaciar ............................................................................................................ 12 Informações de contato ................................................................................................ 13

Agradecimentos................................................................................................. 14 Arquiteto-chefe e autores ............................................................................................. 14 ITIL autoria da equipe ................................................................................................... 14 Mentores ....................................................................................................................... 14 Outras contribuições ..................................................................................................... 15 O ITIL Grupo Consultivo .................................................................................................. 15 Revisores......................................................................................................................... 15

1 Introdução ...................................................................................................... 16 1.1 Visão Geral ............................................................................................................. 18 1,2 Contexto .................................................................................................................. 19 1.2.1 Gestão de Serviços ................................................................................................ 19 1.2.2 Boas práticas no domínio público ........................................................................... 19 1.2.3 ITIL e boas práticas em Gestão de Serviços .......................................................... 21 1.2.3.1 Estratégia de Serviço .................................................................................................. 23 1.2.3.2 Design de Serviços ..................................................................................................... 23 1.2.3.3 Transição de Serviço .................................................................................................. 24 1.2.3.4 Operação de Serviço .................................................................................................. 24 1.2.3.5 Melhoria de Serviço Continuada.................................................................................. 24

1,3 Propósito ................................................................................................................. 26 1,4 Uso .......................................................................................................................... 26

2 Gerenciamento de Serviço como uma prática ................................................ 27 2.1 O que é Gerenciamento de Serviços? ................................................................... 27 2.2 O que são serviços? ............................................................................................... 29 2.2.1 O valor proposição.................................................................................................. 29

2.3 Funções e processos através do ciclo de vida ...................................................... 30 2.3.1 Funções .................................................................................................................. 30 2.3.2 Processos ............................................................................................................... 30 2.3.3 Especialização e coordenação em todo o ciclo de vida.......................................... 31

2,4 Projeto fundamentos Serviço ................................................................................. 33 2.4.1 Finalidade objetivo / / objetivo................................................................................. 33 2.4.2 Âmbito .................................................................................................................... 33 2.4.3 Valor para os negócios ........................................................................................... 40 2.4.4 Otimizando o desempenho do projeto .................................................................... 40 2.4.5 Processos dentro de Design de Serviços ............................................................... 41

3 Projeto princípios do serviço ........................................................................... 43 3,1 Metas ...................................................................................................................... 47 3,2 projeto equilibrado .................................................................................................. 48 3,3 Identificar necessidades de serviço ....................................................................... 51 3,4 Identificar e documentar os requisitos de negócios e motoristas .......................... 53 3,5 As atividades de projeto ......................................................................................... 56 3,6 aspectos de design ................................................................................................. 58

ITIL V3 - Service Design - Página:

3 de 477

3.6.1 Projetando serviço de soluções .............................................................................. 59 3.6.2 Projetando sistemas de apoio, especialmente o portfólio de serviços .................... 62 3.6.3 arquiteturas de tecnologia Projetando .................................................................... 67 3.6.3.1 Gestão de Tecnologia ................................................................................................. 74

3.6.4 processos Projetando ............................................................................................. 79 3.6.5 Projeto de sistemas de medição e métricas ........................................................... 82

3.7 As seguintes atividades de design ......................................................................... 86 3.7.1 Avaliação de soluções alternativas ......................................................................... 86 3.7.2 Aquisição de a solução preferida ............................................................................ 86 3.7.3 Desenvolver a solução de serviço .......................................................................... 87

3,8 restrições de design................................................................................................ 88 3,9 Arquitetura Orientada a Serviços ........................................................................... 90 3,10 Business Service Management ............................................................................ 92 3,11 design modelos de serviço ................................................................................... 94 3.11.1 modelo opções de entrega ................................................................................... 95 3.11.2 Design e opções de desenvolvimento .................................................................. 96 3.11.3 abordagens de projeto e desenvolvimento ........................................................... 99 3.11.3.1 Rapid Application Development ................................................................................. 99 3.11.3.2 Off-the-shelf soluções ............................................................................................. 103

4 design processos de serviço......................................................................... 105 4.1 Gestão Catálogo de Serviços ............................................................................... 108 4.1.1 Finalidade objetivo / / objetivo............................................................................... 108 4.1.2 Âmbito .................................................................................................................. 108 4.1.3 Valor para o negócio............................................................................................. 108 4.1.4 Políticas, princípios e conceitos básicos............................................................... 109 4.1.5 as atividades de processo, métodos e técnicas.................................................... 112 4.1.6 Triggers, entradas, saídas e interfaces................................................................. 113 4.1.7 Gestão da informação .......................................................................................... 114 4.1.8 Indicadores Chave de Desempenho..................................................................... 114 4.1.9 Desafios, Fatores Críticos de Sucesso e riscos.................................................... 114

4.2 Gestão de Nível de Serviço .................................................................................. 116 4.2.1 Finalidade objetivo / / objetivo............................................................................... 116 4.2.2 Âmbito .................................................................................................................. 117 4.2.3 Valor para o negócio............................................................................................. 118 4.2.4 Políticas / princípios / conceitos básicos............................................................... 118 4.2.5 As atividades de processo, métodos e técnicas ................................................... 119 4.2.5.1 SLA estruturas Projetando ........................................................................................ 121 4.2.5.2 Determinar, documentar e acordar requisitos para novos serviços e produzir SLRs ... 124 4.2.5.3 desempenho serviço Monitor contra SLA .................................................................. 126 4.2.5.4 Intercalar, medir e melhorar a satisfação do cliente ................................................... 128 4.2.5.5 Análise e rever os acordos subjacentes e escopo de serviços ................................... 129 4.2.5.6 serviço relatórios Produzir ......................................................................................... 131 4.2.5.7 Conduta revisões do serviço e instigar melhorias dentro de um SIP geral.................. 132 4.2.5.8 e Revisão de SLAs, o escopo de serviços e acordos subjacentes ............................. 133 4.2.5.9 Desenvolver contatos e relacionamentos .................................................................. 133 4.2.5.10 Reclamações e elogios ........................................................................................... 134

4.2.6 Triggers, entradas, saídas e interfaces................................................................. 135 4.2.6.1 processo entradas SLM ............................................................................................ 135 4.2.6.2 saídas processo SLM................................................................................................ 135

4.2.7 Indicadores Chave de Desempenho..................................................................... 136 4.2.7.1 KPIs.......................................................................................................................... 138

4.2.8 Gestão da Informação .......................................................................................... 139 4.2.9 Desafios, Fatores Críticos de Sucesso e riscos.................................................... 139 4.2.9.1 Fatores Críticos de Sucesso ..................................................................................... 142

4,3 Gerenciamento da Capacidade............................................................................ 143 Finalidade 4.3.1 meta / / objetivo ................................................................................... 143 4.3.2 Âmbito .................................................................................................................. 143

ITIL V3 - Service Design - Página:

4 de 477

4.3.3 Valor para o negócio............................................................................................. 147 4.3.4 Políticas / princípios / conceitos básicos............................................................... 147 4.3.4.1 Gerenciamento da Capacidade de Negócios ............................................................. 149 4.3.4.2 Gerenciamento da Capacidade Serviço .................................................................... 149 4.3.4.3 Gerenciamento da Capacidade Componente ............................................................ 149

4.3.5 as atividades de processo, métodos e técnicas.................................................... 151 4.3.5.1 Gerenciamento da Capacidade de Negócios ............................................................. 151 4.3.5.2 Gerenciamento da Capacidade Serviço .................................................................... 154 4.3.5.3 Gerenciamento da Capacidade Componente ............................................................ 155 4.3.5.4 As atividades subjacentes de Gerenciamento da Capacidade ................................... 156 4.3.5.5 Limiar gestão e controle ............................................................................................ 163 4.3.5.6 Gerenciamento da Demanda .................................................................................... 165 4.3.5.7 Modelagem e tendências .......................................................................................... 166 4.3.5.8 Aplicação dimensionamento...................................................................................... 168

4.3.6 Triggers, entradas, saídas e interfaces................................................................. 169 4.3.6.1 Entradas ................................................................................................................... 169 4.3.6.2 Saídas ...................................................................................................................... 170

4.3.7 Indicadores Chave de Desempenho..................................................................... 171 4.3.8 Gestão da Informação .......................................................................................... 172 4.3.8.1 Capacidade do Sistema de Informação de Gestão .................................................... 173

4.3.9 Desafios, Fatores Críticos de Sucesso e riscos.................................................... 175

4.4 Gerenciamento de Disponibilidade ...................................................................... 177 4.4.1 Finalidade objetivo / / objetivo............................................................................... 177 4.4.2 Âmbito .................................................................................................................. 177 4.4.3 Valor para o negócio............................................................................................. 179 4.4.4 Políticas / princípios / conceitos básicos............................................................... 180 4.4.5 as atividades de processo, métodos e técnicas.................................................... 186 4.4.5.1 As atividades reativas de gerenciamento de disponibilidade ...................................... 187 4.4.5.2 As atividades pró-ativas de gerenciamento de disponibilidade ................................... 201

4.4.6 Triggers, entradas, saídas e interfaces................................................................. 222 4.4.6.1 Entradas ................................................................................................................... 222 4.4.6.2 Saídas ...................................................................................................................... 223

4.4.7 Indicadores Chave de Desempenho..................................................................... 224 4.4.8 Gestão da Informação .......................................................................................... 225 4.4.9 Desafios, Fatores Críticos de Sucesso e riscos.................................................... 227

4,5 Gerenciamento de Continuidade do Serviço ....................................................... 229 4.5.1 Finalidade objetivo / / objetivo............................................................................... 229 4.5.2 Âmbito .................................................................................................................. 230 4.5.3 Valor para o negócio............................................................................................. 231 4.5.4 Políticas / princípios / conceitos básicos............................................................... 231 4.5.5 as atividades de processo, métodos e técnicas.................................................... 233 4.5.5.1 Fase 1 - Iniciação...................................................................................................... 233 4.5.5.2 Fase 2 - Requisitos e estratégia ................................................................................ 234 Requisitos - Business Impact Analysis .....................................................................................................234 Requisitos - Análise de Risco ...................................................................................................................237 Estratégia de TI da Continuidade do Serviço ...........................................................................................242 Resposta medidas de risco.......................................................................................................................242 Armazenamento off-site ............................................................................................................................243 Opções de recuperação ITSCM ...............................................................................................................243

4.5.5.3 Estágio 3 - Implementação ........................................................................................ 247 Planejamento, organização ......................................................................................................................250 Teste .........................................................................................................................................................250

4.5.5.4 Fase 4 - Operação Contínua ..................................................................................... 251 Invocação ..................................................................................................................................................252

4.5.6 Triggers, entradas, saídas e interfaces................................................................. 254 4.5.6.1 Entradas ................................................................................................................... 255 4.5.6.2 Saídas ...................................................................................................................... 256

4.5.7 Indicadores Chave de Desempenho..................................................................... 256 4.5.8 Gestão da Informação .......................................................................................... 257 4.5.9 Desafios, Fatores Críticos de Sucesso e riscos.................................................... 257

ITIL V3 - Service Design - Página:

5 de 477

4.6 Gestão de Segurança da Informação .................................................................. 259 4.6.1 Finalidade objetivo / / objetivo............................................................................... 259 4.6.2 Âmbito .................................................................................................................. 260 4.6.3 Valor para o negócio............................................................................................. 261 4.6.4 Políticas / princípios / conceitos básicos............................................................... 261 4.6.4.1 estrutura de segurança ............................................................................................. 261 4.6.4.2 A Política de Segurança da Informação..................................................................... 262 4.6.4.3 O Sistema de Gestão da Segurança (SGSI) .............................................................. 262

4.6.5 as atividades de processo, métodos e técnicas.................................................... 266 4.6.5.1 Os controles de segurança........................................................................................ 267 4.6.5.2 Gestão de violações de segurança e incidentes ........................................................ 269

4.6.6 Triggers, entradas, saídas e interfaces................................................................. 270 4.6.6.1 Entradas ................................................................................................................... 271 4.6.6.2 Saídas ...................................................................................................................... 272

4.6.7 Indicadores Chave de Desempenho..................................................................... 272 4.6.8 Gestão da Informação .......................................................................................... 273 4.6.9 Desafios, Fatores Críticos de Sucesso e riscos.................................................... 274

4,7 Gestão de Fornecedores ...................................................................................... 277 4.7.1 Finalidade objetivo / / objetivo............................................................................... 277 4.7.2 Âmbito .................................................................................................................. 277 4.7.3 Valor para o negócio............................................................................................. 279 4.7.4 Políticas / princípios / conceitos básicos............................................................... 279 4.7.5 as atividades de processo, métodos e técnicas.................................................... 281 4.7.5.1 Avaliação de novos fornecedores e contratos ............................................................ 282 4.7.5.2 categorização Fornecedor e manutenção do banco de dados de fornecedores e contratos (SCD).................................................................................................................... 288 4.7.5.3 Estabelecimento de novos fornecedores e contratos ................................................. 292 4.7.5.4 Gerenciamento de Fornecedor e Contrato e desempenho ......................................... 294 4.7.5.5 renovação do Contrato e / ou rescisão ...................................................................... 299

4.7.6 Triggers, entradas, saídas e interfaces................................................................. 300 4.7.6.1 Entradas ................................................................................................................... 301 4.7.6.2 Saídas ...................................................................................................................... 302

4.7.7 Indicadores Chave de Desempenho..................................................................... 302 4.7.8 Gestão da Informação .......................................................................................... 303 4.7.9 Desafios, Fatores Críticos de Sucesso e riscos.................................................... 303

5 Serviços de design de tecnologia actividades relacionadas com o ............... 306 5,1 Engenharia de requisitos ...................................................................................... 307 5.1.1 Diferentes tipos de requisitos................................................................................ 307 5.1.1.1 Os requisitos funcionais ............................................................................................ 307 5.1.1.2 Gestão e requisitos operacionais............................................................................... 308 5.1.1.3 Os requisitos de usabilidade ..................................................................................... 309

5.1.2 Requisitos para apoio - a visão de usuário ........................................................... 309 5.1.3 Requisitos técnicas de investigação ..................................................................... 310 5.1.3.1 Entrevistas ................................................................................................................ 310 5.1.3.2 Workshops................................................................................................................ 311 5.1.3.3 Observação .............................................................................................................. 313 5.1.3.4 Análise de Protocolo ................................................................................................. 313 5.1.3.5 Shadowing ................................................................................................................ 313 5.1.3.6 Análise de Cenário.................................................................................................... 314 5.1.3.7 prototipagem ............................................................................................................. 314 5.1.3.8 Outras técnicas ......................................................................................................... 315

5.1.4 Problemas com a engenharia de requisitos .......................................................... 316 5.1.4.1 Resolução de problemas de engenharia requisitos .................................................... 317

5.1.5 Documentação de requisitos ................................................................................ 319 5.1.5.1 O Catálogo de Requisitos ......................................................................................... 320 5.1.5.2 documentação de requisitos completo....................................................................... 322

5.1.6 Requisitos e terceirização..................................................................................... 323 5.1.6.1 requisitos típicos cenários de terceirização................................................................ 324

ITIL V3 - Service Design - Página:

6 de 477

5.2 Dados e Gestão da Informação ........................................................................... 325 5.2.1 Gerenciamento de ativos de dados ...................................................................... 326 5.2.2 Âmbito da Gestão de Dados ................................................................................. 326 5.2.3 Gestão de Dados e do Ciclo de Vida do Serviço .................................................. 328 5.2.4 Apoio ao Ciclo de Vida do Serviço........................................................................ 328 5.2.5 Valorização dados ................................................................................................ 328 5.2.6 Classificando dados.............................................................................................. 329 Dados 5.2.7 estabelece normas .................................................................................... 330 5.2.8 Propriedade dos dados......................................................................................... 330 5.2.9 A migração de dados ............................................................................................ 331 5.2.10 O armazenamento de dados .............................................................................. 331 5.2.11 A captura de dados............................................................................................. 332 5.2.12 recuperação de dados e uso .............................................................................. 332 5.2.13 A integridade de dados e questões relacionadas ............................................... 332

5,3 Gerenciamento de Aplicativos .............................................................................. 334 5.3.1 O portfólio de aplicativos ...................................................................................... 335 5.3.2 Vinculação portfólios de aplicativos e serviço....................................................... 335 5.3.3 frameworks de aplicação ...................................................................................... 336 5.3.4 A necessidade de ferramentas CASE e repositórios ............................................ 337 5.3.5 Design de aplicações específicas ......................................................................... 337 5.3.6 Gerente trade-offs................................................................................................. 339 5.3.7 típicas saídas de projeto ....................................................................................... 339 5.3.8 Os padrões de design........................................................................................... 339 5.3.9 Desenvolvimento de aplicações individuais.......................................................... 340 5.3.10 consistentes convenções de codificação ............................................................ 341 5.3.11 modelos e geração de código ............................................................................. 341 5.3.12 instrumentação aplicativo embutido.................................................................... 342 5.3.13 ganchos de diagnóstico ...................................................................................... 342 5.3.14 Principais saídas de serviço de desenvolvimento............................................... 343

6 Organizador para Design de Serviços .......................................................... 344 6.1 Análise Funcional papéis...................................................................................... 346 6.2 Análise de Atividade ............................................................................................. 346 6,3 habilidades e atributos .......................................................................................... 347 6,4 Funções e responsabilidades ............................................................................... 348 6.4.1 Processo de proprietário....................................................................................... 348 6.4.2 Gerente de Service Design ................................................................................... 348 6.4.3 Planner TI ............................................................................................................. 349 6.4.4 TI Designer / Arquiteto .......................................................................................... 351 6.4.5 Gerente de Catálogo de Serviço........................................................................... 354 6.4.6 Gerente de Nível de Serviço ................................................................................. 354 6.4.7 Availability Manager.............................................................................................. 355 6.4.8 Gestor de Continuidade de Serviços de TI ........................................................... 356 6.4.9 Capacity Manager................................................................................................. 357 6.4.10 Security Manager................................................................................................ 359 6.4.11 Gerente de Fornecedor ...................................................................................... 360

7 considerações de tecnologia ........................................................................ 362 7,1 projeto Ferramentas de serviço............................................................................ 363 7,2 Ferramentas de Gestão de Serviço ..................................................................... 367

8 Design de Serviços Implementar .................................................................. 372 8.1 Análise de Impacto no Negócio ............................................................................ 373 8,2 Nível Requisitos de Serviço.................................................................................. 374 8,3 Riscos para os serviços e processos ................................................................... 374 8,4 Service Design Implementar ................................................................................ 375 8.4.1 O que é a visão?................................................................................................... 377

ITIL V3 - Service Design - Página:

7 de 477

8.4.2 Onde estamos agora? .......................................................................................... 378 8.4.3 Onde é que nós queremos ser? ........................................................................... 380 8.4.4 Como é que vamos chegar lá? ............................................................................. 380 8.4.5 Como podemos dizer quando temos lá? .............................................................. 380 8.4.6 Como é que vamos continuar? ............................................................................. 381

8,5 Medição de Design de Serviços ........................................................................... 382 8.5.1 Pré-requisitos para o sucesso .............................................................................. 383 8.5.2 Fatores Críticos de Sucesso e Indicadores Chave de Desempenho .................... 383

9 Desafios, Fatores Críticos de Sucesso e riscos ............................................ 386 9,1 Desafios ................................................................................................................ 386 9,2 Riscos ................................................................................................................... 388

Posfácio........................................................................................................... 389 Apêndice A: O Pacote de Desenho de Serviço................................................ 390 Apêndice B: Critérios de aceitação do serviço (exemplo) ................................ 393 Anexo C: modelos de processo de documentação (exemplo) ......................... 395 C1 Process Framework .............................................................................................. 395

Anexo D: Design e Planejamento documentos e seus conteúdos ................... 396 D1 Design e documentos de arquitetura e padrões .................................................. 397 D2 planos de TI........................................................................................................... 398

Apêndice E: arquiteturas e padrões ambientais ............................................... 400 Edifício tabela E.1 / site ................................................................................................. 400 Tabela E.2 quarto equipamento principal ...................................................................... 400 Tabela E.3 grandes centros de dados ........................................................................... 401 Tabela E.4 centros de dados regionais e centros de equipamento principal ................. 402 Servidor Tabela E.5 ou salas de equipamentos de rede ............................................... 403 Tabela E.6 ambientes de escritório ............................................................................... 404

Anexo F: SLA e OLA Amostra ......................................................................... 405 Service Level Agreement (SLA - Amostra) ................................................................ 405 Descrição do serviço: .................................................................................................... 405 Âmbito do acordo:.......................................................................................................... 405 Horas de serviço: ........................................................................................................... 406 Disponibilidade do serviço: ............................................................................................ 406 Confiabilidade: ............................................................................................................... 406 Atendimento ao cliente: ................................................................................................. 407 Pontos de o e de escalação: .............................................................................. 407 Desempenho do serviço: ............................................................................................... 407 Turnaround vezes lote: .................................................................................................. 408 Funcionalidade (se for o caso):...................................................................................... 408 Gestão da Mudança: ..................................................................................................... 408 Continuidade de serviço: ............................................................................................... 408 Segurança: .................................................................................................................... 409 Impressão: ..................................................................................................................... 409 Responsabilidades: ....................................................................................................... 409 Carregamento (se aplicável):......................................................................................... 409 Serviço de relatórios e analisar:..................................................................................... 409 Glossário: ...................................................................................................................... 410 Folha de alteração: ........................................................................................................ 410

Acordo de Nível Operacional (ANO - Amostra) ......................................................... 410 Detalhes de alterações anteriores: ................................................................................ 410 e Descrição do serviço: ....................................................................................... 410 Âmbito do acordo:.......................................................................................................... 411 Horas de serviço: ........................................................................................................... 411 Metas de serviço:........................................................................................................... 411

ITIL V3 - Service Design - Página:

8 de 477

Pontos de o e de escalação: .............................................................................. 411 Posto de serviço e tempos de resposta a incidentes e responsabilidades: ................... 411 Problema tempos de resposta e responsabilidades: ..................................................... 411 Gestão da Mudança: ..................................................................................................... 411 Gerenciamento de lançamento: ..................................................................................... 411 Gerenciamento de Configuração: .................................................................................. 411 Gestão de Segurança da Informação: ........................................................................... 412 Gerenciamento de Disponibilidade: ............................................................................... 412 Gestão da Continuidade de serviço: .............................................................................. 412 Gerenciamento da Capacidade: .................................................................................... 412 Gerenciamento de Nível de Serviço: ............................................................................. 412 Gestão de Fornecedores: .............................................................................................. 412 Próvisão de informações: .............................................................................................. 412 Glossário: ...................................................................................................................... 412 Folha de alteração: ........................................................................................................ 413

Anexo G: Catálogo de Serviço Exemplo .......................................................... 414 Anexo H: O Serviço de Gerenciamento quadro maturidade do processo ........ 415 Inicial (Nível 1) ............................................................................................................ 417 Repetitivo (Nível 2) ..................................................................................................... 418 Definido (Nível 3) ........................................................................................................ 419 Gerenciado (Nível 4) ................................................................................................... 420 Otimização (Nível 5) ................................................................................................... 421

Apêndice I: conteúdo exemplo de uma declaração de Necessidade (SOR) e / ou concurso (ITT) ................................................................................................. 422 Anexo J: Os conteúdos típicos de um plano de capacidade ............................ 423 1 Introdução ................................................................................................................ 423 2 Resumo de Gestão .................................................................................................. 423 3 cenários de negócios ............................................................................................... 423 4 Âmbito e termos de referência do plano de ............................................................ 423 5 Os métodos utilizados ............................................................................................. 424 6 suposições feitas ..................................................................................................... 424 7 resumo Serviço ........................................................................................................ 424 8 resumo de Recursos................................................................................................ 425 9 Opções para melhoria do serviço............................................................................ 425 10 Custos previstos .................................................................................................... 425 11 Recomendações .................................................................................................... 426

Apêndice K: Os conteúdos típicos de um plano de recuperação ..................... 427 Outras informações ......................................................................................... 435 Referências ................................................................................................................. 435

Glossário ......................................................................................................... 436 Lista de siglas ............................................................................................................. 436 Lista de definições ...................................................................................................... 440

ITIL V3 - Service Design - Página:

9 de 477

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, negócios revisto modelos e aumentando cliente expectativas. Nossa mais recente versão do ITIL foi criado em resposta a estes desenvolvimentos. Este é um dos cinco publicações principais que descrevem a TI Serviço de Gestão de práticas que compõem a ITIL. Eles são o resultado de um de dois anos projeto para rever e atualizar a orientação. O número de Serviço de Gestão de profissionais em 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 é ado pela contínua desenvolvimento 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 negócio, ITIL dá o a nível mundial Serviço de Gestão de perícia. Essencialmente, ele coloca De serviços de TIÉ onde eles pertencem - no coração do sucesso operações comerciais.

Peter Fanning Atuando Executivo Office of Government Commerce

Prefácio Arquiteto Chefe Grande serviços não existem por acaso. Eles têm de ser cuidadosamente planejado e projetado. Design de Serviços é o meio para alcançar este objectivo. O melhor Estratégia de Serviço não pode ser realizado sem bem desenhados serviços. Design de Serviços eficaz pode levar organizaçãos para maiores

ITIL V3 - Service Design - Página:

10 de 477

ganhos de qualidade e custo-efetividade. Reduz o risco de compensar dispendioso para falhas de design na operacional meio ambiente e garante que irá executar os serviços que se destinem e trazer valor mensurável para o objetivo de negócios. No ado, o mundo da TI foi visto em duas partes - o mundo do desenvolvimento e do mundo operacional. A falta de sinergia entre esses mundos muitas vezes produz um efeito colateral grave - os objetivos de negócio não são cumpridas. Um dos objectivos principais do Design de Serviços é eliminar essa visão do velho mundo e trazer De serviços de TI em uma visão única e consolidada de projetar serviços dentro das realidades, constrangimentos e oportunidades da vivo operação. A oportunidade de tirar partido das novas tecnologias, maximizar a utilização da infra-estrutura existente, aplicações, dados e conhecimentos ganha vida nas páginas desta publicação. Design de Serviços amplia nossos horizontes e nos ajuda a ver uma tela maior, mais coeso de TI Serviço de Gestão de. Qualquer organização de TI que quer maximizar seu potencial para atender objetivo de negócios e valor de negócio precisa dessa publicação no seu arsenal de recursos. Design de Serviços é uma orientação poderosa e uma pedra angular de habilidades práticas, ferramentas e métodos para a excelência do serviço.

Sharon Taylor Arquiteto Chefe, Práticas ITIL Service Management

ITIL V3 - Service Design - Página:

11 de 477

Prefaciar "Qualidade de um produto ou serviço não é o que o fornecedor coloca dentro É o que o cliente sai e está disposto a pagar. 'Peter Drucker, o guru americano de gestão.

O ITIL Serviço de Gestão de práticas são baseados nesta idéia. Serviços são bens a partir do qual o cliente ganha valor. Como bem os serviços são projetados com as necessidades dos clientes em mente irá prever o valor que pode ser derivada a partir deles. Na falta de Design de Serviços, O serviço irá evoluir informalmente, muitas vezes sem aproveitando a perspectiva mais ampla - a visão de negócio. A fase de Desenho de Serviço da ITIL Service Ciclo de Vida tem requisitos de negócios e, usando cinco aspectos de Design de Serviços, cria serviços e seu apoio práticas que atendam às demandas de negócios para qualidade,confiança e flexibilidade. Design de Serviços é iterativo ao longo do Ciclo de Vida do Serviço, e começa com um projeto sólido, que permite o construir,teste e liberar fases Transição de Serviço através da Pacote de Desenho de Serviço. O leitor irá aprender sobre princípios de design para infra-estrutura, aplicação, processoes e recursos, bem como fornecimento modelos. Service Managers também vai encontrar orientações sobre a engenharia de requisitos de som, Gestão de Fornecedores e chave projeto considerações para o serviço terceirização. Se você é um interno ou prestador de serviços externo, Você é parte de um rede de valor e preencher uma crítica papel no Ciclo de Vida de Serviço, através da integração do melhores práticass para Design de Serviços eo ITIL Lifecycle Serviço em produtos inovadores para o empresa cliente. A publicação Service Design proporciona os conhecimentos e habilidades necessários para montar a melhor combinação de serviço ativos para produzir mensuráveis, serviços escaláveis e inovadora, no caminho para a excelência do serviço. Qualquer Provedor de serviços de TI que é esperado para entregar qualidade para o cliente de negócios deve ter o capacidade projetar serviços que atendam às expectativas, então vá para exceder essas expectativas. A orientação desta publicação irá ajudar a alcançar isso.

ITIL V3 - Service Design - Página:

12 de 477

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, faça o los em www.best-managementpractice.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: [email protected]

ITIL V3 - Service Design - Página:

13 de 477

Agradecimentos Arquiteto-chefe e autores

Sharon Taylor (Aspect Group Inc)

Arquiteto Chefe

Vernon Lloyd (Fox IT)

Autor

Colin Rudd (TI Enterprise Management Services Ltd - ITEMS)

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), Shirley Lacy (ConnectSphere), Ivor Macfarlane (Guillemot Rock), Michael Nieves (Accenture), Stuart Rance (HP), George Spalding (Pink Elephant) e David Wheeldon (HP).

Mentores Tony Jenkins Sergio Rubinato Filho

ITIL V3 - Service Design - Página:

14 de 477

Outras contribuições Um número de pessoas contribuíram generosamente seu tempo e conhecimento a este Design de Serviços publicação. Jim Clinch, como OGC Gerente de Projeto, é grato ao apoio prestado por Jenny Dugmore, Convocador de Grupo de Trabalho ISO / IEC 20000, Eves Janine, Carol Hulm, Aidan Lawes e Michiel van der Voort. Os autores também gostariam de agradecer ao Tony Jenkins, DOMAINetc e Steve Rudd TI Enterprise Management Service Limited (itens). Para desenvolver ITIL v3 para refletir as melhores práticas actuais e produzir publicações de valor duradouro, OGC amplas consultas com diferentes das partes interessadass em todo o mundo em todas as fases do processo. OGC também gostaria de agradecer às seguintes pessoas e suas organizações, por suas contribuições à orientação refrescante ITIL a:

O ITIL Grupo Consultivo Pippa Bass, OGC; Tony Betts, Independente; Megan Byrd, Bank of America; 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; Signe Marie Hernes, Det Norske Veritas; Carol Hulm, British Computer Society-ISEB; Tony Jenkins, DOMAINetc; Phil Montanaro, EDS; Alan Nance, ITpreneurs; Christian Nissen, itelligence; Don Page, 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 Justin Alford, Espírito Consultoria; Rajeev Andharia, Sun; Antonio Arévalo, SATEC; Kamal Kishore Arora, Infosys Technologies; G. Arvinda; Martin Andenmatten, Independente; Brian Barber, Serra de Sistemas; Pierre Bernard, Pink Elephant, Jason Besant; Twane Boettinger, primeiro cdn; Juergen Breithaupt, Infora; Javier Marques Cabrero, Deloitte; Neil Chadwick, David Colburn, The Creek; Bob Costa, do Exército dos EUA; Wills Damasio, Quint Wellington Redwood; Catalin Danila, GlaxoSmithKline, SRL Roménia; Juergen Dierlamm, Rechtsanwaitkanzlei Dierlamm; Peter Doherty, CA; Thomas Dressler, EDV-Beratung; Fouad El Sioufy, TUV Rheinland Secure IT GmbH; Jaime Eduardo Facioli, Kalendae IT Service Management; Juergen Feldges, DNV; Prasad Gadgil, Satyam Computer Services Ltd; Kingshuk Ghosh, HP; Sandeep Gondhalekar, Quint Wellington Redwood, John Graham, Educad; Juergen Gross, Independente; Ib Guldager, CSC; Tsuyoshi Hamada, HP; Eero Heikkonen, Efecte; Christoph Herwig, Accenture; Thomas Hess, pluralis AG; Maria Hondros, da Microsoft, Thomas Jahn; Chris Jones, Ariston Consultoria Estratégica; Daniel Keller, SUIT Suíça; Brian Kerr, Axios Systems, Robert Kuhlig, mITSM; Hendrikje Kuhne, KTP-organisationsterberatung; Dirk Koetting, EDV - Konzepte; Madhav Lakshminarayanan; Jane Link, Acerit Limited; Ernst Guido Leidhe , Telelogic; Ryan Lloyd, MKS; Eduardo Magalhães, Paulo Martini, HP; Raimund Martl, HP, Ruth Mason, Kcit; Tan Heng Meng, Starhub; Rohit Nand, Infosys, Edward Newman; Glen Notman, Pink Elephant, Tuomas Nurmela, TietoEnator Processamento e Rede Oy; Benjamin Orazem, SRC.SI; Fadi Otoun; Gerard Persoon, E.Novation; Neil Pinkerton, Laughingtree; Christian Probst, Quint Wellington Redwood; Rajwardhan Purohit; Rajesh Radhakrishnan, IBM; Zahra Rahemtulla, BearingPoint, Arvind Raman, Infosys; Brian Rowlatt, a LogicaCMG; Sutirtha Roy Chowdhury, Serra de Sistemas; Parmjit Sangha, Alexander Sapronov, HP; s Scarff, OGC; Alan Shepherd, Deutsche Bank AG, Renato Maia Silva; Moira Stepchuk, Pultorak; Russel Steyn, Foster-Melliar; Stephen Straker, Fujitsu, rico Sylva, Microsoft; José Tamo, QualiTI7; Brett Tilney; Michael Tomkinson, BT; Mathias Traugott, Swisscom, Ken Turbitt, BMC Software; Wiley Vasquez, BMC Software, Brian Verbrugge, RBC; Ettiene Vermeulen, Datacentrix; Joachim von Caron, Lufthansa Systems; Andreas Weinberger, DekaBank; Sven Werner, Unilog Avinci GmbH; Ken Williamson, Tyler Pedra Consultoria; Ann Inverno, EMC, Theresa Wright, Computacenter Serviços; Geoffrey Wyeth, Independente; Rob Young, Fox IT, Michael Zimmermann , NETCONS

ITIL V3 - Service Design - Página:

15 de 477

1 Introdução O primário objetivo de Serviço de Gestão de é o de assegurar que o De serviços de TIs estão alinhados com as necessidades do negócio e apoiar ativamente deles. É imperativo que os serviços de TI apoiar o processo de negócioes, mas também é cada vez mais importante que a TI atua como um agente de mudança para facilitar a transformação de negócios. Todos organizaçãos que usam a TI vai depender de TI para ser bem sucedido. Se os processos de TI e serviços de TI são implementados, geridos e apoiados de forma adequada, o negócio será mais bem sucedido, sofrem menos perturbações e perda de horas produtivas, reduzir custars, aumentar a receita, melhorar as relações públicas e alcançar o seu objetivo de negócios. A maioria das autoridades agora identificar quatro tipos de ativos de TI que precisam ser adquiridas e geridas de forma a contribuir para a prestação de serviços de TI eficaz. Estes são infraestrutura de TI, aplicaçãos, informações e pessoas. Especificamente há uma forte ênfase na aquisição, gestão e integração desses ativos ao longo do seu "nascimento à aposentadoria" ciclo de vida. A entrega de serviços de TI de qualidade depende de uma gestão eficaz e eficiente desses ativos. Esses ativos por conta própria, no entanto, não são suficientes para atender a Serviço de Gestão de necessidades do negócio. ITIL Serviço de Gestão de práticas usar esses tipos de ativos quatro como parte de um conjunto de capacidades e recursoé chamado de 'serviço ativos '.

Figura 1.1 Recursos e capacidades são a base para a criação de valor

Um De serviços de TI, Utilizado para apoiar processo de negócioes, é construído a partir de uma combinação de ativos de TI e externamente, desde 'que sustentam' serviços. Uma vez no local, um serviço de TI deve ser apoiado ao longo de sua "vida", durante o qual pode ser modificado muitas vezes, seja

ITIL V3 - Service Design - Página:

16 de 477

através da inovação tecnológica empresarial, mudando ambiente, O uso de mudança da serviço, Alterando seus parâmetros de qualidade de serviço, ou alterar seus ativos de TI de apoio ou recursos (por exemplo, um mudar em uma aplicação de software componente para fornecer funcionalidade adicional). Eventualmente, o serviço de TI é aposentard, quando o negócio processoes não tem mais um uso para ele ou ele não é mais custo-efetiva para correr. Transição de Serviço está envolvida na construir e desenvolvimento do serviço e do dia-adia, apoio e entrega do serviço é a papel de Operação de Serviço, Enquanto Melhoria de Serviço Continuada implementa melhores práticas no otimizar e se aposentar etapas. A partir desta perspectiva, Design de Serviços pode ser visto como a recolha de necessidades de serviços e mapeá-los às necessidades de serviços integrados e de criar o projeto especificaçãos para o serviço ativos necessários para prestação de serviços. Uma característica particular dessa abordagem é uma forte ênfase na reutilização durante o projeto. O principal objetivo do Service Design é projetar serviços de TI, juntamente com as que regem as práticas de TI, processos e políticas, para realizar o estratégia e para facilitar a introdução dos serviços para o viver ambiente garantir a qualidade do serviço de entrega, satisfação do cliente e custo-eficaz prestação de serviços. Design de Serviços também deve projetar os serviços de TI de forma eficaz, de modo que eles não precisam de uma grande quantidade de melhoria durante a sua ciclo de vida. No entanto, a melhoria contínua deve ser incorporado em todas as atividades de design de serviço para garantir que as soluções e os projetos tornam-se ainda mais eficaz ao longo do tempo e identificar novas tendências no negócio que podem oferecer oportunidades de melhoria. As atividades de projeto de serviços podem ser periódicas ou exceção baseada em quando pode ser desencadeada por uma necessidade de negócio ou evento específico. Se os serviços ou processos não são projetados eles vão evoluir organicamente. Se evoluir sem a devida controlars, a tendência é simplesmente a reagir às condições ambientais que ocorreram em vez de compreender claramente a global visão e necessidades globais do negócio. Projetando para combinar com o ambiente esperado é muito mais eficaz e eficiente, mas muitas vezes impossível - daí a necessidade de se considerar iterativo e abordagens incrementais Design de Serviços. Iterativo e abordagens incrementais são essenciais para assegurar que os serviços introduzidos no ambiente real se adaptar e continuar em linha com as necessidades de negócio em evolução. Na ausência de Design de Serviços formalizada, serviços, muitas vezes, ser excessivamente caro para ser executado, propenso a falha, Os recursos serão desperdiçados e serviços não ser completamente alinhado com as necessidades do negócio. É pouco provável que qualquer melhoria programa nunca vai ser capaz de conseguir o que projeto adequado seria alcançar em primeiro lugar. Sem Design de Serviços, o custo-benefício serviço não é possível. Os aspectos

ITIL V3 - Service Design - Página:

17 de 477

humanos do Design de Serviços também são de extrema importância, e estes serão explorados em detalhe mais tarde nesta publicação.

1.1 Visão Geral Esta publicação faz parte do ITIL geral Serviço de Gestão de práticas e abrange o projeto de adequadas e inovadoras de TI serviços para atender atuais e futuros requisitos de negócios acordados. Ele descreve os princípios do Desenho de Serviço e olha para identificar, definir e alinhar a solução de TI com as necessidades dos negócios. Além disso, introduz o conceito de Pacote de Desenho de Serviço e olha para selecionar o apropriado Design de Serviços modelo. A publicação também aborda os fundamentos dos processos de design e os cinco aspectos do projeto: • • • • •

Serviços Projeto de sistemas de gerenciamento de serviços e ferramentas, especialmente o Portfólio de Serviços Tecnologia arquiteturas e sistema de gestãos Processoes Métodos de medição e métricos.

A publicação abrange os métodos, práticas e ferramentas para alcançar a excelência em Design de Serviço. Ele aplica o princípio de que o Design de Serviços inicial deve ser conduzido por uma série de fatores, incluindo os requisitos funcionais, os requisitos dentro do Contratos de Nível de Serviço (SLAs), os benefícios de negócio e as restrições de design em geral. Capítulo 4 explica o processo de ponta a ponta das áreas chave para o sucesso Design de Serviços. Estes processos são utilizados por todas as outras fases do Serviço Ciclo de VidaE outros processos são levados em conta por Design de Serviço. No entanto, é aqui que o Gerenciamento de Catálogo de Serviço, Gerenciamento de Nível de Serviço,Gerenciamento da Capacidade,Gerenciamento de Disponibilidade,Gerenciamento da Continuidade do Serviço,Gestão de Segurança da Informação e Gestão de Fornecedores são abordados em detalhes. Os apêndices para esta publicação dar exemplos da Pacote de Desenho de Serviço,Critérios de aceitação de serviços, Modelos de documentação de processos, design e documentos de planejamento, arquiteturas e padrões ambientais, amostra de SLAs, e OLAs Catálogo de Serviços e a Serviço de Gestão de estrutura de maturidade de processo.

ITIL V3 - Service Design - Página:

18 de 477

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, sistemas de TI, aplicaçãos, infra-estrutura e são componentes ou subconjuntos de um produto maior. Eles permitem ou são incorporados em processos e serviços. A partir da segunda perspectiva, é uma organização com seu próprio conjunto de capacidades e recursos. Organizações de TI podem ser de vários tipos, tais como funções de negócios, unidades de serviços partilhados, e as unidades de nível empresarial do núcleo. A partir da terceira perspectiva, é uma categoria de serviços utilizados pelas empresas. Eles são tipicamente de TI aplicaçãos e infra-estrutura que são embalados e oferecida como serviços internos de TI por organizações ou prestador de serviços externos. TI custars são tratados como despesas comerciais. A partir da quarta perspectiva, a TI é uma categoria de ativos de negócios 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 em ambientes dinâmicos com a necessidade de aprender e se adaptar. Existe uma necessidade de melhorar atuação enquanto gestora trade-offs. Sob pressão semelhante, clientes procuram vantagem de prestadores de serviços. Eles perseguem estratégias de sourcing que melhor servem os seus próprios interesses comerciais. Em muitos países, agências governamentais e organizações sem fins lucrativos têm uma tendência semelhante de terceirizar para o bem da operacional eficácia. Isso coloca uma pressão adicional sobre os prestadores de serviços para manter uma vantagem competitiva em relação às alternativas que os clientes possam ter. O aumento em terceirização se particularmente expostas prestador de serviços internos à concorrência incomum. Para lidar com a pressão 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 na utilização de toda a indústria. Existem várias fontes de boas práticas, incluindo estruturas públicas, padrões e conhecimento de propriedade de organizações e indivíduos (Figura 1.2).

ITIL V3 - Service Design - Página:

19 de 477

Figura 1.2 Fornecimento de prática Gestão de Serviços

Estruturas públicas e as normas são atraentes quando comparados com conhecimento de propriedade: •

•

•

•

•

Conhecimento proprietário está profundamente enraizado na organizaçãos e, portanto, difíceis 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,COBIT, CMMI, eSCM-SP, PRINCE2,ISO 9000, ISO / IEC 20000 e ISO / IEC 27001 são validados através de um conjunto diversificado de ambientes e situações, em vez de limitada experiência de uma única organização. Eles estão sujeitos a ampla revisão através de várias organizações e disciplinas. Eles são controlados por diversos conjuntos de parceiros, fornecedors e concorrentes. O conhecimento das estruturas públicas é mais provável a ser amplamente distribuído entre uma grande comunidade de profissionais por meio de treinamento disponíveis publicamente e certificado. É mais fácil para as organizações a adquirir tais conhecimentos por meio do mercado de trabalho.

ITIL V3 - Service Design - Página:

20 de 477

Ignorando estruturas públicas e padrões podem desnecessariamente colocar uma organização em desvantagem. As organizações devem cultivar seu próprio conhecimento proprietária em cima de um corpo de conhecimento baseado em quadros públicos e padrões. Colaboração e coordenação entre as organizações são mais fáceis com base compartilhada práticas e padrões.

1.2.3 ITIL e boas práticas em Gestão de Serviços O contexto desta publicação é o framework ITIL como uma fonte de boas práticas Serviço de Gestão de. ITIL é usado por organizações em todo o mundo para estabelecer e melhorar as capacidades de gerenciamento de serviços. ISO / IEC 20000 fornece uma formal e universal padrão para organizações que buscam ter seus recursos de gerenciamento de serviço auditado e certificado. Enquanto a norma ISO / IEC 20000 é um padrão a ser alcançado e mantido, ITIL oferece um corpo de conhecimento útil para alcançar o padrão. A Biblioteca ITIL tem o seguinte componentes: • •

O Core ITIL - melhores práticas orientações aplicáveis a todos os tipos de organizações que prestam serviços para um negócio O ITIL Orientação Complementar - um conjunto complementar de publicações com orientações específicas para os setores da indústria, tipos de organização, operando modelos e tecnologia arquiteturas.

O Core ITIL é composto por cinco publicações (Figura 1.3). 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 - Service Design - Página:

21 de 477

Figura 1.3 ITIL Núcleo

Cada publicação aborda as capacidades que têm direta impacto num 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çãos são criados para alavancar as capacidades em uma área de aprendizagem e melhorias em outras. O Núcleo é esperado para dar estabilidade, estrutura e força para Serviço de Gestão de capacidades com duráveis princípios, métodos e ferramentas. Isso serve para proteger os investimentos e proporcionar a base necessária para a aprendizagem, medição e melhoria. A orientação em ITIL pode ser adaptado para uso em ambientes de negócios diversos e estratégias organizacionais. Orientação Complementar fornece flexibilidade para implementar o núcleo em uma variada gama de ambientes. Praticantes pode selecionar Orientação Complementar, conforme necessário para fornecer tração para o Core em um contexto determinado negócio, assim como os pneus são selecionados com base no tipo de condições de uso do veículo, e estrada. Isso é para aumentar a durabilidade e portabilidade dos ativos de conhecimento e de proteger os investimentos em capacidades de Gestão de Serviços.

ITIL V3 - Service Design - Página:

22 de 477

1.2.3.1 Estratégia de Serviço

O Estratégia de Serviço publicação fornece orientações sobre como projetar, desenvolver e implementar o Gerenciamento de Serviço, não apenas como uma organização capacidade mas também como um estratégico ativos. São fornecidas orientações sobre os princípios subjacentes à prática de Gestão de Serviços, que são úteis para o desenvolvimento de políticas de gerenciamento de serviços, diretrizs e processoes em todo o ITIL Service Lifecycle. Orientação Estratégia serviço é útil no contexto de Design de Serviços,Transição de Serviço,Operação de ServiçoE Melhoria de Serviço Continuada. Os tópicos abordados na Estratégia de Serviço incluem o desenvolvimento de mercados interno e externo, serviço ativos, Catálogo de ServiçosE implementação de estratégia através do Ciclo de Vida do Serviço. Gestão Financeira, Gestão de Portfólio de Serviços, Desenvolvimento Organizacional e riscos estratégicos estão entre outros grandes temas. Organizações usam a orientação para definir objetivos e expectativas de desempenho para servir clientes e espaços de mercado, e de identificar, selecionar e priorizar oportunidades. Estratégia de Serviço se de garantir que as organizações estão em uma posição para lidar com a custars e os riscos associados ao seu Portfólio de Serviçoss, e são criados não só para operacional eficácia mas também para um desempenho diferenciado. As decisões tomadas em relação à Estratégia de Serviço tem conseqüências de longo alcance, incluindo aqueles com efeito retardado. Organizações já praticando ITIL usar este volume para guiar um estratégico rever da sua ITIL baseada Serviço de Gestão de capacidades e melhorar o alinhamento entre esses recursos e suas estratégias de negócios. Este volume de ITIL incentiva os leitores a parar e pensar sobre por que algo está a ser feito antes de pensar em como fazer. As respostas para o primeiro tipo de perguntas estão mais próximos da clienteO negócio. Estratégia de Serviço expande a escopo do Quadro de 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 projeto e desenvolvimento de serviços e Serviço de Gestão de processos. Ele abrange os princípios de design e métodos para a conversão estratégico objetivos em carteiras de serviços e serviço ativos. O escopo do Serviço de projeto não se limita a novos serviços. Ele inclui o mudars e melhorias necessárias para aumentar ou manter valor para os clientes durante o ciclo de vida dos serviços, a continuidade dos serviços, a realização de nível de serviços e conformidade com as normas e regulamentos. Ele orienta as organizações sobre como desenvolver capacidades de design para Gerenciamento de Serviços. ITIL V3 - Service Design - Página:

23 de 477

1.2.3.3 Transição de Serviço

O Transição de Serviço publicação fornece orientação 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ções sobre como os requisitos de Estratégia de Serviço codificado em Design de Serviços são efetivamente realizados em operação de serviços, enquanto controla os riscos de falha e ruptura. A publicação combina práticas em Gerenciamento de Liberação, Gestão de Programa e gestão de risco, E coloca-os no contexto da prática de Serviço de Gestão de. Ele fornece orientações sobre o gerenciamento da complexidade relacionada a alterações nos serviços e Serviço de Gestão de processoes evitando consequências indesejáveis, permitindo a inovação. Orientação é fornecida sobre a transferência do controlar de serviços entre clientes e provedor de serviçoss. 1.2.3.4 Operação de Serviço

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

Esta publicação oferece orientação instrumental na criação e manutenção de valor para os clientes através de uma melhor concepção, transição e operação de serviços. Combina princípios, práticas e os métodos de gestão da qualidade, Gestão da Mudança e melhoria de capacidade. Organizações aprender a perceber melhorias incrementais e de larga escala em serviço qualidade,operacional eficiência e continuidade dos negócios. Orientação é fornecida para ligar os esforços de melhoria e resultados com estratégia de serviço, Transição, design e operação. Um sistema de retorno de ciclo fechado, com base na Plan-Do-Check-Act (PDCA) modelo especificado na norma ISO /

ITIL V3 - Service Design - Página:

24 de 477

IEC 20000, é estabelecido e capaz de receber entradas para a mudança de qualquer perspectiva de planejamento.

ITIL V3 - Service Design - Página:

25 de 477

1,3 Propósito O objetivo desta publicação é dar a orientação sobre o uso de leitor de práticas recomendadas ao projetar De serviços de TIs e TI Serviço de Gestão de processos. Esta publicação surge na sequência do Estratégia de Serviço publicação, que fornece orientação sobre o alinhamento e integração das necessidades do negócio para a TI. Ele permite que o leitor a avaliar os requisitos na concepção de um serviço e indústria documentos melhores práticas para o projeto de De serviços de TIs e processos. Embora esta publicação pode ser lido de forma isolada, recomenda-se que seja utilizada em conjunto com a outra ITIL publicações. As orientações do ITIL publicações é aplicável genericamente. É burocrática nem pesado se for utilizado de forma sensata e no pleno reconhecimento das necessidades do negócio da organização. Design de Serviços É importante para o palco para entregar serviços de forma eficaz para o negócio e atender a demanda de crescimento e mudança. Enhancement é tipicamente superior em custar e recursos do que desenvolvimento. Consideração importante deve ser dado a projetar para a facilidade e economia de apoio ao longo de todo ciclo de vida, Mas, mais importante ainda, não é possível eliminar completamente reengenharia um serviço de uma vez em produção. É possível chegar perto, mas vai ser impossível voltar a um projeto uma vez que algo está sendo executado. Reequipamento do projeto é difícil e caro e nunca alcança o que poderia ter sido alcançado se projetado

1,4 Uso Esta publicação é relevante para qualquer pessoa envolvida na concepção, implementação ou e de serviços de TI. Ela terá relevância para o arquiteto de TI, gerentes de TI e profissionais de todos os níveis. Todas as publicações do ITIL Serviço de Gestão de Biblioteca núcleo precisa ser lido para apreciar e entender o ciclo de vida total dos serviços e do IT Service Management. Existem várias maneiras de entregar um serviço de TI, tais como em casa, terceirizados e parceria. Esta publicação é geralmente relevantes para todos os métodos de prestação de serviços. Assim, os envolvidos na prestação de serviços de TI - dentro de sua própria organização, Na prestação de serviços terceirizados ou a trabalhar em parcerias - vai achar que esta publicação se aplica a eles. Os gerentes de negócios pode encontrar a publicação útil para a

ITIL V3 - Service Design - Página:

26 de 477

compreensão e definição das melhores práticas de serviços de TI e e. Gestores de fornecedor organizações também vai encontrar esta publicação relevante quando a criação de acordos para a entrega e e de serviços.

2 Gerenciamento de Serviço como uma prática 2.1 O que é Gerenciamento de Serviços? Serviço de Gestão de é um conjunto de capacidades especializadas organizacionais para o valor de clientes, sob a forma de serviços. As capacidades de assumir a forma de funções e processoes para gerenciamento de serviços ao longo de um ciclo de vida, com especializações em estratégia, Design, transição,operação e melhoria contínua. Os recursos representam um serviço de 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, uma organização de serviço é meramente um conjunto de recursos que por si só tem relativamente baixo valor intrínseco para os clientes. Service Management é um conjunto de capacidades especializadas organizacionais para o valor aos clientes na forma de serviços. Capacidades organizacionais são moldadas pelos desafios que eles terão de superar. Serviço de Gestão de capacidades são igualmente influenciado pelos seguintes desafios que distinguem serviços de outros sistemas de criação de valor, tais como mineração, manufatura e agricultura: • • • •

Natureza intangível da produção e produtos intermediários de processos de serviços: difíceis de medir, controlar e validar (ou provar) A demanda está intimamente ligado com clienteOs ativos: usuários e ativos dos clientes, tais como processos, aplicaçãos, documentos e transaçãos chega com a demanda e estimular a produção de serviços Alto nível de contato para os produtores e consumidores de serviços: buffer pouca ou nenhuma entre o cliente, o front-office e back-office A natureza perecível 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 ado por um extenso corpo de conhecimento, experiência e habilidades. Uma comunidade global de indivíduos e organizaçãos nos 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

ITIL V3 - Service Design - Página:

27 de 477

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 gestão de TI aplicaçãoA infra-estrutura, e processoes. Soluções para os negócios problemas e e 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 estão provedor de serviçoss, incluindo unidades organizacionais internas. Este, por sua vez, reforçou a prática de gerenciamento de serviços, ao mesmo tempo, impor desafios maiores sobre ele.

ITIL V3 - Service Design - Página:

28 de 477

2.2 O que são serviços? 2.2.1 O valor proposição Um serviço é um meio de entregar valor aos clientes, facilitando resultados clientes querem alcançar, sem a posse de determinado custars e riscos. Serviços são um meio de entregar valor aos clientes, facilitando os resultados que os clientes querem alcançar, sem a posse de custos e riscos específicos. Serviços de facilitar os resultados através do aumento da atuação associado de tarefas e a redução do efeito de restrições. O resultado é um aumento na probabilidade de resultados desejados. Ao longo dos anos, as organizações têm debatido a definição de um "serviço". A ilustração na Figura 2.1 é um exemplo de que a realização do serviço é realmente sobre a entrega de valor aos clientes.

Figura 2.1 Uma conversa sobre a definição e significado de serviços

ITIL V3 - Service Design - Página:

29 de 477

2.3 Funções e processos através do ciclo de vida 2.3.1 Funções Funções são unidades de organizaçãos especializada para executar certos tipos de trabalho e responsáveis por resultados específicos. Eles são auto-suficientes, com capacidades e recursos necessários para o seu desempenho 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 normalmente definem papels ea autoridade associado e responsabilidade por um determinado atuação e os resultados. Coordenação entre funções através compartilhada processoes é um padrão comum na organização projeto. Funções tendem a otimizar seus métodos de trabalho 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 que são críticos 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 sistemas de circuito fechado, pois fornecem mudar e transformação em direção a um objetivo, e utilizar o para a autoreforç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

ITIL V3 - Service Design - Página:

30 de 477

Definições de processos descrevem ações, dependências e seqüência. Processos de ter as seguintes características: •

•

•

•

Mensurável - Somos capazes de medir o processo de uma forma 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. Os resultados específicos - A razão existe um processo é a entrega de um resultado específico. Este resultado deve ser individualmente identificáveis e contáveis. Enquanto podemos contar mudanças, é impossível contar quantas Mesas de serviços foram concluídos. Clientes - Cada processo de entrega de seus resultados primários para um cliente ou das partes interessadas. Os clientes podem ser internos ou externos à organização, mas o processo deve atender suas expectativas. Responde a um específico evento - Enquanto um processo pode ser contínuo ou iterativo, deve ser feita com um gatilho específico.

Muitas vezes há confusão em torno de funções, processoes, papels e atividades. As funções são muitas vezes confundidos com processos e processos confundido com funções. Design de Serviços, Bem como sendo uma etapa do ciclo de vida de um serviço, pode ele próprio ser vista por alguns organizaçãos como um função, Por outros como um papel ou de um conjunto de processos ou como um atividade. Se é ou não é uma função, atividade, função ou conjunto de processos depende inteiramente da dimensão, estrutura e cultura de uma organização. É importante que no entanto é definida e executada dentro de uma organização, o sucesso da função, o processo, papel ou atividade é medido e melhorado continuamente.

2.3.3 Especialização e coordenação em todo o ciclo de vida Especialização e coordenação são necessários na abordagem do ciclo de vida. e controlar entre as funções e processos dentro e entre os elementos do ciclo de vida de tornar isto possível. O padrão dominante do ciclo de vida é o progresso seqüencial a partir de SS através SO-SD-ST e volta a SS por meio de CSI. Que, no entanto, não é o único padrão de acção. Cada elemento do ciclo de vida fornece pontos de e controle. A combinação de múltiplas perspectivas permite uma maior flexibilidade e controle em ambientes e situações. A abordagem do ciclo de vida imita a realidade da maioria das organizações, onde a gestão eficaz requer a utilização de múltiplas controle de perspectivas. Os responsáveis pela projeto,desenvolvimento e melhoria de processos para Serviço de Gestão de pode adotar uma perspectiva de controle baseada em processos. 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 do pensamento sistêmico. Cada

ITIL V3 - Service Design - Página:

31 de 477

perspectiva de controle pode revelar padrões que podem não ser evidentes a partir do outro.

ITIL V3 - Service Design - Página:

32 de 477

2,4 Projeto fundamentos Serviço 2.4.1 Finalidade objetivo / / objetivo O principal objectivo do Design de Serviços fase do ciclo de vida é o desenho de novos ou alterados serviços para introdução na viver ambiente. É importante que uma abordagem holística para todos os aspectos do projeto é adotado, e que ao mudar ou alterar qualquer dos elementos individuais do projeto todos os outros aspectos são considerados. Assim, ao projetar e desenvolver um novo aplicação, Isso não deve ser feito isoladamente, mas também deve considerar o impacto em todo o serviço, o sistema de gestãos e ferramentas (por exemplo, Portfólio de Serviços e Catálogo de Serviços), O arquiteturas, a tecnologia, os processos de gerenciamento de serviços e as medidas necessárias e métricos. Isso irá garantir que não só os elementos funcionais são atendidas pelo projeto, mas também de que toda a gestão e operacional requisitos são tratados como uma parte fundamental do projeto e não são adicionados como uma reflexão tardia. Uma abordagem holística deve ser adotada por todos os aspectos de serviços de design e áreas para garantir a consistência e integração em todas as atividades e processos através da tecnologia de TI inteira, fornecendo fim-a-fim funcionalidade de negócios relacionados e qualidade. Nem todos os mudar dentro de um De serviços de TI exigirá a instigação Design de Serviços atividade. Ele somente será exigida quando há mudança "significativa". Cada organização deve definir o que constitui "significativo" para que todos dentro da organização é clara quanto ao momento em atividade Design de Serviços é instigado. Portanto, todas as alterações devem ser avaliadas quanto ao seu impacto sobre as atividades de design de serviço para determinar se eles são significativos em termos de actividade que necessitam de serviço de Design. Isto deve ser parte do Gestão da Mudança impacto processo avaliação dentro do Transição de Serviço publicação de ITIL.

2.4.2 Âmbito Há cinco aspectos individuais de Design de Serviços considerados nesta publicação. Estes são o desenho de: • • • • •

Serviços novos ou modificados Serviço de Gestão de sistemas e ferramentas, em especial os Portfólio de Serviços, Incluindo o Catálogo de Serviços Tecnologia arquitetura e sistema de gestãos O processoes necessárias Métodos de medição e métricas.

ITIL V3 - Service Design - Página:

33 de 477

O Design de Serviços fase do ciclo de vida começa com um conjunto de requisitos de negócios novos ou alterados e termina com a desenvolvimento de uma solução de serviço projetado para atender as necessidades do documentados negócio. Esta solução desenvolvida, juntamente com a sua Pacote de Desenho de Serviço (SDP - ver Apêndice A), é então ado para Transição de Serviço para avaliar, construir,teste e implantar o serviço novo ou alterado. No termo destas transição actividades, controlar é transferido para o Operação de Serviço fase do ciclo de vida de serviços. As atividades envolvidas nestas fases estão descritos na seção 3. O total escopo Serviço de Design e os cinco aspectos do design e como eles interagem são ilustrados na figura 2.3.

Figura 2.3 Âmbito de Design de Serviços

O principal objetivo do Design de Serviços é o desenho de novo ou alterado serviços. Os requisitos para estes novos serviços são extraídos da Portfólio de Serviços. Cada requisito é analisada, documentada e concordou, e um projeto de solução que é produzido é então comparada com as estratégias e as restrições de Estratégia de Serviço para garantir que ele está em conformidade com corporativa e políticas de TI. Cada Service Design indivíduo também é

ITIL V3 - Service Design - Página:

34 de 477

considerada em conjunto com cada um dos outros aspectos do Desenho de Serviço: •

•

•

•

O Serviço de Gestão de sistemas e ferramentas, em especial os Carteira de serviço: para garantir que este serviço novo ou alterado é compatível com todos os outros serviços, e que todos os outros serviços que o apoio de interface, ou dependem dos serviços novos ou alterados são compatíveis com o novo serviço. Se não, ou o design do novo serviço ou outros serviços já existentes terão de ser adaptados. Também os sistemas de gerenciamento de serviços e ferramentas devem ser revistas para garantir que eles são capazes de ar o serviço novo ou alterado. A tecnologia arquiteturas e gerenciamento de sistemas: Para garantir que todas as arquiteturas de tecnologia e sistemas de gestão são consistentes com o novo serviço ou alterados e têm o capacidade para operar e manter o novo serviço. Se não, então ou as arquiteturas ou sistemas de gestão terá de ser alterada ou o design do novo serviço terá de ser revisto. Os processos: Para assegurar que os processos, papels, responsabilidades e competências têm a capacidade de operar, apoiar e manter o serviço novo ou alterado. Se não, o projeto do novo serviço terá de ser revisto ou as capacidades de processo existentes terão de ser reforçada. Isto inclui todo e TI Serviço de Gestão de processos, e não apenas a chave Design de Serviços processos. Os métodos de medição e métricos: Garantir que os métodos de medição existentes podem fornecer as métricas necessárias no serviço novo ou alterado. Se não, então os métodos de medição precisa ser melhorado ou as métricas de serviço terá de ser revisto.

Se todas as atividades acima estejam concluídas durante o Design de Serviços palco, isso irá garantir que não haverá problemas mínimos que surgem durante as fases subsequentes do Ciclo de Vida de Serviço. Portanto Design de Serviços deve consolidar as questões fundamentais de projeto e atividades de TI e todos os Serviço de Gestão de processoes dentro de suas atividades de design próprios, para garantir que todos os aspectos são considerados e incluídos dentro de todos os projetos para serviços novos ou modificados como parte do processo cotidiano operação. A capacidade de medir e demonstrar o valor para o negócio exige a capacidade de vincular negócio resultados, objetivos e seus processos subjacentes e funções para os serviços de TI e de seus ativos subjacentes, processos e funções. Este valor deve ser articulado por: •

Concordando nível de serviços, SLAs e metas de toda a empresa, garantindo a crítica processo de negócioes receber mais atenção

ITIL V3 - Service Design - Página:

35 de 477

•

•

•

•

•

Medição de TI qualidade no negócio /usuário termos, relatando o que é relevante para os usuários (por exemplo, cliente satisfação, o valor do negócio) Mapeamento de processos de negócios para Infra-estrutura de TI, Uma vez que novos componentes são adicionados continuamente, aumentando a possibilidade de interferências causadas por TI e perda de foco serviço de negócios e os processos Mapeamento de processos de negócio para as empresas e serviço medições, tornando os serviços de TI se concentrar em medidas relacionadas aos principais aspectos do negócio atuação Infra-estrutura de mapeamento recursos para os serviços, a fim de tirar pleno partido das críticas componentes de TI dentro da Gerenciamento da Configuração Sistema (CMS), que estão ligados a processos críticos de negócio. Isso também pode usar a informação completa dentro do Sistema de Gestão de Conhecimento Serviço (SGCS). Mais informações podem ser encontradas no CMS dentro do Transição de Serviço publicação Fornecer end-to-end de desempenho monitoramento e medição de processos de negócios on-line, periodicamente relatados contra SLA alvos.

Muitas vezes, o projeto de um grande serviço novo ou alterado vai exigir que o projeto mudars são considerados, e muitas vezes afectam ou que são afectadas por todos os outros quatro fases do Serviço Ciclo de Vida. É essencial, portanto, que os sistemas de TI e serviços são concebidos, planejada, implementada e gerida de forma adequada para o negócio como um todo. A exigência, então é fornecer serviços de TI que: • • • • • • •

São-business e orientada para o cliente, focado e dirigido São rentáveis e seguras São flexíveis e adaptáveis, ainda apto para o efeito no ponto de entrega Pode absorver uma demanda cada vez maior no volume e velocidade da mudança Atender às demandas de negócios crescentes para operação contínua São gerenciados e operados a um nível aceitável de risco São sensíveis, com as devidas disponibilidade adequada às necessidades de negócio.

Com todas essas pressões sobre a TI e os negócios, a tentação - e, infelizmente, a realidade em alguns casos - é 'cortar' no projeto e planejamento processos ou ignorá-los completamente. No entanto, nestas situações, as atividades de design e planejamento são ainda mais essenciais para a entrega total de qualidade serviços. Portanto, mais tempo do que menos deve ser dedicada aos processos de projeto e sua implementação.

ITIL V3 - Service Design - Página:

36 de 477

A fim de que o design, da qualidade eficaz pode ser conseguida, mesmo quando são curtos prazos e pressão para fornecer serviços é elevada, organizaçãos, deve assegurar que a importância do Desenho de Serviço função é totalmente compreendida, e que o e é fornecido para manter e amadurecer Design de Serviços como um elemento fundamental da Serviço de Gestão de. As organizações devem se esforçar continuamente para revisar e melhorar a sua Service Design capacidade, A fim de que Service Design pode tornar-se uma consistente e repetível prática, Permitindo que as organizações forneçam serviços de qualidade contra prazos desafiadores. Tendo uma prática do Design maduro serviço também permitirá que as organizações reduzam risco no transição e operacional estágios de serviço. Em geral, a chave para o sucesso da provisão De serviços de TIs é um nível adequado de projeto e planejamento para determinar qual projetos, processoes e os serviços tiverem maior impacto ou benefício para o negócio. Com o nível adequado de pensamento, design, preparação e planejamento, esforço pode ser orientada para as áreas que produzem o maior retorno. Avaliação de risco e gestão são requisitos fundamentais dentro de todas as atividades do projeto. Portanto, todos os cinco aspectos do Desenho de Serviço deve incluir a avaliação e gestão de riscos como uma parte integrada inerente de tudo o que fazem. Isso irá garantir que os riscos envolvidos na prestação de serviços e da operação de processos, tecnologia e métodos de medição estão alinhados com o risco do negócio e impacto, porque a avaliação e gestão de riscos estão embutidos em todos os processos de projeto e atividades. Muitos projetos, planos e projetos falham por falta de preparação e de gestão. A implementação de ITIL Serviço de Gestão de como uma prática é sobre como preparar e planejar o uso eficaz e eficiente dos quatro Ps: as pessoas, os processos, os produtos (serviços, a tecnologia e ferramentas) e os Parceiros (fornecedors, os fabricantes e fornecedores), como ilustrado na Figura 2.4.

Figura 2.4 O Quatro Ps

ITIL V3 - Service Design - Página:

37 de 477

No entanto, não há nenhum benefício na produção de desenhos, planos, arquiteturas e políticas e mantê-los para si mesmo. Eles devem ser publicadas, concordou, divulgado e usado ativamente. A fim de assegurar que os negócios e serviços de TI permanecem sincronizados, muitas organizações formar comitês de gerência sênior do negócio e de TI. O comitê carrega a responsabilidade geral de fixação governo, Direção, política e estratégia para serviços de TI. Muitas organizações referemse a esse grupo como a Estratégia de TI ou Grupo de Coordenação. (ISG). A função de um ISG é actuar como um parceria entre a TI eo negócio. Ele deve se reunir regularmente e analisar o negócio e as estratégias de TI, projetos, planos, Portfólio de Serviços, Arquiteturas e políticas para assegurar que eles estão alinhados uns com os outros. Deve proporcionar o visão, Definir a direção e determinar as prioridades de cada programas e projetos para garantir que a TI esteja alinhada e focada em metas empresariais e motoristas. O grupo também deve garantir que prazos irrealistas, o que poderia comprometer a qualidade ou perturbar normais requisitos operacionais, não são impostas ou tentado por qualquer negócio ou de TI. Veja a Figura 2.5. O ISG vai incluir discussões sobre todos os aspectos do negócio que envolvem serviços de TI, bem como proposta ou possível mudar num estratégico nível. Assuntos para o ISG para discutir podem incluir: •

•

•

•

• •

•

•

Revisão de negócios e planos de TI: Para identificar qualquer alteração em qualquer área que desencadeiam a necessidade de criar, aumentar ou melhorar serviços Demanda planejamento: Para identificar eventuais mudanças na demanda para ambos os horizontes de planejamento de curto e longo prazo; tais mudanças podem ser aumentos ou diminuições na demanda, e preocupação tanto de negócios como de costume e projetos Autorização do projecto e priorização: Para garantir que projetos são autorizados e priorizadas para a satisfação mútua de ambas as empresas e TI Comente de projetos: Garantir que os benefícios comerciais esperados estão sendo realizados de acordo com o projeto caso de negócios, e identificar se os projetos estão dentro do cronograma Potencial terceirização: Identificar a necessidade eo conteúdo das estratégias de sourcing para o De serviços de TI provisão Negócios / TI revisão da estratégia: Discutir mudanças importantes para a estratégia de negócios e as principais mudanças propostas para TI estratégia e tecnologia, para garantir o alinhamento contínuo Continuidade de Negócios e de TI da Continuidade do Serviço: O grupo, ou um grupo de trabalho do grupo, é responsável pelo alinhamento de Continuidade de Negócios e estratégias de TI continuidade de serviço Políticas e normas: O ISG é responsável por garantir que as políticas de TI e padrões, particularmente em relação à estratégia financeira e gestão

ITIL V3 - Service Design - Página:

38 de 477

de desempenho, Estão no lugar e alinhada com a corporativa global visão e objetivos.

Figura 2.5 O Grupo de Coordenação de TI / Estratégia

O Grupo de Coordenação de TI estabelece o rumo para as políticas e planos de empresa para operacional níveis de organização de TI e garante que eles são compatíveis com estratégias de nível empresarial. Veja a Figura 2.5. O ISG tem um importante papel a desempenhar no alinhamento dos negócios e estratégias de TI e planos como ilustrado na figura 2.5. Como pode ser visto, o Portfólio de Serviços é uma das principais fontes de entrada para o ISG no seu papel de tomada de decisão, que permite que o ISG para: • • • •

Dirigir e orientar a seleção de investimentos em áreas que produzem o maior valor de negócio e Retorno sobre Investimento Realize eficaz programa e projeto de seleção, priorização e planejamento Exercer a governança eficaz e contínuo de gestão activa do 'pipeline' de requisitos de negócios Assegurar que os benefícios de negócios projetados de programas e projetos são realizados.

ITIL V3 - Service Design - Página:

39 de 477

2.4.3 Valor para os negócios Com boa Design de Serviços, É possível entregar qualidade, O custo-benefício serviços e para assegurar que os requisitos de negócio estão sendo atendidas. O resultado seguintes benefícios de Service Design boa prática: •

• • •

•

•

• • •

Reduzido Custo Total de Propriedade (TCO):custar de propriedade só pode ser minimizado se todos os aspectos de serviços, processos e tecnologia são concebidas e implementadas corretamente contra o projeto Melhoria da qualidade de serviço: Tanto a qualidade de serviço e operacional será reforçada Melhor consistência de serviço: Como os serviços são projetados dentro da empresa estratégia,arquiteturas e constrangimentos Mais fácil implementação de serviços novos ou alterados: Como não há integrada e completa Design de Serviços e a produção de SDPs abrangentes Alinhamento melhor serviço: Envolvimento, desde a concepção do serviço, garantindo que os serviços novos ou alterados corresponder às necessidades de negócios, com serviços destinados a satisfazer Nível Requisitos de Serviço Desempenho do serviço mais eficaz: Com incorporação e reconhecimento de Disponibilidade capacidade financeira, e TI Plano de Continuidade do Serviços Melhorou TI governo: Ajudar na implementação e comunicação de um conjunto de controlars para uma governação eficaz da TI Mais eficaz Serviço de Gestão de e processos de TI:processoes será projetado com ótima qualidade e custo-eficácia Melhoria da informação e tomada de decisão: Mais abrangente e eficaz medições e métricos vai permitir a melhoria melhor tomada de decisão e contínua de Serviço de Gestão de práticas na fase de concepção do Ciclo de Vida do Serviço.

2.4.4 Otimizando o desempenho do projeto A otimização de projeto atividades requer a implementação de processos documentados, juntamente com uma imperiosa sistema de gestão da qualidade (Tais como ISO 9001) Para sua medição contínua e aperfeiçoamento. É importante que, ao considerar a melhoria e otimização do Design de Serviços atividades, o impacto das atividades em todos os estágios do ciclo de vida deve ser medida e não apenas o impacto na fase de concepção. Portanto medições de serviços de design e métricas deve olhar para a quantidade de retrabalho atividade e atividades de melhoria que é necessário em transição,operação e melhoria atividades como resultado de deficiências na concepção de soluções

ITIL V3 - Service Design - Página:

40 de 477

de serviços novos e modificados. Mais informações sobre a medição de Design de Serviços pode ser encontrado na seção 8.5.

2.4.5 Processos dentro de Design de Serviços Esta detalhes publicação processos necessários na fase de projeto do Ciclo de Vida de Serviço. Esses processos não pode ser considerado isoladamente, como o seu verdadeiro valor só será realizado quando as interfaces entre os processos são identificadas e acionadas. Os seguintes processos são detalhadas neste documento: •

•

•

•

•

•

•

Gerenciamento de Catálogo de Serviço: Para garantir que uma Catálogo de Serviços é produzido e mantido, contendo informação precisa sobre todos operacional serviços e aqueles que estão sendo preparados para ser executado operacionalmente Gerenciamento de Nível de Serviço: Negocia, concorda e documentos apropriados De serviços de TI alvos com representantes da negócioE, em seguida, monitora e produz relatórios sobre a provedor de serviçosCapacidade 's para fornecer o nível de serviço acordado Gerenciamento da Capacidade: Garantir que custo justificável de TI capacidade em todas as áreas de TI sempre existe e é adaptado às necessidades atuais e futuras acordadas do negócio, em tempo hábil Gerenciamento de Disponibilidade: Para assegurar que o nível de serviço disponibilidade entregues em todos os serviços é correspondente a, ou exceder as necessidades atuais e futuras acordadas do negócio, de uma maneira custo-efetiva Gerenciamento da Continuidade do Serviço: Garantir que as instalações de TI necessários técnicos e de serviços (incluindo sistemas de computadores, redes, aplicaçãos, repositórios de dados, telecomunicações, ambiente,e técnico e Service Desk) pode ser retomada dentro necessário e acordado, negócios prazos Gestão de Segurança da Informação: Para alinhar a TI com os negócios de segurança segurançaE garantir que a segurança da informação é gerido de forma eficaz em todos os serviços e Serviço de Gestão de atividades Gestão de Fornecedores: Gerir fornecedors e os serviços que eles fornecem, para oferecer perfeita qualidade de serviço de TI ao negócio, garantindo valor para o dinheiro é obtido.

Estes são apenas alguns dos processoes descritas no ITIL Serviço de Gestão de orientação prática. Todos os processos no Serviço de Gestão de ciclo de vida deve ser ligado em conjunto para gerenciar, projetar, e e manutenção dos serviços, Infra-estrutura de TI, Meio ambiente, aplicações e dados. Outros processos são descritos em detalhe em outras publicações na biblioteca ITIL Service Management núcleo práticas. As interfaces entre todos os processos e todos os outros processos devem ser claramente definidas na concepção de um

ITIL V3 - Service Design - Página:

41 de 477

serviço ou melhoria ou implementação de um processo. Estas interfaces são descritas em detalhe na secção 4 e incluem não apenas as interfaces para cada um dos Design de Serviços processos, mas também interfaces para processos dentro de outras etapas do ciclo de vida. Ao projetar um serviço ou um processo, é imperativo que todos os papels estão claramente definidos. A marca de de alto desempenho organizaçãos é a capacidade de tomar as decisões certas rapidamente e executá-los rapidamente. Se a decisão envolve estratégico escolha ou uma operação crítica, ser claro sobre quem tem de entrada, quem decide e quem toma a ação vai permitir que a organização para avançar rapidamente.

ITIL V3 - Service Design - Página:

42 de 477

3 Projeto princípios do serviço Veja primeiro que o projeto é sábio e justo: aquele apurado, persegui-lo resolutamente, não para uma repulsa renunciar a finalidade que você resolveu para o efeito. William Shakespeare (1564-1616) O erro comum que as pessoas cometem ao tentar projetar algo completamente à prova de falhas é subestimar a ingenuidade dos tolos completos. Douglas Adams

TI Design de Serviços é uma parte do processo geral de mudança negócio. Este processo de mudança de negócios eo papel de TI são ilustrados na figura 3.1.

Figura 3.1 O processo de mudança de negócios

Uma vez que as informações exactas tenha sido obtido com o que é necessário e assinado, no que diz respeito às necessidades modificadas do negócio, O plano para a prestação de um serviço para atender a necessidade concordou pode ser desenvolvida. O papel do estágio de Design de Serviços dentro desta mudança global de negócios processo pode ser definida como: 'A projeto de adequada e inovadora De serviços de TIs, incluindo as suas arquiteturas, processos, políticas e documentação, para atender às atuais e futuros requisitos de negócios acordados. " É importante que as interfaces corretas e links para as atividades de design existem. Ao projetar serviços novos ou modificados, é vital que todo o ciclo de vida de serviço e processos de ITSM estão envolvidos desde o início. Muitas vezes ocorrem dificuldades em operações quando um serviço recém-projetado é entregue para executar ao vivo no último minuto. A seguir, são ações que precisam ser realizadas a partir do início de um Design de Serviços para assegurar que a solução cumpre os requisitos da empresa:

ITIL V3 - Service Design - Página:

43 de 477

•

• •

• •

• • •

A solução de serviço novo deve ser adicionado ao total Portfólio de Serviços desde a fase de conceito, e da Carteira de serviço deve ser atualizado para refletir a atual estado através de qualquer incremental ou iterativa desenvolvimento. Isto será benéfico não só do ponto de vista financeiro, mas também de todas as outras áreas durante o projeto. Como parte do primeiro serviço/ Sistema de análise, haverá uma necessidade de compreender o Nível Requisitos de Serviço (SLR) para o serviço quando ele vai viver. A partir das SLRs, o Gerenciamento da Capacidade equipe pode modelar este dentro da infra-estrutura atual para determinar se este será capaz de ar o novo serviço. Se o tempo permitir, os resultados do modelagem actividades podem ser incorporadas ao Plano de capacidade. Se nova infra-estrutura é necessária para o novo serviço, ou de e estendido, Gestão Financeira terá que ser envolvidos para definir o orçamento. Uma primeira Análise de Impacto no Negócio e avaliação de risco deve ser realizado em serviços bem antes da implementação como entrada de valor inestimável em Estratégia de TI da Continuidade do Serviço, Design Disponibilidade e Planejamento de Capacidade. O Service Desk terá de tomar conhecimento de novos serviços com antecedência de ao vivo operação para preparar e treinar a equipe de Service Desk e potencialmente equipe de TI do cliente. Transição de Serviço pode começar planejamento a implementação e construir no cronograma de mudança. Gestão de Fornecedores terá de ser envolvido se de concurso é necessário para o novo serviço.

A composição de um serviço e as suas partes constituintes é ilustrado na Figura 3.2.

ITIL V3 - Service Design - Página:

44 de 477

Figura 3.2 A composição de serviços

Design de Serviços deve considerar todos esses aspectos na concepção de soluções de serviços para atender às necessidades de negócios novos e em desenvolvimento: • • • • • • • •

Processo de negócio: Definir as necessidades funcionais do serviço a ser prestado, por exemplo, televendas, faturamento, pedidos, verificação de crédito Serviço: O próprio serviço que está sendo entregue ao clientes e de negócios pela provedor de serviços, E.g. e-mail de cobrança, SLAs / SLRs: Os documentos acordados com os clientes que especificam o nível, escopo e qualidade de serviço a ser prestado Infra-estrutura: Todos os equipamentos de TI necessárias para a entrega do serviço para os clientes e usuários, incluindo servidors, circuitos de rede, switches, computadores, telefones Ambiente: O ambiente necessário para proteger e operar a infra-estrutura, por exemplo, centros de dados, energia, ar condicionado Dados: Os dados necessários para apoiar o serviço e fornecer as informações requeridas pelos processos de negócios, por exemplo, cliente registros, contas contábeis Aplicaçãos: Todos os aplicativos de software necessários para manipular os dados e fornecer os requisitos funcionais dos processos de negócios, por exemplo, ERM, Financeiro, CRM Serviços de e: Todos os serviços que são necessários para apoiar a operação do serviço prestado, por exemplo, um serviço compartilhado, um serviço de rede gerenciada

ITIL V3 - Service Design - Página:

45 de 477

• • •

Acordo de Nível Operacionals (ANO) e contratos: Qualquer fundamento acordos necessários para libertar a qualidade do serviço acordado no SLA Equipas de Apoio: Quaisquer equipes internas de apoio que fornecem segunda e terceira linha de apoio para qualquer um dos componentes necessários para prestar o serviço, por exemplo, Unix, mainframe, redes Fornecedors: Quaisquer partes externas terceiros necessários para proporcionar e de terceira e quarta linha para qualquer um dos componentes necessários para fornecer o serviço, por exemplo, redes, hardware, software.

O projeto actividades não deve considerar apenas cada um dos componentes acima isoladamente, mas também deve considerar o relaçãos entre cada um dos componentes e suas interações e dependências em quaisquer outros componentes e serviços, a fim de fornecer uma solução eficaz e abrangente, que atenda as necessidades do negócio.

ITIL V3 - Service Design - Página:

46 de 477

3,1 Metas Os principais objetivos e objetivos de Design de Serviços são os seguintes: •

•

•

• • • • •

• •

Serviços de design para satisfazer objetivo de negócios, com base na qualidade de conformidade, risco e segurança requisitos, fornecendo mais eficaz e eficiente de TI e soluções de negócios e serviços alinhados às necessidades do negócio, coordenando todas as atividades de projeto para De serviços de TIs para garantir consistência e foco de negócios Serviços de design que podem ser facilmente e eficientemente desenvolvidos e melhorados dentro de prazos adequados e custars, e, sempre que possível, reduzir, minimizar ou restringir os custos de longo prazo de prestação de serviços O design eficiente e eficaz processoes para a concepção, transição, Operação e melhoria dos serviços de alta qualidade, juntamente com as ferramentas de apoio, sistemas e informações, especialmente os Portfólio de Serviços, Para gerenciar os serviços através de seu ciclo de vida Identificar e gerenciar os riscos, para que possam ser eliminados ou reduzidos antes que os serviços vão viver Design seguro e resistente Infra-estrutura de TIs, ambientes aplicaçãos e os dados / informações recursos e capacidade que atendam as necessidades atuais e futuras do negócio e os clientes Projeto métodos de medição e métricos para avaliar a eficácia e eficiência dos processos de projeto e de seus entregas Produzir e manter planos de TI, processos, políticas, arquiteturas, quadros e documentos para o projeto de qualidade Soluções de TI, para atender as necessidades atuais e futuras de negócios acordados Auxiliar na desenvolvimento de políticas e normas em todas as áreas de concepção e planeamento de serviços de TI e processos, recebendo e atuando no sobre os processos de design de todas as outras áreas e incorporando as ações em um processo contínuo de melhoria Desenvolver as habilidades e capacidade dentro de TI, movendo estratégia e atividades de projeto em operacional tarefas, fazendo uso eficaz e eficiente de todos os recursos de serviços de TI Contribuam para a melhoria da qualidade global do serviço de TI, dentro das limitações impostas pelo projecto, especialmente através da redução da necessidade de refazer e melhorar serviços, uma vez que têm sido implementadas no ambiente ao vivo.

ITIL V3 - Service Design - Página:

47 de 477

3,2 projeto equilibrado Para quaisquer novos requisitos de negócios, o projeto de serviços é um ato de equilíbrio delicado, garantindo que não só os requisitos funcionais, mas também a atuação metas sejam atingidas. Tudo isso precisa ser equilibrado no que diz respeito aos recursos disponíveis dentro do prazo exigido e custars para os novos serviços. Jim McCarthy, autor de Dinâmica de Desenvolvimento de Software, Afirma: "Como um gerente de desenvolvimento, você está trabalhando com apenas três coisas": • • •

Funcionalidade: O serviço ou produto e suas instalações, funcionalidade e qualidade, Incluindo todas as funcionalidades de gestão e operacional necessária Recursos: As pessoas, tecnologia e dinheiro disponível Programar: Os prazos.

Estes são apresentados na Figura 3.3.

ITIL V3 - Service Design - Página:

48 de 477

Figura 3.3 Elementos do projeto em uma relação triangular

Este conceito é muito importante para Design de Serviços actividades e para o equilíbrio entre o esforço que é gasto no projeto, desenvolvimento e prestação de serviços em resposta às exigências do negócio. Design de Serviços é um ato de equilíbrio delicado dos três elementos eo ajuste constante dinâmica de todos os três para atender as necessidades de negócio. Alterando um lado do triângulo, invariavelmente tem um impacto sobre, pelo menos, um dos outros lados, se não ambos. É vital, por conseguinte, que os condutores de negócios e necessidades são completamente compreendidos, de modo que as soluções comerciais mais eficazes são concebidos e entregues, utilizando o equilíbrio mais adequado destes três elementos. É provável que os motoristas de negócio e as necessidades vão mudar durante o projeto e entrega, devido a pressões do mercado. A funcionalidade e os recursos devem ser considerados para todas as

ITIL V3 - Service Design - Página:

49 de 477

fases do ciclo de vida de serviço, para que os serviços não são apenas concebido e desenvolvido de forma eficaz e eficiente, mas que a eficácia e eficiência do serviço é mantida ao longo de todas as fases da sua ciclo de vida. A devida atenção deve ser dada dentro de Design de Serviços em todas as fases subseqüentes dentro do Ciclo de Vida do Serviço. Muitas vezes, os designers e arquitetos considerar apenas o desenvolvimento de um novo serviço até o tempo de execução do serviço para o viver ambiente. Uma abordagem holística para a concepção de serviços de TI devem ser adotadas para garantir que uma solução totalmente integrada e abrangente foi projetado para atender os requisitos acordados para a negócio. Esta abordagem deve também garantir que todos os mecanismos necessários e funcionalidades são implementadas dentro do novo serviço, para que possa ser gerido de forma eficaz e melhorado ao longo de sua vida operacional para atingir todas as suas metas de serviço acordados. Uma abordagem formal, estruturada devem ser adotadas para garantir que todos os aspectos do serviço são abordados e garantir a sua introdução suave e operação dentro do ambiente ao vivo. O mais eficaz Provedor de serviços de TIs integrar todos os aspectos de design de cinco, em vez de projetá-los em isolamento. Isto assegura que uma arquitetura empresarial integrado é produzido, consistindo de um conjunto de padrões, desenhos e arquiteturas que satisfazem todos da gestão e operacional necessidades dos serviços, bem como a funcionalidade exigida pelo negócio. Este projeto integrado garante que, quando um serviço novo ou alterado é implementado, ele não só fornece a funcionalidade exigida pelo negócio, mas também atende e continua a satisfazer todas as suas nível de serviços e metas em todas as áreas. Isso garante que nenhuma fraqueza (ou mínimo absoluto) terá de ser abordado de forma retrospectiva. A fim de conseguir isso, a gestão global dessas atividades de projeto deve garantir: • • • •

Boa comunicação entre as atividades de design diferentes e todas as outras partes, incluindo o negócio e TI planejadores e estrategistas O mais recente versãos de todos os negócios e de TI apropriada planos e estratégias estão disponíveis para todos os designers Todos os documentos de arquitetura e documentos do projeto são consistentes com todos os negócios e políticas de TI e planos O arquiteturas e desenhos: o São flexíveis e permitem que a TI responder rapidamente às necessidades de novos negócios o Integrar-se com todas as estratégias e políticas o Apoiar as necessidades de outras etapas do ciclo de vida de serviço o Facilitar os serviços de qualidade novos ou alterados e soluções, alinhados com as necessidades e prazos do negócio.

ITIL V3 - Service Design - Página:

50 de 477

3,3 Identificar necessidades de serviço Design de Serviços deve considerar todos os elementos do serviço, tendo uma abordagem holística para o projeto de um novo serviço. Esta abordagem deve considerar o serviço e seu constituinte componentes e suas inter-relações, garantindo que os serviços prestados atender a funcionalidade e qualidade de serviço esperada pela empresa em todas as áreas: • • • • • • • • •

O escalabilidade do serviço para satisfazer os requisitos futuros, em apoio a longo prazo objetivo de negócios O processo de negócioes e unidade de negócioss ados pelo serviço O De serviços de TI ea funcionalidade de negócios e requisitos acordados O serviço em si e sua Exigência de Nível de Serviço (SLR) ou Acordo de Nível de Serviço (SLA) Os componentes de tecnologia utilizados para implementar e entregar o serviço, incluindo a infra-estrutura, o ambiente, os dados e os aplicaçãos O internamente ado serviços e componentes e suas associadas Acordo de Nível Operacionals (ANO) Os serviços de apoio externo e componentes e de seus associados subjacente contratos, o que, muitas vezes, têm a sua própria relacionada acordos e / ou horários O atuação medições e métricos exigido O legislado ou exigido segurança níveis.

O relaçãos e dependências entre esses elementos encontram-se ilustrados na Figura 3.4.

ITIL V3 - Service Design - Página:

51 de 477

Figura 3.4 A relação de serviço e dependências

Nenhum serviço pode ser concebido, transição e operado de forma isolada. A relação de cada serviço ao seu apoio componentes e os serviços devem ser claramente compreendida e reconhecida por todas as pessoas dentro da provedor de serviços organização. Também é essencial que todas as metas contidas dentro de apoio acordos, tais como e OLAs contratos, sustentam os acordados entre o provedor de serviços e os seus clientes. Alguns desses conceitos são discutidos em mais detalhe nas secções posteriores da publicação, no que diz respeito aos aspectos individuais da Design de Serviços. No entanto, quando um aspecto individual de um serviço é alterada, todas as outras áreas do serviço também deve ser considerada para assegurar que as alterações necessárias para ar o mudar estão incluídas na concepção global. Cada vez mais, os serviços são complexos e são fornecidos por um número de sócio ou fornecedor organizações. Onde múltiplos provedor de serviçoss estão envolvidos na prestação de um serviço, é vital que uma central Design de Serviços autoridade é estabelecida, para garantir serviços e processoes estão totalmente integradas em todas as partes. Dentro da área específica de tecnologia há quatro domínios tecnológicos distintos que precisam ser resolvidas, como são as componentes de apoio de todos os serviços e contribuir para o seu desempenho global: •

• • •

Infra-estrutura: A gestão e controlar de todos os elementos de infraestrutura, incluindo mainframes, servidors, equipamentos de rede, sistemas de banco de dados, redes de área de armazenamento (SANs), network-attached storage (NAS), software de sistemas, serviços públicos, apoio sistemas, firewalls, desenvolvimento e teste ambientes, ferramentas de gestão, etc Ambiental: A gestão e controlo de todos os aspectos ambientais de todas as salas de equipamentos principais, incluindo o espaço físico e disposição, energia, ar condicionado, cabeamento, física segurança, Etc Dados: A gestão e controlo de todos os dados e informações e de o associado, incluindo dados de teste, quando aplicável Aplicaçãos: A gestão e controlo de todos os softwares aplicativos, incluindo tanto comprados em aplicativos e em casa desenvolvido aplicações de software.

ITIL V3 - Service Design - Página:

52 de 477

3,4 Identificar e documentar os requisitos de negócios e motoristas TI deve manter informações precisas sobre os requisitos de negócios e motoristas se é para fornecer o catálogo mais adequada de serviços com um nível aceitável de serviço qualidade que está alinhada às necessidades do negócio. Drivers de negócio são as pessoas, informações e tarefas que am o cumprimento dos objetivos do negócio. Isto requer que a TI desenvolve e mantém relações estreitas, regular e adequada e troca de informações, a fim de compreender o operacional,tático e estratégico requisitos da negócio. Esta informação deve ser obtida e concordou em duas áreas principais para manter o alinhamento do serviço: •

•

Informações sobre os serviços existentes - Que mudanças serão necessárias aos serviços já existentes no que diz respeito a: o Novas instalações e requisitos de funcionalidade o Mudanças nas processo de negócioes, as dependências, as prioridades criticidade, e impacto o Mudanças nos volumes de serviço transaçãos o Aumento nível de serviços e meta de nível de serviços devido a motorista de novos negócios, ou reduzido para serviços de idade, reduzindo a prioridade para aqueles devido a substituição o Necessidades adicionais de Serviço de Gestão de informação. o Informações sobre as exigências de novos serviços: o Instalações e funcionalidades necessários o Gestão da informação necessidades requeridas e gestão o Processos de negócio ados, as dependências, as prioridades criticidade e impacto o Os ciclos de negócios e variações sazonais o Nível de exigências de serviço e meta de nível de serviços o Negócio transação níveis, os níveis de transações de serviços, números e tipos de usuários e crescimento futuro antecipado o Justificativa de negócios, incluindo a financeira e estratégico aspectos o Nível previsto de mudar, E.g. requisitos futuros conhecidos de negócios ou de melhoria o Nível de negócios capacidade ou o apoio a conceder, por exemplo, apoio às empresas com base local.

Esta recolha de informação é o primeiro o eo mais importante para a concepção e oferta de novos serviços ou grandes mudanças para os serviços existentes. A necessidade de informações precisas e representante da negócio é primordial. Isso deve ser acordado e assinado com altos representantes dentro da empresa. Se a informação incorreta ou enganosa é obtido e utilizado nesta fase, então todas as fases subsequentes será a prestação de serviços que não

ITIL V3 - Service Design - Página:

53 de 477

correspondem às necessidades do negócio. Além disso, tem de haver alguma formais processo para o acordo ea aceitação de mudanças nos requisitos de negócio, uma vez que estes, muitas vezes, mudar e evoluir durante o Ciclo de Vida de Serviço. Os requisitos e as projeto deve evoluir com o negócio em mudança ambiente para assegurar que as expectativas de negócios são cumpridos. No entanto, este processo deve ser cuidadosamente controlados para assegurar que a taxa de modificação é mantido a um nível combinado e manejável, e não "pântano" e excessivamente atrasar o projeto à sua execução. A fim de projetar e entregar De serviços de TIs que atendam as necessidades dos clientes e do negócio, clara, concisa, sem ambiguidades especificaçãos dos requisitos devem ser documentados e acordados. O tempo gasto nessas atividades vai evitar problemas e discussão de surgir mais tarde em relação ao variaçãos do cliente e expectativa de negócios. Esse negócio de estágio requisitos deve ser composto de: • • • •

• •

•

Nomeação de um gerente de projeto, a criação de uma equipa de projecto e do contrato de projeto governo pela aplicação de uma metodologia de projeto formal, estruturado Identificação de todas as partes interessadas, incluindo a documentação de todos os requisitos de todas as partes interessadas e das partes interessadas benefícios que irá obter com a implementação Análise de requisitos, priorização de acordo, e documentação Determinação e acordo de esboço orçamentos e benefícios comerciais. O orçamento deve ser cometido pela istração, porque é normal prática para decidir orçamento do próximo ano, no último trimestre do ano anterior, portanto, quaisquer planos devem ser apresentados dentro deste ciclo A resolução do conflito potencial entre unidade de negócioss e acordo sobre os requisitos corporativos Registe-off processos para os requisitos acordados e um método para concordar e aceitar mudanças nos requisitos acordados. Muitas vezes, o processo de desenvolvimento de requisitos é um processo iterativo ou abordagem incremental que precisa ser cuidadosamente controlada de gerir "escopo rastejar ' Desenvolvimento de um compromisso com o cliente plano, Delineando a principal relaçãos entre a TI e os negócio e como essas relações e comunicação necessárias para maior das partes interessadass serão gerenciados.

Quando os requisitos de serviço estão em causa, às vezes eles vêm com uma etiqueta de preço (que pode não ser totalmente conhecido nesta fase), então não precisa sempre de haver um equilíbrio entre a serviço alcançável eo custar. Isso pode significar que alguns requisitos pode ser demasiado caro para incluir e pode ter que ser descartado durante o exercício avaliação envolvido na projeto processo. Se isso for necessário, todas as decisões de omitir quaisquer

ITIL V3 - Service Design - Página:

54 de 477

requisitos de serviço a partir da concepção do serviço deve ser documentado e acordado com os representantes das empresas. Há muitas vezes uma dificuldade quando o que a empresa quer eo orçamento alocados para a solução não levam em conta os custos de serviço completo, incluindo os custos em curso

ITIL V3 - Service Design - Página:

55 de 477

3,5 As atividades de projeto Todas as atividades do projeto são acionados por mudars em necessidades de negócio ou melhorias de serviços. Uma abordagem estruturada e holística para as atividades de projeto devem ser adoptadas, de modo que toda a informação disponível é considerado para garantir consistência e integração é alcançada ao longo do Provedor de serviços de TI organização, Em todas as atividades do projeto. Arquiteturas e os projetos devem ser mantidos, clara, concisa, simples e relevante. Com muita freqüência, os projetos e arquiteturas são complexas e teórico e não se relacionam com o "mundo real". O principal problema hoje é que as organizações geralmente se concentrar apenas nos requisitos funcionais. Um projeto ou arquitetura, por definição, tem de considerar todos os aspectos do projeto. Não é uma organização menor que combina esses aspectos, é sensata. O projeto atividades de processos são: • • • • • • • •

Requisitos coleta, análise e engenharia para assegurar que os requisitos de negócio são claramente documentados e acordados Design de serviços adequados, tecnologia, processomedição da informação es, e processo para atender aos requisitos de negócios Comente e revisão de todos os processos e documentos envolvidos na Design de Serviços, Incluindo desenhos, planos, arquiteturae as políticas Ligação com todo o projeto e outros planejamento atividades e funções, por exemplo, projeto de solução Produção e manutenção de políticas de TI e documentos de projeto, incluindo desenhos, planos, arquiteturas e políticas Revisão de todos os documentos de projeto e planejamento para a desenvolvimento e implementação de estratégias de TI usando 'roteiros', programas e planos de projeto Avaliação de risco e gestão de todos os processos de concepção e entregas Garantindo o alinhamento com todos corporativa e estratégias de TI e políticas.

As entradas para as atividades de design diferentes são: • •

Corporativo visãos, as estratégias, objetivos, políticas e planos, visões de negócios, estratégias, objectivos e planos, incluindo Plano de Continuidade de Negócioss (SBDC) Condicionalismos e exigências para a conformidade com as normas e regulamentos legislados

ITIL V3 - Service Design - Página:

56 de 477

•

•

Estratégias de TI e estratégico (a partir de documentos Estratégia de Serviço): o Todas as estratégias de TI, políticas e planos estratégicos o Detalhes de requisitos de negócio o Todas as restrições, financeiras orçamentos e os planos o O Portfólio de Serviços o Serviço de Gestão de visãos, estratégias, políticas, objetivos e planos o TI e Serviço de Gestão de processoes, os riscos e as questões registra o Transição de Serviço planos (de Mudança, Configuração e Release e Planos de Gestão de implantação) o Segurança políticas, manuais e planos o A aquisição e contrato política,fornecedor estratégia e Gestão de Fornecedores processos o O conhecimento pessoal atual, habilidades e capacidade o TI planos de negócios, planos de negócios e de TI de qualidade e políticas o Serviço de Gestão de planos, incluindo Gerenciamento de Nível de Serviço Planos, SLAs e SLRs, Plano de Melhoria de Serviço (SIP), Plano de capacidades, Plano de disponibilidades, TI Plano de Continuidade do Serviços Ferramentas de medição e técnicas

Os resultados das atividades do projeto são: • •

• • • • • • •

Revisões sugeridas para as estratégias de TI e políticas Projetos, planos e revistas de tecnologia e gestão arquiteturas, incluindo: o O Infra-estrutura de TI e gestão de infra-estrutura e meio ambiente estratégia, Desenhos, planos, arquiteturas e políticas o O aplicaçãos estratégias e dados, desenhos, planos, arquiteturas e políticas Projetos para serviços novos ou modificados, processos e tecnologias Processo de relatórios de avaliação e análise, com processos revistos e melhorados e procedimentos Revistos os métodos de medição e processoes Níveis gerenciados de riscoRelatórios, de risco e de avaliação e gestão Casos de negócios e estudos de viabilidade, com as declarações de Requisitos (Sors) e concursos (ITTs) Comentários e opiniões sobre todos os outros planos Benefício do negócio e realização revers e relatórios.

ITIL V3 - Service Design - Página:

57 de 477

3,6 aspectos de design Uma abordagem global e integrada deve ser adotado para as atividades de projeto documentados na seção anterior e deve cobrir o projeto de: • •

• • •

Serviço As soluções, incluindo todos os requisitos funcionais, recursos e as capacidades necessárias e acordadas Serviço de Gestão de sistemas e ferramentas, em especial os Portfólio de Serviços para a gestão e controlar de serviços por meio de sua ciclo de vida Tecnologia arquiteturas e gestão arquiteturas e ferramentas necessárias para prestar os serviços Processos necessários para projetar, transição,operar e melhorar os serviços Sistemas de medição, métodos e métricos para os serviços, as arquitecturas e seus constituintes componentes e os processos.

O aspecto fundamental é a concepção de soluções de serviços novos ou alterados para atender às necessidades empresariais em constante mudança. Cada vez que uma solução de serviço novo é produzido, ele tem de ser verificado em relação a cada um dos outros aspectos para garantir que ela irá integrar e interface com todos os outros serviços já existentes. Estes cinco aspectos da Design de Serviços são abordados com mais detalhes nas seções seguintes. Os planos produzidos por Design de Serviços para o projeto, transição e subsequente operação destes cinco diferentes aspectos devem incluir: • • • •

•

• • •

A abordagem adoptada e os prazos associados O organizacional impacto da nova solução ou alterados em ambos os negócio e TI O impacto comercial da solução no organização, Incluindo o financiamento, custars e orçamentos exigido O impacto técnico da solução e do pessoal ea sua papels, responsabilidades, competências, conhecimentos, formação e competências necessárias para implantar, operar, manter e otimizar a nova solução para o negócio A justificativa comercial avaliação do impacto da solução em negócios existentes - este impacto deve ser avaliado a partir do ponto de vista de TI e Serviço de Gestão de os processos, incluindo tanto a sua capacidade e atuação A avaliação e mitigação de riscos para os serviços, processoes e Serviço de Gestão de atividades Comunicação planejamento e todos os aspectos de comunicação com todas as partes interessadas O impacto da solução em novos ou existentes contratos ou acordos

ITIL V3 - Service Design - Página:

58 de 477

•

•

•

O esperado resultados da operação do serviço novo ou alterado em termos mensuráveis, geralmente expressa em novo ou existente Contratos de Nível de Serviço (SLAs), nível de serviços e satisfação do cliente A produção de um Pacote de Desenho de Serviço (Ver Apêndice A) contendo tudo necessário para a subsequente introdução de testes e funcionamento da solução ou serviço A produção de um conjunto de Critérios de aceitação de serviços (SAC) (ver o Apêndice B), que irá ser utilizado para assegurar que o provedor de serviços está pronto para entregar e ar o novo serviço ou alterados na viver ambiente.

3.6.1 Projetando serviço de soluções Há muitas atividades que devem ser concluídas dentro do Design de Serviços palco para um serviço novo ou alterado. Uma abordagem formal e estruturada é necessário para produzir o novo serviço à direita custar, Funcionalidade, qualidade e dentro do tempo certo. Este processo e suas fases constituintes encontram-se ilustrados na figura 3.5, em conjunto com as outras áreas importantes, que terão de ser envolvido dentro do processo. Este processo deve ser iterativo / incremental para garantir que o serviço prestado atende às necessidades em constante evolução e mudança do negócio durante o processo de negócio desenvolvimento e do ciclo de vida dos serviços de TI. Gerentes de projeto e equipes de projeto adicionais podem precisar de ser alocado para gerenciar os estágios dentro do ciclo de vida para o desenvolvimento do novo serviço. O papel da equipa de projecto no âmbito desta atividade de fornecimento de novo e mudando De serviços de TIs para o negócio e seu relação conceber actividades é ilustrada na Figura 3.5.

ITIL V3 - Service Design - Página:

59 de 477

Figura 3.5 Alinhar novos serviços aos requisitos de negócios

Figura 3.5 mostra o ciclo de vida de um serviço do negócio inicial ou alterados exigência através da projeto,transição e operação as fases do ciclo de vida. É importante que haja efetiva transferência de conhecimento em todas as fases entre o operacional pessoal e da equipe do projeto para garantir a progressão suave através de cada uma das etapas ilustradas. As áreas que precisam ser considerados no projeto da solução de serviço deve incluir: • •

•

Analisar os requisitos de negócio acordados Reveja os existentes serviços de TI e infra-estrutura e produção de soluções de serviços alternativos, com vista a re-utilização ou exploração existentes componentes e serviços, sempre que possível Projetar as soluções de serviços para os novos requisitos, incluindo os seus componentes constituintes, em termos de procedimentos e documentar este projeto: • As instalações e funcionalidade necessária, e as informações necessárias para o monitoramento do atuação do serviço ou processo • O processo de negócioes apoiado, as dependências, as prioridades, criticidade e impacto do serviço, juntamente com os benefícios de negócios que serão entregues pelo serviço

ITIL V3 - Service Design - Página:

60 de 477

•

•

• • •

• •

• •

Os ciclos de negócios e variações sazonais, e os negócios relacionados transação níveis, os níveis de serviços de transação, os números e tipos de usuários e crescimento futuro esperado, e os requisitos de continuidade de negócios • Nível Requisitos de Serviço e meta de nível de serviços ea medição do serviço necessário, relatar e analisar as atividades • Os prazos envolvidos e os resultados planejados a partir do novo serviço e do impacto sobre os serviços existentes • Os requisitos para o ensaio, incluindo qualquer Usuário Teste de aceitação (UAT) e as responsabilidades para a gestão dos resultados dos testes Certifique-se de que o conteúdo do Critérios de aceitação de serviços (SAC) são incorporadas e as conquistas necessários planejado no projeto inicial Avaliar e custam projetos alternativos, destacando vantagens, bem como desvantagens das alternativas Concordo as despesas e orçamentos Re-avaliar e confirmar os benefícios do negócio, incluindo a Retorno sobre Investimento (ROI) de o serviço, incluindo a identificação e quantificação de todos os custos de serviços e todos os benefícios de negócios e aumento de receitas. O custars deve cobrir o Custo Total de Propriedade (TCO) do serviço e incluem custos de arranque, tais como os custos do projeto, transição custos, o orçamento do projeto, e todos em curso custo operacionals, incluindo e, gestão e manutenção Concordam que a solução preferida e os seus resultados e metas planejadas (Exigência de Nível de Serviço (SLR)) Verifique a solução está em equilíbrio com todos corporativa e de TI estratégias, políticas, planos e documentos arquitetônicos. Se não, rever solução ou a estratégico documentação (tomando em consideração o efeito sobre outros estratégico documentos, serviços e componentes), sempre que possível re-uso ou exploração de componentes existentes (por exemplo, objectos de software, 'corporate dados, hardware), a menos que o estratégia indique o contrário. A mudança de estratégia envolverá uma quantidade significativa de trabalho e que ser feita em conjunto com Estratégia de Serviço Garantir que todos os corporativa apropriada e TI governo e segurança controlars são incluídos com a solução de Conclua prontidão organizacional de TI ' avaliação"Para garantir que o serviço possa ser efetivamente utilizado para atingir os seus objectivos acordados e que o organização tem o apropriado capacidade para entregar ao nível acordado. Isto incluirá: • O impacto comercial sobre a organização de um negócio e tanto perspectiva de TI, incluindo todos os benefícios comerciais e toda a custars (os custos de um projeto-off em curso e os custos de operação anual) envolvidos na projeto,desenvolvimento e em curso operação e apoio do serviço

ITIL V3 - Service Design - Página:

61 de 477

•

• •

Avaliação e mitigação dos riscos associados com o serviço novo ou alterado, particularmente em relação à operação, segurança,disponibilidade e da continuidade do serviço • A capacidade empresarial e maturidade. Este atividade deve ser realizado pela negócio -se a assegurar que toda a direita processoes estrutura, pessoas, papels, as responsabilidades e as instalações estão no local para operar o novo serviço • A capacidade de TI e maturidade: • O ambiente e todas as áreas de tecnologia, tendo considerado o impacto em componentes existentes de infraestrutura e serviços existentes • A estrutura organizacional da TI e os papéis e responsabilidades • Os processos de TI e sua documentação • O habilidades, conhecimento e competência do pessoal • Os processos de gerenciamento e ferramentas de apoio O fornecedor e apoiar acordos necessários para manter e fornecer o serviço A montagem de um Pacote de Desenho de Serviço (SDP) para a subsequente transição, Operação e melhoria da solução de serviço novo ou alterado.

3.6.2 Projetando sistemas de apoio, especialmente o portfólio de serviços A maneira mais eficaz de gerenciar todos os aspectos dos serviços por meio de sua ciclo de vida é usando apropriada sistema de gestãos e ferramentas para apoiar e automatizar processos eficientes. O Portfólio de Serviços é o sistema de gestão mais crítico usado para apoiar todos os processos e descreve um provedor do serviços em termos de valor de negócio. Ele articula as necessidades do negócio ea resposta do provedor para essas necessidades. Por definição, termos de valor de negócios correspondem aos termos de mercado, fornecendo um meio para comparar a competitividade serviço através de prestadores alternativos. Ao agir como a base de uma decisão-quadro, um Portfólio de Serviços ou esclarece ou ajuda a esclarecer o seguinte estratégico perguntas: • • • • •

Por que um cliente comprar esses serviços? Por que eles deveriam comprar estes serviços de você? Quais são os preços ou estorno modelos? Quais são os meus pontos fortes e fracos, as prioridades e risco? Como deve ser o meu recursos capacidades e ser alocados?

Veja a Figura 3.6. Idealmente, o Portfólio de Serviços devem fazer parte de um abrangente Sistema de Gestão Serviço de Conhecimento (SGCS) e registrado como um documento no Gerenciamento da Configuração (CMS). Mais

ITIL V3 - Service Design - Página:

62 de 477

informações são fornecidas em ambos o CMS e os SKMS dentro do Transição de Serviço publicação. Figura 3.6 é uma representação da relação do portfólio de serviços com as SKMS.

Figura 3.6 Portfolio O Serviço - um repositório central

Uma vez que um estratégico decisão de fretar um serviço é feita, esta é a fase do ciclo de vida de serviços ao Design de Serviços começa arquitetar o serviço, que acabará por se tornar parte do Catálogo de Serviços. O Portfólio de Serviços devem conter informações relativas a todos os serviços e seu status atual no organização. As opções de estado na Carteira de serviço deve incluir: • • • •

Requisitos: Um conjunto de requisitos de destaque foram recebidos do negócio ou de TI para um serviço novo ou alterado Definido: O conjunto de requisitos para o novo serviço estão sendo avaliados, definidos e documentados e os SLR está sendo produzido Analisados: O conjunto de requisitos para o novo serviço estão sendo analisados e priorizados Aprovado: O conjunto de requisitos para o novo serviço ter sido finalizado e autorizado

ITIL V3 - Service Design - Página:

63 de 477

• • • • • • • •

Fretado: Os novos requisitos de serviços estão sendo comunicados e recursos e orçamentos alocado Projetado: O novo serviço e seu constituinte componentes estão sendo projetados - e adquiridos, se necessário Desenvolvido: O serviço e os seus componentes constituintes estão a ser desenvolvidos ou colhida, se aplicável Construído: O serviço e suas componentes estão sendo construídas Teste: O serviço e os seus componentes constituintes estão sendo testadas Lançado: O serviço e suas componentes estão sendo liberados Operacional: O serviço e suas componentes estão operacionais dentro do viver ambiente Aposentado: O serviço e suas componentes foram retirados.

O Portfólio de Serviços seria, portanto, conter detalhes de todos os serviços e suas estado no que diz respeito à fase de corrente dentro do ciclo de vida de serviço, tal como ilustrado na Figura 3.7.

ITIL V3 - Service Design - Página:

64 de 477

Figura 3.7 Portfolio O Serviço e seu conteúdo

Clientes e usuários só seria permitido o o a esses serviços na Portfólio de Serviços que foram de um estado entre "fretado" e "funcionamento", tal como ilustrado pela caixa na Figura 3.7, ou seja, os serviços contidos dentro do Catálogo de Serviços. Estratégia de Serviço e Design de Serviços pessoal seria necessário o a todos registros dentro do portfólio de serviços, bem como de outras áreas importantes, como a Gestão da Mudança. Outros membros da provedor de serviços organização teria o a um subconjunto permitido dos registros dentro do portfólio de serviços. Embora o portfólio de serviços é projetado por Design de Serviços, é detida e gerida por Estratégia de Serviço dentro do processo de Gestão de Portfólio de Serviço. Detalhes completos sobre

ITIL V3 - Service Design - Página:

65 de 477

Gestão de Portfólio de Serviços são discutidos na publicação Estratégia de Serviço. O Pipeline Service é um subconjunto do portfólio de serviços em geral e contém detalhes de todos os requisitos de negócio que ainda não se tornaram serviços liberados para o viver ambiente. Ela é usada como base para a definição, análise, priorização e aprovação, pelo ISG e Estratégia de Serviço, de todos os pedidos de serviços novos ou modificados, para assegurar que os serviços novos e modificados são alinhados com os requisitos de negócios. Ele vai ser principalmente usado como entrada para as atividades da Estratégia de Serviço e estágios serviço de projeto do Ciclo de Vida de Serviço. Ele também fornece dados valiosos para as atividades do Transição de Serviço fase do ciclo de vida na determinação dos serviços a serem liberados. O Serviço de Gestão de Catálogo processo deve assegurar que todos os detalhes dentro do Portfólio de Serviços são precisos e up-to-date como o exigência e seu serviço novo ou alterado é migrado para o ambiente ao vivo. Este será realizado em estreita ligação com todas as atividades de Transição de Serviço. Vários elementos do mesmo serviço pode ter diferentes estados ao mesmo tempo. Caso contrário, o Portfólio de Serviços seria incapaz de ar "incremental e iterativo ' desenvolvimento. Cada organização deve projetar cuidadosamente seu portfólio de serviços, o conteúdo eo o permitido para o conteúdo. O conteúdo deve incluir: • • • • • • • • • • • • • • • • • • •

Nome do serviço Descrição do serviço Serviço estado Serviço classificação e criticidade Aplicaçãos usado Dados e / ou esquema de dados utilizados Processo de negócioes ada Os proprietários do negócio Negócio usuários TI proprietários Garantia de serviço referências SLA nível, e SLR Serviços de apoios Apoiar recursos Dependente serviços Apoio Olas, contratos e acordos Serviço custars Taxas de serviço (se aplicável) As receitas de serviços (se aplicável) Serviço métricos.

O Portfólio de Serviços é a principal fonte de informação sobre os requisitos e serviços e precisa ser cuidadosamente projetado para atender todas as

ITIL V3 - Service Design - Página:

66 de 477

necessidades de todos os seus usuários. O projeto do Portfólio de Serviços precisa ser considerado da mesma maneira como o desenho de qualquer outra De serviços de TI para garantir que ele atende a todas essas necessidades. Esta abordagem deverá também ser utilizada para todas as outras Serviço de Gestão de sistemas de informação, incluindo a: • • • • • • •

Serviço do Sistema de Gestão do Conhecimento (SGCS) Gerenciamento da Configuração (CMS) Sistema de Service Desk Capacidade do Sistema de Informação de Gestão (CMIS) Disponibilidade do Sistema de Informação de Gestão (AMIS) Gestão de Segurança Sistema de Informação (SIGE) Fornecedor e Contratos Banco de Dados (SCD).

3.6.3 arquiteturas de tecnologia Projetando As atividades de design de arquitetura de TI dentro de uma organização estão preocupados com o fornecimento global estratégico "Projetos" para o desenvolvimento e desenvolvimento de um Infra-estrutura de TI - Um conjunto de aplicaçãos e dados que atendam as necessidades atuais e futuras do negócio. Embora estes aspectos sustentam a prestação de serviços de TI de qualidade, sozinhos não podem fornecer qualidade de serviços de TI, e é essencial que as pessoas, processo e parceiro /fornecedor aspectos que cercam estes tecnológica componentes (produtos) são também consideradas. 'Arquitetura"É um termo usado em vários contextos diferentes. Neste contexto, é definida como: A organização fundamental de um sistema, incorporada nas suas componentes, suas relaçãos um ao outro e ao meio ambiente, e com os princípios orientadores da sua concepção e evolução. 'Sistema' nesta definição é usada em mais geral, não necessariamente de TI, sentido: "Uma coleção de componentes organizados para realizar uma específica função ou conjunto de funções.

Assim, o sistema pode ser, por exemplo, uma organização de todo, uma função de negócios, ou uma linha de produto de um sistema de informação. Cada um destes sistemas terá uma "arquitectura", tal como definido anteriormente, constituído pelo componentes do sistema, as relações entre eles (como interfaces de controle e intercâmbio de dados), as relações entre o sistema eo seu ambiente (políticas, organizacionais, tecnológicos, etc) e os princípios de design que informar, orientar e restringir a sua estrutura e operação, Bem como o seu futuro desenvolvimento.

ITIL V3 - Service Design - Página:

67 de 477

Em essência, a arquitectura pode ser definida como: "O desenvolvimento e manutenção de políticas, estratégias, arquiteturas, desenhos, documentos, planos e processos para a desenvolvimento e posterior operação e melhoria da apropriadas serviços de TI e soluções de toda a organização. " O trabalho do projeto arquitetônico precisa avaliar e reconciliar diversos tipos de necessidades, alguns dos quais podem estar em conflito um com o outro. O trabalho deve assegurar que: •

• • •

As infra-estruturas de TI, ambientes de dados, aplicaçãos e serviços externos servir as necessidades da empresa, seus produtos e serviços. Este atividade não inclui apenas os componentes de tecnologia, mas também a gestão deles O justo equilíbrio entre a inovação, risco e custar ao buscar uma vantagem competitiva, onde desejado pela empresa Há a conformidade com as estruturas arquitetônicas, estratégias, políticas, regulamentos e normas Uma interface é fornecida coordenada entre TI desenhistas e projetistas, designers, estrategistas de negócios e planejadores.

As atividades de projeto de arquitetura deve usar a entrada do negócio, Estratégia de Serviço, Seus planos, desenhistas e projetistas para desenvolver projetos adequados, planos, arquiteturas e políticas para todas as áreas de TI. Estes projetos, planos, arquiteturas e políticas devem cobrir todos os aspectos da TI, incluindo papels e responsabilidades, serviços, tecnologia, arquitetura e estruturas, processoes e procedimentos, parceiros e fornecedors métodos e gestão. O processo de projeto arquitetônico também deve cobrir todas as áreas de tecnologia, incluindo a infra-estrutura, ambiente,aplicaçãos e dados e estar intimamente ligado ao do negócio em geral planejamento e projeto processos. Qualquer empresa é um sistema complexo, com muitos tipos de componentes, incluindo a equipe, funções de negócios e processos, estrutura organizacional e distribuição física, recursos de informação e sistemas de informação, financeiro e outros recursos, incluindo tecnologia, e as estratégias, planos, gestão, políticas e governo estruturas que dirigem a empresa. Uma arquitetura empresarial deve mostrar como todos estes componentes (e outros) são integradas a fim de alcançar o negócio objetivos, tanto agora como no futuro. A Arquitetura Corporativa completa pode ser grande e complexo. Aqui estamos interessados em pessoas arquiteturaestá preocupado com o negócio da organização e os sistemas de informação que am. Cada uma dessas arquiteturas apela arquitetônicas distintas disciplinas e áreas de conhecimento, como ilustrado na figura 3.8.

ITIL V3 - Service Design - Página:

68 de 477

Figura 3.8 Enterprise Architecture

Arquitetura Corporativa é definido pela Gartner como: "O processo de tradução de negócios visão e estratégia em empresa eficaz mudar, Com a criação, a comunicação ea melhoria princípios fundamentais e modelos que descrevem os estados futuros da empresa e permitir a sua evolução ".

Há muitos quadros de proprietários e não-proprietários para o desenvolvimento de uma arquitetura empresarial, como ilustrado na Tabela 3.1.

ITIL V3 - Service Design - Página:

69 de 477

Nome quadro completo

Sigla quadro

Arquitetura do Quadro Integrado de Sistemas de Informação

ARIS

Bredemeyer Quadro

Bredemeyer

Transformação de Negócios Enablement quadro Transformação do Programa

BTEP

Comando, Controle, Comunicações, Computadores Inteligências Vigilância e Reconhecimento

C4ISR

CSC Catalisador

Catalisador

Manufatura Integrada por Computador Arquitetura de Sistemas Abertos

CIMOSA

Enterprise Architecture Framework

Gartner

Empresa de Planejamento Arquitetura

EAP

Quadro Extended Enterprise Architecture

E2AF

FEA Modelos de Referência

FEA

Generalizada Enterprise Architecture Referência e Metodologia

GERAM

Integrated Architecture Framework

IAF

Pilares da EA

Forrester

Modelo de Referência para Processamento Distribuído Aberto

RM-ODP

Gestão de Informação Técnico Architectural Framework

TAFIM

Tesouro Enterprise Architecture Framework

TEAF

TOGAF Modelo de Referência Técnica

TOGAF

Zachman Framework

Zachman

Tabela 3.1 Arquitetura estruturas empresariais

Estes quadros incluem descrições da estrutura organizacional, processo de negócioes de planejamento e controle de sistemas, gestão e governo mecanismos, políticas e procedimentos da empresa. Eles mostram como estes componentes interagir e contribuir para a realização de objetivos de negócio e objetivos, e fornecer a base para identificar os requisitos para sistemas de informação que am estes processos de negócios. ITIL V3 - Service Design - Página:

70 de 477

A Arquitetura Corporativa deve ser um elemento integrante da Arquitetura de Negócios e deve incluir as seguintes áreas principais: •

•

•

•

•

Arquitetura de Serviço, Que se traduz aplicaçãos, infra-estrutura, organização e atividades de apoio em um conjunto de serviços. O Arquitetura de Serviço prevê a abordagem de negócios independente, integrada para a prestação de serviços à negócio. Ele fornece o modelo para fazer uma distinção entre a arquitetura de serviço, a arquitetura do aplicativo, a Arquitetura de Dados e Infra-estrutura da Arquitetura. Ele também fornece tolerância a falhas, Preparação para o futuro e segurança controlos. Isto significa que, potencialmente, quaisquer alterações que ocorram na arquiteturas de tecnologia será transparente para a usuários da serviço - Por exemplo, web-based de entrega mecanismos de auto-serviço. Ela deve incluir não apenas os próprios serviços e sua integração global, mas também a gestão desses serviços. Arquitetura da Aplicação, Que fornece um modelo para a desenvolvimento e desenvolvimento de aplicativos individuais, mapas de negócio e requisitos funcionais para aplicações, e mostra as interrelações entre as aplicações. Arquiteturas de aplicação emergentes são susceptíveis de ser baseado em componentes. Essa abordagem maximiza a reutilização e ajuda a manter a flexibilidade em mudanças acomodando em terceirização política. Dados / Arquitetura de Informação, Que descreve os ativos físicos e lógicos de dados da empresa e do gerenciamento de dados recursos. Ele mostra como os recursos de informação são geridos e compartilhada para o benefício da empresa. A estratégia em dados centralizada versus distribuída quase certamente foram concebidas como parte de uma tal arquitetura. Os dados / Arquitetura da Informação deverão ter em conta as tecnologias de armazenamento de dados que facilitam a exploração dos bens de informações corporativas. É cada vez mais cobrir gerenciamento de conteúdo e as instalações para a entrega de informações através de múltiplos canais. Arquitetura de TI Infra-estrutura, Que descreve a distribuição de funcionalidade, estrutura e geográfica do hardware, software e componentes de comunicação que servem de base e apoiar a arquitectura global, bem como as normas técnicas aplicáveis a eles. Esta também deve incluir uma "Arquitetura de Produto" que descreva os produtos proprietários particulares e padrões da indústria que a empresa usa para implementar a infra-estrutura em conformidade com os princípios da arquitetura de TI Infra-estrutura Arquitetura Ambiental, Que descreve todos os aspectos, tipos e níveis de ambiente controlars e sua gestão. Uma ilustração do tipo de informação sobre o ambiente necessário está incluído no Apêndice E.

O relaçãos entre essas perspectivas arquitectónicos podem ser vistos na Figura 3.9. As arquiteturas de documentação, desenvolvimento e manutenção de

ITIL V3 - Service Design - Página:

71 de 477

negócios e de TI, normalmente fazem parte da processoes de estratégico pensar e estratégia no desenvolvimento organização.

Figura 3.9 relações de arquitectura

Dentro da estrutura descrita anteriormente, é possível identificar (pelo menos) três arquitectónico papels. Estes poderiam relatar a um idoso "Enterprise Architect" na organização: •

•

Negócios / Arquiteto Organizacional: Preocupação com os negócios modelos, processo de negócioes e organizacional projeto - Estrutural e funcional componentes da organização e sua relação, e como o negócio funções e atividades da organização são distribuídas entre eles, também a governação da organização e os papéis e responsabilidades necessárias Arquiteto serviço (Muitas vezes papéis distintos de Aplicações Arquiteto e Informação / Data Architect): preocupados com o Serviço, dados e

ITIL V3 - Service Design - Página:

72 de 477

•

arquiteturas de aplicativos - a lógicas arquiteturas apoiar o negócio e as relações entre eles Arquiteto de TI Infra-estrutura: Preocupado com o modelo de tecnologia física, os componentes de infra-estrutura e suas relações, incluindo escolhas de tecnologias, interfaces e protocolos, ea seleção de produtos para implementar a infra-estrutura.

Em algumas organizações, o papels de Negócios / Arquiteto Organizacional, Arquiteto de Sistemas de Informação (ou papéis possivelmente separados de Aplicações Arquiteto e Arquiteto de Dados) e Arquiteto de TI Infra-estrutura será funções distintas. Em outras, algumas ou todas as funções podem ser combinadas. Os papéis podem residir em partes separadas da organização ou mesmo fora dela. Por exemplo: • •

•

O papel Business Architect / organizacional pode residir no negócio Estratégia e Planejamento função na sede corporativa O papel do arquiteto serviço podem fazer parte de uma função interna com a responsabilidade de lidar com as relações entre a empresa, externa fornecedors de TI e parceiros relacionados com questões de serviço. Uma das principais responsabilidades de tal função é a manutenção da Arquitetura de Serviço. Esta função pode ser dentro de uma função de TI ou no lado do negócio de uma organização O papel do arquiteto de TI Infra-estrutura pode residir com o provedor de serviços/ Parceiro que é responsável pela produção da Arquitetura de Infra-estrutura de TI utilizado para a entrega de De serviços de TIs para a organização.

Se o necessário arquiteturas estão no lugar, em seguida, o papel de Design de Serviços é afetado das seguintes formas: • • •

Deve trabalhar dentro do quadro acordado arquitetura e padrões Será capaz de voltar a usar muitos dos bens criados como parte da arquitetura Devem trabalhar em estreita colaboração com todas as três funções de arquitetura para garantir o máximo proveito do trabalho feito na criação da arquitetura.

Se o projeto de arquitetura deve ser realizado de forma eficaz e economicamente, os documentos, processos e atividades da empresa e projeto arquitetônico deve ser estreitamente coordenada e sincronizada. A lista dos documentos de projeto e seu conteúdo está contido nos Apêndices C e D. Os detalhes individuais de tecnologia incluídos no projeto arquitetônico são considerados nas seções seguintes.

ITIL V3 - Service Design - Página:

73 de 477

O real benefício e ROI do Enterprise Architecture não vem da própria arquitetura, mas a partir da capacidade de uma organização para projetar e implementar projetos e as soluções de uma maneira rápida e consistente. 3.6.3.1 Gestão de Tecnologia

Aestratégico abordagem deve ser adotada com relação ao planejamento de um tecnologia da informação e sua gestão. Isto implica a criação de "arquiteturas" ou "esquemas" para o quadro a longo prazo da tecnologia utilizada e planejada. TI planejadores, projetistas e arquitetos precisam entender o negócio, os requisitos e da tecnologia atual, a fim de desenvolver TI apropriada arquiteturas para o curto, médio e longo prazo. Design de tecnologia também precisa levar em conta os prováveis serviços de TI que irão apoiar, ou pelo menos os tipos de serviço a partir de um entendimento do negócio e sua orientação futura, porque o negócio vai exigir serviços de TI, e eles vão precisar de uma tecnologia adequada para oferecer e prestar esses serviços. Se é possível para fornecer uma tecnologia de longo prazo, que podem apoiar uma série de serviços de TI, em seguida, tendo uma abordagem estratégica proporcionará benefícios a longo prazo. Arquiteturas precisam ser desenvolvidos dentro das grandes áreas de tecnologia. Arquiteturas de tecnologia Arquiteturas são necessários em todas as áreas de Infra-estrutura de TI. Sempre que pertinente, devem ser desenvolvidas nas seguintes áreas: • • •

Aplicações e sistemas de software Informações, dados e base de dados, incluindo informações segurança e confidencialidade, Mineração de dados e armazenamento de dados Projeto de infra-estrutura e arquitetura: • Central servidor, Arquiteturas de mainframe, distribuídos servidores regionais, incluindo arquivos local e servidores de impressão • Redes de dados (LANs, MANs, WANs, protocolos, etc), internet, intranet e extranet sistemas • Tecnologias convergentes de rede, incluindo redes de voz (PABX, Centrex, telefones, celulares, aparelhos de fax, etc) • Sistemas de clientes (desktops, notebooks, dispositivos de o móvel (dispositivos portáteis, telefones celulares, palmtops, PDAs, scanners, etc) • Dispositivos de armazenamento, redes de área de armazenamento (SANs), Network Attached Storage (NAS), incluindo apoio e recuperação sistemas e serviços (servidores, robôs, etc) • Armazenamento de documentos, manuseio e gestão

ITIL V3 - Service Design - Página:

74 de 477

•

•

Áreas especializadas de tecnologia, tais como EPOS, caixas eletrônicos, dispositivos de digitalização, sistemas de GPS, etc Sistemas ambientais e equipamentos, incluindo a sua monitoramento e gestão.

Isto irá resultar numa hierarquia de arquiteturas, o que terá de ser articulados para a construção de um conjunto integrado de arquiteturas de tecnologia para o organização. A Arquitetura de Infra-estrutura deverá ter como objectivo fornecer relativamente poucas plataformas padronizadas para hospedagem aplicaçãos. Também deve estabelecer normas para arquiteturas de aplicações que estão a ser hospedado em centros de dados controlados de modo que estes se encaixam no padrão de funcionamento, monitoramento e segurança requisitos Arquitecturas de gestão TI deve gerir custars, entregar os serviços certos no momento certo, os ativos de informações seguras, fornecer um serviço confiável e levar o negócio para alavancar tecnologias. Isto requer automatizado procedimentos e ferramentas de gestão, a fim de alcançar este objectivo de forma eficaz e eficiente. A seleção de uma arquitetura de gestão adequado é fundamental para estabelecer o nível de controlar e automação. Existem duas abordagens distintas para o desenvolvimento de uma arquitetura de gerenciamento: •

•

Seleção de uma arquitetura de gerenciamento de propriedade: Esta baseia-se na selecção de um conjunto único de produtos e ferramentas de gestão de uma única istração de soluções proprietárias fornecedor. Esta abordagem irá normalmente exigem menos esforço, irá apoiar e integrar dentro de uma arquitetura de ferramenta em geral, mas, muitas vezes significa que compromete terá de ser feita com a funcionalidade de gestão e de instalações, o que pode resultar em falhas. Selecionando 'melhor da raça "uma arquitetura: Esta abordagem envolve a seleção de um conjunto de "Melhor da Raça" ferramentas de gestão e produtos a partir de um número de fornecedores de soluções de gestão e integrá-los para fornecer uma solução abrangente de gerenciamento. Isso geralmente requerem mais esforço na integração das ferramentas em uma solução única de gestão abrangente, mas, muitas vezes, oferecem maior funcionalidade de gestão e instalações que levam a poupança de longo prazo de custos.

Os desafios para a gestão de TI são coordenar e trabalhar em parceria com a negócio na construção destas soluções de gestão, ando a adequada processoes e proporcionando as medições necessárias e métricos. Isso tem que ser alcançado reduzindo ou otimizando os custos envolvidos, particularmente os custos anuais, em curso. A melhor maneira de minimizar custos é projetar inteligentemente e com cuidado - por exemplo, fazendo o melhor uso de capacidade para que a capacidade adicional não é desnecessariamente

ITIL V3 - Service Design - Página:

75 de 477

comprou (com seus custos associados em curso), ou projetar um apoioSolução / recuperação que não requer um conjunto completo de infra-estrutura adicional. Custos consideráveis pode ser salvo por inteligente e cuidadosa projeto, Utilizando a tecnologia que é ável e causa poucos problemas no operacional ambiente. O principal método de alcançar essas metas é criar soluções que dão a uma redução na gestão global da rede e os custos de e, mantendo ou melhorando a qualidade do serviço prestado para a empresa. Para obter os maiores benefícios da utilização do Quatro Ps, organizaçãos deve determinar os papéis de processos e pessoas, e depois implementar as ferramentas para automatizar os processos, facilitando as pessoas de papels e tarefas. A melhor maneira de conseguir isso é desenvolver um modelo ou arquitetura com base nesses princípios. Esta arquitetura deve facilitar a implementação de um conjunto de ferramentas integradas de gestão e processos que e "fim-a-fim" de todas as áreas da tecnologia utilizada, garantindo que não existem lacunas e não "silos técnicas". No entanto, ele enfrenta um grande desafio no desenvolvimento e manutenção das habilidades sociais necessárias para executar essas funções e processos de gestão eficaz. Nas organizações verdadeiramente eficazes, estas funções e processos estão alinhados com os da empresa. Isso garante que os processos de negócios e de gestão de TI e informações têm metas e objectivos semelhantes. No entanto, muitas vezes, as organizações dedicar tempo e esforço insuficiente para o desenvolvimento das habilidades sociais (por exemplo, habilidades interpessoais, habilidades de comunicação, habilidades de reuniões) necessárias para a processoes eo alinhamento do negócio a ser efetivamente alcançado. Existem cinco áreas que têm de ser considerados em relação à projeto de uma arquitectura de gestão, tal como ilustrado na Figura 3.10.

ITIL V3 - Service Design - Página:

76 de 477

Figura 3,10 tecnologia de gerenciamento integrado voltado aos negócios

O relaçãos entre essas perspectivas de arquitetura pode ser visto no diagrama acima. As arquiteturas de documentação, desenvolvimento e manutenção de negócios e de TI, normalmente fazem parte dos processos de estratégico pensar e estratégia desenvolvimento na organização. Estas cinco áreas de gestão a serem considerados pode ser rapidamente definida como: • • • • •

Negócio: As necessidades, requisitos, processos, objetivos e metas do unidade de negócioss e gestores dentro da organização Pessoas: O escopo, Tarefas e atividades dos gestores e funcionários envolvidos na gestão da prestação de De serviços de TIs Processos: Os processos e procedimentos usados para gerenciar serviços de TI para o negócio e seu clientes Ferramentas: As ferramentas de gerenciamento e e necessários para gerir eficazmente o Infra-estrutura de TI Tecnologia: Os produtos de TI e de tecnologia usada para entregar o serviço e informações para a pessoa certa, no lugar certo, na hora certa.

Tal arquitetura pode ser usado para projetar e implementar soluções de gestão eficiente, eficaz e integrada, que estão alinhados com os requisitos de negócio da organização e seus gerentes de negócios. Esta arquitetura de gestão pode ser aplicada dentro de uma organização:

ITIL V3 - Service Design - Página:

77 de 477

•

•

•

Projeto de cima para baixo, Assegurando que o Serviço de Gestão de e processos de tecnologia de gestão, ferramentas e informações estão alinhados com as necessidades e objetivos de negócio Implementar de baixo para cima, Garantindo que o Gerenciamento de Serviço eficiente e eficaz e processos de gestão de tecnologia são totalmente integradas com as ferramentas e tecnologias em uso dentro do organização Integrar os processos e ferramentas, Garantindo uma maior exploração de ferramentas na gestão e e de tecnologia e de ponta a pontaprocessos.

Estes pontos são também ilustrados na Figura 3.10. A chave para o desenvolvimento de uma arquitetura de gestão é garantir que ele é impulsionado por necessidades do negócio e não desenvolvido para as necessidades de TI de forma isolada: Arquitecturas de gestão devem ser: '... negócios alinhados não, tecnologia orientada ".

Dentro desta estrutura geral, uma arquitetura de gerenciamento é necessário que possa ser aplicada a todas as áreas de Gestão de TI e não apenas individuais áreas isoladas. Isto pode então ser executado de uma coordenada programa de inter-funcionamento, para fornecer gerenciamento de empresa global de ponta a ponta, tão essencial para a gestão eficaz da infra-estrutura de TI atual. Se apenas as áreas individuais comprar a arquitetura, Então individuais "ilhas de excelência" vai desenvolver e que será impossível fornecer os completas end-to-end de soluções necessárias para ar hoje soluções ebusiness. Bem como assegurar que todas as áreas de TI são integrados, é vital que a arquitetura de gestão é desenvolvido a partir da perspectiva de negócios e de serviços ('top down', por exemplo). Portanto, os elementos-chave para acordar e definir antes de desenvolver a arquitetura de gerenciamento são: • •

Gestão do processo de negócioes: Quais são os processos de negócios e como eles se relacionam com a rede e serviços de TI e componentes? Gestão de serviço qualidade: O que é qualidade de serviço? Como e onde é que vai ser medido?

Estes são os elementos-chave que precisam ser determinadas pela SLM e Gestão de TI. Eles dar um contributo crucial para o desenvolvimento de arquiteturas de negócios com foco de gestão. Muitas vezes as ferramentas de gestão e processoes têm sido focados na gestão de componentes e componentes, em vez de serviços e processos de negócios. Isso precisa ser

ITIL V3 - Service Design - Página:

78 de 477

mudado, com ênfase claramente no projeto de sistema de gestãos, processos e ferramentas que são movidos pelas necessidades do negócio e estamos focados em gestão de processos de negócios e serviços de TI. Se a arquitetura de gestão adequado é projetado e implementado, isso vai permitir Serviço de Gestão de processos para concentrar-se na gestão de serviços e serviço qualidade e operar de ponta-a-ponta em toda a empresa de TI inteira, fornecendo Empresa verdade Serviço de Gestão de. Isso vai realmente facilitar a gestão de serviços para garantir que os serviços e qualidade de serviço estão estreitamente alinhados com as necessidades do negócio. O arquiteturas descritos sugerem que o futuro da rede e gerenciamento de sistemas será menos centrada na tecnologia e se tornam mais integrados com os requisitos gerais do negócio e Gestão de TI. Estes novos sistemas e processos já estão começando a evoluir como as normas de gestão para o intercâmbio de gestão da informação entre as ferramentas se tornam mais totalmente definido, por organizações como o Distributed Management Task Force (DMTF). Em essência, os sistemas de gestão será: • • • •

• •

Mais focada nas necessidades das empresas Mais alinhada com a processo de negócioes Menos dependente de tecnologia específica e mais "centrada em serviços" Mais integrado com outras ferramentas de gestão e processos, as normas de gestão evoluir. Isso vai envolver a integração de sistemas de gestão, operacional gestão e Serviço de Gestão de ferramentas e processos, com 'silos de tecnologia' e 'menos ilhas de excelência " Parte de sistemas end-to-end e processos de gestão, mais focado na prestação de serviços de qualidade e atendimento ao cliente Mais flexível. Haverá um afastamento de alguns dos mais rígida, única fornecedor enquadramentos para uma abordagem mais aberta 'best-ofbreed ".

3.6.4 processos Projetando Esta seção fornece uma introdução geral ao processar teoria e prática, Que é a base para o projeto de ITIL os processos que são utilizados no Serviço Ciclo de Vida. Um processo de modelo possibilita a compreensão e ajuda a articular as características distintivas de um processo. Um processo é um conjunto estruturado de atividades destinadas a realizar uma específica objetivo. Um processo leva uma ou mais entradas e as transforma em saídas definidas. Um processo inclui todas as papels, responsabilidades, ferramentas e gestão controlars obrigado a entregar de forma confiável as saídas. Um processo também pode definir ou revisar políticas, normas, diretrizs, atividades, processos, procedimentos e instrução de trabalhos se eles são necessários.

ITIL V3 - Service Design - Página:

79 de 477

Controle de processo pode ser definida como: O atividade de planejamento e regulação de um processo, com o objetivo de realizar um processo de uma forma eficaz, eficiente e consistente. Processos, uma vez definido, devem ser documentados e controlados. Uma vez sob controlo, podem ser repetidos e tornar controlável. Graus de controlo sobre os processos podem ser definidos, e em seguida de medição do processo e métricos podem ser construídos em que o processo para controlar e melhorar o processo, tal como ilustrado na Figura 3.11.

Figura 3.11 Os elementos genéricos do processo

Os elementos genéricos do processo mostram dados entram no processo, é processado, é emitido e o resultado é medido e analisado. Esta descrição muito básica subjacente a qualquer descrição do processo. Um processo é sempre organizado em torno de um conjunto de objectivos. Os principais resultados do processo deve ser conduzido pelos objectivos e deve sempre incluir medições de processos (métricas), relatórios e melhoria de processos. Cada processo deve ser de propriedade de um proprietário do processo, Quem deve ser responsável para o processo e seu aperfeiçoamento e para assegurar que um processo cumpre os seus objectivos. Os objectivos de qualquer processo de TI devem ser definidos em termos mensuráveis e devem ser expressas em termos de benefícios para os negócios e os negócios que sustenta estratégia e objetivos. Design de Serviços devem ajudar cada processo com o proprietário projeto de processos, a fim de assegurar que todos os

ITIL V3 - Service Design - Página:

80 de 477

processos utilizam termos padrão e modelos, são consistentes e integrar com o outro para fornecer end-to-end integração de todas as zonas. A saída produzida por um processo tem de obedecer a normas operacionais que são derivados de objectivos comerciais. Se os produtos em conformidade com a norma conjunto, o processo pode ser considerado como eficaz (uma vez que pode ser repetido, medidos e istrados). Se as atividades são realizadas com um uso mínimo de recursos, o processo pode também ser considerada eficaz. Processo de análise, resultados e métricas devem ser incorporadas nos relatórios regulares de gestão e melhorias de processo. Todas estas áreas devem ser incluídas no projeto de qualquer processo. Estas novas publicações ITIL ter sido escrito em torno de "conjuntos de processos" que refletem as etapas do ciclo de vida de um serviço. O Design de Serviços conjunto de processos detalhados nesta publicação abrange os processos, principalmente com relação a todos os aspectos do projeto. Trabalhar com processos definidos tem sido a base do ITIL desde o seu início. Ao definir o que o organização'S são actividades que são necessárias entradas e saídas que irá resultar do processo, é possível trabalhar de modo mais eficiente e eficaz. Medição e direcção das actividades aumenta este eficácia. Finalmente, através da adição de normas para o processo, é possível adicionar qualidade medidas para a saída. Esta abordagem sustenta a Plan-Do-Check-Act ciclo de melhoria contínua para qualquer sistema de gestão da qualidade. Planear a finalidade do processo de tal modo que as acções do processo podem ser analisados, avaliados ou controladas para realizar com sucesso e melhorado. Normas definir certas condições que os resultados devem atender. Normas definindo introduz aspectos de qualidade para o processo. Mesmo antes de começar, é importante pensar sobre o que os resultados dos processos deve ser parecida. Para descobrir se ou não as atividades do processo estão contribuindo de forma otimizada para o objetivo de negócio e da objetivos do processo, alinhada aos objetivos de negócio, a eficácia deve ser medida em uma base regular. Medição permite a comparação do que tem sido feito com o que a organização se propôs a fazer, e para identificar e implementar melhorias no processo. Cada organização deve adotar uma abordagem formal para a concepção e implementação de Serviço de Gestão de processos. O objetivo não deve ser o de "processos perfeitos" de design, mas para projetar processos práticos e adequados com os mecanismos de "embutido" de melhoria, de modo que a eficácia ea eficiência dos processos são melhoradas de forma mais adequado para o organismo. Documentação normas, processos e modelos deve ser usado para assegurar que os processos são facilmente adoptada em toda a

ITIL V3 - Service Design - Página:

81 de 477

organização. Alguns exemplos de modelos de documentação do processo estão incluídas no Apêndice C. A meta para agora e no futuro, é a concepção de processos e apoiar essas ferramentas que podem proporcionar a integração entre as organizações. Isso agora se tornou possível porque as ferramentas de gestão estão a prestar apoio de padrões abertos, como o Distributed Management Task Force (DMTF), que am a troca de informações com base em ITIL conceitos, como incidentes, problemas e mudars com formatos padrão e conteúdos. Isto permite que provedor de serviçoss para ar interfaces de processos eficientes e eficazes com a sua principal fornecedors com câmbio automatizado de chave operacional informação em tempo real.

3.6.5 Projeto de sistemas de medição e métricas "Se você não pode medir-lo, então você não pode controlá-lo."

A fim de gerenciar e controlar os processos de design, eles têm que ser monitorado e medido. Isto é verdade para todos os aspectos dos processos de desenho. Medidas e métricos são abordados em detalhes na publicação Melhoria de Serviço Continuada. Esta seção aborda os aspectos que são particularmente relevantes e apropriadas para medir a qualidade dos processos de projeto e sua entregas. Deve haver cuidado ao selecionar as medições e as métricas e os métodos utilizados para produzi-los. Isto porque as métricas e medições escolhidos vão realmente afetar e mudar o comportamento das pessoas que trabalham no âmbito das actividades e processos que estão sendo medidas, nomeadamente quando se refere a objetivos, pessoal e da equipe atuação e esquemas relacionados com o desempenho de pagamento. Portanto, somente medidas que incentivem a progressão no sentido de cumprir objetivo de negócios ou desejada mudança de comportamento devem ser selecionados. Em todas as atividades do projeto a exigência deveria ser: • • • •

•

Soluções de design que são 'apto para o efeito' Design para o nível adequado de qualidade - Não mais de engenharia ou em engenharia Soluções de design que são "à primeira" e cumprir os seus objectivos esperados Soluções de design que minimizam a quantidade de "retrabalho" ou "addons" que têm de ser rapidamente desenvolvido após soluções foram implantadas Soluções de design que são eficazes e eficientes do ponto de vista da negócio e a clientes. A ênfase deve ser sobre as soluções que são eficazes acima de tudo e que são eficientes dentro do constrangimento de permanecer eficaz.

ITIL V3 - Service Design - Página:

82 de 477

Métodos de medição e métricas devem refletir esses requisitos e ser projetado para medir a capacidade de processos de design para combinar com esses requisitos. Todas as medições e métricos usado deve reflectir a qualidade eo sucesso do projeto processoes a partir da perspectiva dos negócios, clientes e usuários. Eles precisam refletir a capacidade das soluções entregues para atender as necessidades identificadas e acordadas do negócio. As medições de processos seleccionados devem ser apropriados para o capacidade e maturidade dos processos a ser medido. Processos imaturos não são capazes de ar medições sofisticadas, métricas e métodos de medição. Existem quatro tipos de métricas que podem ser utilizados para medir a capacidade e o desempenho dos processos de: • •

• •

Progresso: Marcos e entregas na capacidade do processo Observância: O cumprimento do processo de governo requisitos, requisitos regulamentares e de conformidade de pessoas para a utilização do processo. Eficácia: A exatidão e correção do processo e sua capacidade de entregar o "resultado certo ' Eficiência: A produtividade do processo, a sua velocidade, rendimento e recurso utilização.

Medidas e métricas devem desenvolver e mudar como a maturidade ea capacidade de um processo se desenvolve. Inicialmente, com os processos de imaturos os primeiros dois níveis de métricas devem ser utilizados para medir o progresso e a conformidade do processo à medida que se desenvolve em maturidade. Como a maturidade do processo se desenvolve, maior uso deve ser feito de eficácia e eficiência métricas, mas não em detrimento de comprometer o progresso ou a conformidade do processo. A seleção das métricas, o ponto de medição e os métodos de medição, cálculo e elaboração de relatórios sobre as métricas devem ser cuidadosamente concebido e planejado. As principais métricas deve sempre se concentrar em determinar a eficácia ea qualidade das soluções fornecidas. Métricas secundárias podem então medir a eficiência dos processos utilizados para produzir e istrar a solução. A prioridade deve ser sempre a de garantir que os processos de fornecer os resultados corretos para o negócio. Portanto, os métodos de medição e métricas deve sempre fornecer esta medida com foco em negócios acima de tudo. O método mais eficaz de medida é estabelecer uma "Árvore Metrics" ou "árvore de KPI". Muitos organizaçãos coletar medição em áreas individuais, mas não para agregá-los juntos e ganhar o benefício total das medições, e, portanto, sofrem porque: •

Medidas não estão alinhados com objetivo de negócios e necessidades

ITIL V3 - Service Design - Página:

83 de 477

• • • • •

Não há visibilidade global da imagem do 'nível superior' Há lacunas em áreas onde as medições não são registradas Áreas individuais são bem medido e os outros são pouco ou não são medidos medidos Não há coerência no método de apresentação e cálculo das medições Decisões e ações de melhoria são baseadas em informações incompletas ou incorretas.

Por isso as organizações devem tentar desenvolver sistemas automáticos de medição baseado em uma forma de "Métricas Árvore ', como a ilustrada na Figura 3.12.

Figura 3.12 A Árvore Métricas

A árvore na Figura 3.12 é ilustrativa de um exemplo de uma árvore de métricas com base em uma típica Balanced Scorecard. Balanced Scorecards representam uma sistema de gestão que permite que um número crescente de organizações para clarificar a sua visão e estratégia em ação. Eles fornecem em relação ao interno processo de negócioes e externa resultados, a fim de melhorar continuamente estratégico atuação e resultados. Isso permite que todos dentro da organização para obter uma imagem do desempenho da organização ao nível adequado: • •

Gerentes de negócios e clientes pode obter um 'alto nível' negócio ' de instrumentos', Alinhados com as necessidades de negócio e processos Seniores de TI, gestores e clientes podem se concentrar no de gerenciamento de nível superior de TI

ITIL V3 - Service Design - Página:

84 de 477

• • • •

Service Managers e os clientes podem concentrar-se na execução de serviços particulares Proprietário do processos e os gerentes podem ver o desempenho de sua processoes Especialistas técnicos pode olhar para o desempenho individual componentes O de instrumentos apresenta também uma oportunidade de ver as tendências ao longo do tempo, ao invés de dados estáticos, de modo que a degradação do desempenho potencial pode ser identificado e corrigido em um estágio inicial.

Isto significa que, dentro de um sistema hierárquico de métricas, cada pessoa no organização pode ter o a um nível adequado de informação e de medição que se adapte às suas necessidades em particular. Ele dá a gerência sênior a oportunidade de acompanhar um de alto nível para garantir que serviços continuam a ser entregues aos seus níveis acordados, e também fornece o capacidade para especialistas técnicos e proprietários de processos para perfurar até ao detalhe para analisar variação de serviço acordado, componente ou um processo de desempenho. Obviamente, a coleta, análise e apresentação de dados pode ser uma atividade muito trabalhoso e, portanto, deve ser automatizado, sempre que possível. Isto pode ser conseguido utilizando ferramentas de análise baseadas em macros, scripts, folhas de cálculo ou, preferencialmente, em específico soluções baseadas na web. As medições em cada um dos níveis devem ser definidos especificamente para atender as necessidades do negócio, Clientes e usuários da informação. Informações mais detalhadas sobre as medidas, métricas e métodos de medição estão contidas na publicação Melhoria de Serviço Continuada.

ITIL V3 - Service Design - Página:

85 de 477

3.7 As seguintes atividades de design Uma vez que a solução de serviço desejado foi concebido, em seguida, as atividades subseqüentes também deve ser preenchida com o Design de Serviços fase antes que a solução a para o Transição de Serviço fase.

3.7.1 Avaliação de soluções alternativas Um adicional avaliação fase pode ser necessário se externo fornecedor serviços e soluções estão envolvidos. Este consiste no seguinte: •

•

•

A seleção de um conjunto de fornecedores e completar um processo de concurso. Isto requererá a produção e a conclusão de: • Documentação da escopo do serviço e produção de uma Declaração de Necessidade (SOR) e / ou um Termos de referência (TR) documento • Request For Information (RFI), solicitação de proposta (RFP), solicitação de cotação (RFQ) e concurso (ITT) documentos • Produção e adoptando um conjunto de solução e fornecedor critérios de avaliação e uma pontuação processo. Avaliação e rever de respostas de fornecedores e seleção do preferido fornecedor(S) e sua solução proposta (s). Isso também pode envolver a execução de ensaios ou até mesmo protótipos ou prova de conceito se atividades significativas novos conceitos ou de tecnologia estão envolvidas no novo serviço, a fim de garantir que os componentes novos satisfazer as suas expectativas. Avaliação e custeio dos projetos alternativos, possivelmente incluindo a identificação de potenciais fornecedores e avaliação de suas propostas alternativas, tecnologias, soluções e contratos. Existe uma necessidade de garantir que cobre custando one-off custars e custos correntes de operação e propriedade, incluindo e e manutenção.

3.7.2 Aquisição de a solução preferida É possível que os elementos externos não será necessário para a solução. No entanto, isso é incomum como fornecedores de software, pelo menos são altamente propensos a se envolver. Quando os fornecedores externos estão envolvidos na solução preferida, as etapas consistem em: • • •

Completando todas as verificações necessárias sobre o preferido fornecedor Finalizar os termos e condições de quaisquer novos contratos, garantindo que todas as políticas corporativas são aplicadas A aquisição da solução selecionada.

ITIL V3 - Service Design - Página:

86 de 477

3.7.3 Desenvolver a solução de serviço O desenvolvimento etapa consiste em traduzir a Design de Serviços num plano para o desenvolvimento, reutilização ou renovação do componentes obrigado a entregar o serviço e posterior execução do serviço desenvolvido. Ele pode necessitar de ser convertida numa programa de planos, se trata de um serviço principal mudar. Cada plano ou projeto dentro do programa será responsável pela entrega de um ou mais componentes do serviço e incluem: • • • •

•

•

As necessidades do negócio O estratégia para ser adoptada para a aquisição e desenvolvimento ou da solução de Os prazos envolvidos O recursos necessário, levando-se em consideração instalações, Infraestrutura de TI e as habilidades certas de pessoal a fim de garantir a entrega serviço atende às necessidades do cliente O desenvolvimento do serviço e dos seus componentes constituintes, incluindo a istração e de outros operacional mecanismos, tais como a medição, monitoramento e elaboração de relatórios Serviço e planos de teste de componentes.

Gestão do projecto cuidadoso terá de ser usado para assegurar que o conflito é evitado e que os componentes compatíveis são desenvolvidos a partir das várias actividades de desenvolvimento diferentes

ITIL V3 - Service Design - Página:

87 de 477

3,8 restrições de design Todas as atividades de design operar dentro de muitas restrições. Estas restrições vêm do negócio e Estratégia de Serviço e cobrir muitas áreas diferentes, como ilustrado na Figura 3.13.

Figura 3.13 As restrições de design impulsionado pela estratégia

Isto significa que os designers nem sempre são "livres" para criar a solução mais adequada para o negócio, Uma vez que não cai dentro das restrições impostas, conforme ilustrado na Figura 3.13. A limitação mais óbvia é o financeiro. Pode haver insuficiente orçamento disponível para a solução mais adequada, portanto, uma alternativa mais barata serviço teria que ser identificadas e acordadas com o negócio. O designer só pode fornecer a solução que se encaixa dentro de todas as limitações atualmente conhecidos, ou então tentar levantar ou renegociação de alguns dos constrangimentos - por exemplo, através da obtenção de um orçamento maior. Na Figura 3.13, não só será mais do orçamento devem ser obtidas para implementar a solução desejada, mas também por não-conformidade com algumas das normas e regulamentos pertinentes. Portanto, neste caso uma alternativa, a solução mais barata compatível seria provavelmente necessário. Assim, o Design de Serviços processos deve reconhecer o fato de que eles estão livres para soluções de design, mas eles estão trabalhando em um ambiente onde muitos fatores externos podem influenciar o projeto.

ITIL V3 - Service Design - Página:

88 de 477

Clique na imagem acima para ver uma versão maior em uma nova janela do navegador

Muitas dessas influências externas são da necessidade de corporativa e de TI governo, E os outros são a partir do requisito de acordo com os regulamentos, legislação e as normas internacionais, como ilustrado na Figura 3.14. É essencial, portanto, que todos os designers reconhecê-las e garantir que os projetos e as soluções que eles produzem tem todo o necessário controlars e capacidade dentro deles.

ITIL V3 - Service Design - Página:

89 de 477

3,9 Arquitetura Orientada a Serviços Processo de negócio e as soluções devem ser concebidos e desenvolvidos utilizando uma Arquitetura Orientada a Serviços abordagem (SOA). A abordagem SOA é considerado melhores práticas e é usado por muitas organizações para melhorar a sua eficácia e eficiência na prestação de De serviços de TIs. SOA é definido pela OASIS (www.oasis-open.org) como: 'Um paradigma para organizar e utilizando as capacidades distribuídas que podem estar sob o controle de diferentes domínios proprietários. Ele fornece um método uniforme para oferecer, descobrir, interagir e usar os recursos para produzir efeitos desejados consistentes com condições mensuráveis e expectativas. " OASIS (Organização para o Avanço de Padrões de Informação Estruturada) é um sem fins lucrativos consórcio internacional, que impulsiona o desenvolvimento, Convergência e adoção de padrões de e-business. SOA traz valor e agilidade a um organização incentivando o desenvolvimento de "autosuficientes" serviços que são reutilizáveis. Isto, por sua vez, promove uma abordagem modular e flexível para o desenvolvimento de "serviços partilhados" que podem ser usados em muitas áreas diferentes do negócio. Mais e mais organizações estão a converter os processos de negócio de "pacotes de serviços" comuns que podem ser usados e compartilhados por muitas áreas do negócio. Sempre que possível, Provedor de serviços de TI organizações devem usar o SOA e princípios para desenvolver flexíveis, reutilizáveis de serviços de TI que são comuns e podem ser compartilhadas e exploradas por diversas áreas do negócio. Quando este método é usado, é essencial que a TI: • • • • • •

Define e determina o que é um serviço é Entende e identifica claramente as interfaces e dependências entre os serviços Utiliza padrões para o desenvolvimento e definição de serviços Utiliza tecnologia comum e conjunto de ferramentas Investiga e compreende o impacto de mudars de "serviços partilhados" Garante que SOA relacionada treinamento foi planejado e realizado para o povo de TI, a fim de estabelecer uma linguagem comum e melhorar a implementação e e dos serviços novos ou alterados.

Quando os princípios de SOA são utilizadas pela organização de TI do prestador de serviços, é fundamental que um preciso Catálogo de Serviços é mantido como parte de uma estratégia global Portfólio de Serviços e Sistema de Gerenciamento da Configuração (CMS). Adotando essa abordagem pode reduzir significativamente o tempo necessário para fornecer novas soluções para o negócio e avançar para um Business Service Management (BSM) capacidade.

ITIL V3 - Service Design - Página:

90 de 477

O Catálogo de Serviços também irá mostrar o relação entre serviços e aplicaçãos. Uma única aplicação pode ser parte de mais de um serviço, e um único serviço poderia utilizar mais de um aplicativo.

ITIL V3 - Service Design - Página:

91 de 477

3,10 Business Service Management Business Service Management (BSM) é um estratégia e uma abordagem para permitir TI componentes para ser ligada aos objetivos do negócio. Desta forma, o impacto da tecnologia sobre os negócios e como a mudança negócio pode impactar tanto a tecnologia pode ser previsto. A criação de um Catálogo de Serviço totalmente integrada - incluindo unidade de negócioss, processos e serviços, e suas relações e dependências de De serviços de TIA tecnologia e os componentes - é crucial para aumentar a capacidade do provedor de serviços de TI para entregar BSM. Todos os aspectos da Design de Serviços são elementos vitais para apoiar e aprimorar os negócios Serviço de Gestão de capacidade do Provedor de serviços de TI, Particularmente o projeto do portfólio de serviços, o Catálogo de Serviços e as individuais de serviços de TI. Todas essas atividades também irá melhorar o alinhamento da TI com os negócios de prestação de serviços e de suas necessidades em evolução. Veja a Figura 3.15. BSM permite que uma organização de TI provedor de serviço para: • • • • • • • • •

Alinhar a TI com os objetivos de prestação de serviços de negócios e objetivos Priorizar todas as atividades de TI no impacto nos negócios e urgência, Assegurando crítico processo de negócioes e serviços recebem mais atenção Aumentar a produtividade ea lucratividade do negócio através do aumento da eficiência e eficácia dos processos de TI ar os requisitos para empresas governo com governança de TI apropriada e controlars Criar vantagem competitiva através da exploração e inovação da infraestrutura de TI como um todo Melhorar o serviço qualidade, Satisfação do cliente e usuário percepção Garantir a conformidade regulamentar e legislativo Garantir níveis adequados de protecção em todas as TI e os ativos de informação Garantir que os serviços de TI estão alinhados e continuar a estar alinhado com as necessidades de negócio.

Figura 3.15 ilustra a relação de serviço actividades e Serviço de Gestão deE do alcance e da faixa que eles oferecem em termos de valor para o negócio e TI.

ITIL V3 - Service Design - Página:

92 de 477

Figura 3.15 O contínuo de gestão de TI

ITIL V3 - Service Design - Página:

93 de 477

3,11 design modelos de serviço O modelo seleccionado para o projeto de serviços de TI vai depender principalmente do modelo selecionado para a entrega de serviços de TI. Antes de adotar um modelo de design para um serviço novo e importante, uma rever da corrente capacidade e disposições em relação a todos os aspectos da entrega de serviços de TI devem ser realizados. Esta avaliação deve considerar todos os aspectos do novo serviço, incluindo a: • • • • • • • • • •

Drivers de negócio e requisitos Escopo e capacidade do actual provedor de serviços unidade Demandas, metas e requisitos do novo serviço Alcance e capacidade de externo fornecedors Maturidade do organizaçãos presentemente envolvidas e da sua processoes Cultura das organizações envolvidas Infra-estrutura de TI,aplicaçãos, dados, serviços e outros componentes envolvidos Grau de corporativa e de TI governo eo nível de propriedade e controle necessários Orçamentos e recursos disponível Níveis de pessoal e competências.

Esta avaliação /avaliação fornece um mecanismo estruturado para determinar as capacidades de uma organização e do estado de prontidão para a oferta de novos serviços ou revistas em e de drivers de negócio definidas e exigências. A informação obtida a partir de tal avaliação pode ser utilizado na determinação da distribuição estratégia para um serviço de TI em particular ou sistema de TI. A entrega estratégia é o método utilizado para mover uma organização de um estado conhecido, com base na avaliação de prontidão, para um estado desejado, a determinação dos drivers de negócio e necessidades. Existem muitas maneiras de preparar um organização para a implantação de um novo serviço. O método e estratégia escolhida deve ser baseado na solução a organização escolhe para o cumprimento de seus drivers de negócios-chave, bem como as capacidades da organização de TI e seus parceiros. A escala de opções disponíveis é muito grande, e não todas as necessidades opção ser considerado em todos os casos. No entanto, manter todas as opções disponíveis para a consideração é fundamental para a concepção e operação de soluções inovadoras para os desafios de negócios mais difíceis. No final, este pode ser a diferença entre uma falha projeto - Ou mesmo uma empresa falhou e um sucesso. Estes dois modelos, para os serviços de projeto e entrega de TI, estão intimamente relacionados e são considerados nas duas secções seguintes.

ITIL V3 - Service Design - Página:

94 de 477

3.11.1 modelo opções de entrega Embora a avaliação de prontidão determina a diferença entre os recursos atuais e desejado, uma organização de TI não deve, necessariamente, tentar preencher essa lacuna por si só. Há muitas estratégias diferentes de entrega que podem ser utilizados. Cada um tem seu próprio conjunto de vantagens e desvantagens, mas todas elas requerem algum nível de adaptação e personalização para a situação em questão. Tabela 3.2 lista as principais categorias de estratégias de sourcing com um pequeno resumo de cada um. Entrega práticas tendem a cair em uma dessas categorias ou alguma variante deles. Estratégia de entrega

Descrição

Insourcing

Esta abordagem baseia-se na utilização de recursos internos da organização no projeto,desenvolvimento,transição, A manutenção, operação e / ou apoio de novo, alterado ou revisto serviços ou operações de data center

Terceirização

Esta abordagem utiliza o recursos de uma organização externa ou organizações em um acordo formal para fornecer uma parte bem definida de um serviço de design, desenvolvimento, manutenção, operações e / ou apoio. Isto inclui o uso de serviços a partir de Provedores de Serviços de Aplicação (ASPs) descrito abaixo

Co-sourcing

Muitas vezes, uma combinação de insourcing e terceirização, usando um número de organizações de terceirização trabalhando juntos para elementos co-fonte-chave na ciclo de vida. Isto geralmente envolve o uso de um número de externa organizaçãos trabalhando juntos para projetar, desenvolver, transição, Manter operar e / ou ar uma porção de um serviço

Parceria ou multi-sourcing

Acordos formais entre duas ou mais organizações de trabalhar juntos para projetar, desenvolver, transição, Manter, operar e / ou apoio De serviços de TI(S). O foco aqui tende a ser em estratégico parcerias que utilizar o conhecimento crítico ou oportunidades de mercado.

Business Process Outsourcing (BPO)

A tendência crescente de deslocalização funções empresariais inteiros usando acordos formais entre as organizações onde uma organização fornece e gerencia o processo de outra organização de negócios de todo (s) ou funções (s) em um local de baixo custo. Exemplos comuns são folha de pagamento, contabilidade e call center operações

Prestação de Serviços de Aplicativos

Envolve acordos formais com um Application Service Provider (ASP) a organização que irá fornecer o Shared Computer baseados em serviços para organizações clientes através de uma rede. Aplicaçãos oferecidos desta forma são também por vezes referido como software on-demand / aplicações. Através ASPs, as complexidades e custars de software compartilhado pode ser reduzida, desde a organizações que poderiam de outra forma não justificam o investimento

Knowledge Process

A mais nova forma de terceirização, KPO é um o à frente de BPO em um aspecto. Organizações KPO fornecer baseada em domínio processoes e

ITIL V3 - Service Design - Página:

95 de 477

Outsourcing (KPO)

conhecimento de negócio e não apenas conhecimento de processo, e exigem habilidades avançadas de análise e especializado a partir da organização de terceirização

Tabela 3.2 Principais estratégias de entrega de serviços

Tabela 3.2 destaca um ponto chave: o conjunto de estratégias de entrega varia muito e varia de uma situação relativamente simples, apenas conseguiu dentro dos limites de uma empresa, todo o caminho para uma situação KPO completo. Esta ampla gama de alternativas proporciona uma flexibilidade significativa, mas geralmente com uma complexidade adicional e, em alguns casos adicionais risco. As vantagens e desvantagens de cada tipo de parto estratégia são discutidos na Tabela 3.3 a seguir. Todas as disposições acima referidas podem ser fornecidos em ambos um offshore ou em terra situação. No caso em terra, ambas as organizações são baseadas no mesmo país / continente, enquanto que na situação off-shore as organizações estão em diferentes países / continentes. Muito complexos arranjos de terceirização existem dentro da indústria de TI e é impossível cobrir todas as combinações e suas implicações aqui. ITIL Service Série Prática de Gestão Complementar irá fornecer orientações sobre estratégias de abastecimento. Fusões e aquisições podem também complicar as questões. Estas situações ocorrem quando uma empresa adquire ou se funde com outra empresa por dinheiro e / ou equidade swaps de ações da empresa. Mais uma vez, isso ocorre geralmente em resposta a consolidação da indústria, a expansão do mercado, ou em resposta direta às pressões competitivas. Se as empresas que têm estratégias diferentes de entrega de serviços são adquiridos ou mesclar, um período de revisão e consolidação é muitas vezes necessária para determinar o fornecimento mais adequado estratégia para a organização recém-fundidas. No entanto, as fusões e aquisições muitas vezes pode fornecer organizaçãos com a oportunidade de consolidar o melhores práticas de cada organização, melhorando assim o serviço global capacidade e obtenção de sinergias em toda a organização. Oportunidades também existem para fornecer melhores opções de desenvolvimento de carreira para Serviço de Gestão de pessoal e para a consolidação fornecedor contrato para serviços.

3.11.2 Design e opções de desenvolvimento As estratégias de entrega são relevantes para ambos o projeto e transição as fases do ciclo de vida de serviço, bem como a fase de operação. Extremo cuidado deve ser tomado ao selecionar estratégias diferentes para diferentes fases do ciclo de vida para assegurar que todas as organizações envolvidas compreender claramente os seus papéis e responsabilidades individuais, e também todos os outros da organização papel ea responsabilidade de assegurar

ITIL V3 - Service Design - Página:

96 de 477

aceitação e entrega de processos estão claramente definidos, acordados e aceites. Um banco de tamanho médio se fundiu com outro banco que tinha um portfólio de produtos complementares. Por isso a integração de aplicaçãos era simples. No entanto, os dois bancos sentiram que a consolidação das operações seria benéfico, mas não conseguiu alavancar o economias de escala a um nível suficiente. Terceirização também foi uma opção, mas sim os dois bancos escolhemos fazer parceria com uma empresa terceirizada. Os bancos forneceu o conhecimento específico do banco para fazer a sua De serviços de TIa organização de um centro de dados atraentes para os bancos menores. O parceiro de outsourcing, desde a experiência e tecnologia necessária nova clientes beneficiar das economias de escala. Então como é que uma organização a determinar a entrega ideal estratégia? Não há uma resposta única ou simples para esta pergunta. É muito dependente da situação singular e específico em estudo. Por esta razão, a orientação mais conveniente que pode ser fornecida é descrever as principais vantagens e desvantagens de cada uma das estratégias de entrega. Isto, por sua vez, pode ser usado como uma lista de verificação para determinar qual a abordagem de entrega deve ser melhor avaliada e beneficiar mais específico projeto ou iniciativa empresarial. Tabela 3.3 lista cada estratégia e suas principais vantagens e desvantagens para a entrega de uma aplicação ou serviço de TI.

ITIL V3 - Service Design - Página:

97 de 477

Estratégia de entrega

Vantagens

Desvantagens

Insourcing

Dirigir controlar Liberdade de escolha Prototipagem rápida de ponta serviços Políticas familiares e processoes Empresa de conhecimentos específicos

Limitações de escala Custo e tempo de mercado para serviços prontamente disponíveis fora Dependente interno recursos e suas habilidades e competências

Terceirização

Economias de escala Conhecimentos adquiridos a foco nas competências essenciais da empresa e para necessidades transitórias Test drive / trial de novos serviços

Menos controle direto Barreiras de saída Risco de solvência de fornecedors Desconhecido habilidades e competências fornecedor Mais desafiador processo de negócio integração Aumento governo e verificação

Co-sourcing

Tempo de mercado Conhecimentos alavancados Controlar Uso de fornecedores especializados

A complexidade do projeto Propriedade intelectual e proteção de direitos autorais Cultura choque entre empresas

Parceria ou multisourcing

Tempo de mercado Expansão do mercado / entrada Resposta competitiva Conhecimentos alavancados Alinhamento, confiança e benefício mútuo 'Risco e recompensa' acordos

A complexidade do projeto Propriedade intelectual e proteção de direitos autorais O choque de culturas entre as empresas

Business Process Outsourcing (BPO)

Único ponto de "Balcão Único" responsabilidade O o a competências especializadas Risco transferido para o contratante Baixo custo de localização

O choque de culturas entre as empresas Perda de conhecimento do negócio Perda de relação com o negócio

Prestação de Serviços de Aplicativos

O o a soluções caras e complexas Baixo custo de localização e e atualizações incluído Segurança e opções ITSCM incluído

O choque de culturas entre as empresas o às instalações apenas, não o conhecimento Muitas vezes com base em uso de carregamento modelos

Knowledge Process Outsourcing (KPO)

O o a competências especializadas, conhecimento e experiência Baixo custo de localização

O choque de culturas entre as empresas Perda de competências internas Perda da relação com o negócio

ITIL V3 - Service Design - Página:

98 de 477

Significativas economias de custo

Tabela 3.3 Vantagens e desvantagens das estratégias de prestação de serviços

O estratégia seleccionado dependerá da capacidade e as necessidades da organização específica, o seu negócio e as pessoas - cultura e capacidades. Qualquer que seja a estratégia é selecionada, seu sucesso e operação devem ser medidos e revistos regularmente para eficácia e eficiência e adaptado para atender às necessidades empresariais em constante mudança. A seleção adotado em relação à De serviços de TI prestação muitas vezes pode ser influenciado pela cultura global de negócios e sua abordagem para terceirização e parcerias.

3.11.3 abordagens de projeto e desenvolvimento Também é importante compreender o genérico atual ciclo de vida tipos, métodos e abordagens para o serviço de TI desenvolvimento, A fim de decidir sobre as normas para o Design de Serviços fase do ciclo de vida. Para isso, um bom entendimento é necessário os seguintes aspectos dos vários Ciclo de Vida Serviço de Desenvolvimento (SDLC) abordagens: • • •

A estrutura (por exemplo, metas / etapas / fases) As atividades (por exemplo, os fluxos de trabalho ou detalhados os / tarefas descritas dentro de uma abordagem) Os modelos primários associados com o método escolhido, geralmente com uma perspectiva de processo, de uma perspectiva de dados, uma evento perspectiva e, muitas vezes, um usuário perspectiva. Exemplos incluem caso de uso , diagramas de classe e diagramas de gráfico de estado da Unified Modeling Language (UML).

Há mais detalhes sobre SDLC no Capítulo 5. 3.11.3.1 Rapid Application Development

É necessário compreender as diferenças entre orientada a objetos e estruturada de desenvolvimento de sistemas, os princípios básicos do "Agile" (Rapid Application Development (RAD) ou o desenvolvimento acelerado são outros termos usados na área) movimento e reconhecer como um compromisso com a uma solução de pacote de software modifica a estrutura da abordagem. Estas abordagens, que por padrão abordar um único sistema (e relacionado serviços) apenas, pode ser completada por abordagens de arquitecturas, tais como aqueles baseados em componente baseado reutilização (ver a secção sobre arquitetura para discussão). O ciclo de vida do aplicativo modelo descrito na seção sobre Gestão de Aplicações (seção 5.1.3) pode ser visto como um exemplo de linear ou "cascata" ITIL V3 - Service Design - Página:

99 de 477

(ou modelo 'V') abordagem baseada, e não serão discutidos em mais detalhes aqui, exceto para fins de comparação com outras abordagens. A principal característica da RAD é a introdução de incrementos e iterações no desenvolvimento processo para a gestão dos riscos associados com a incerteza e mudanças de requisitos. As abordagens tradicionais têm assumido que um conjunto completo de requisitos pode ser definida no início do ciclo de vida e que o desenvolvimento custars pode ser controlado através da gestão mudar. No entanto, a mudança pode significar desanimador sendo indiferente às condições do negócio. Abordagens RAD aceitar que a mudança é inevitável e tentativa de minimizar os custos de responder a elas, mantendo a necessária qualidade. O uso de incrementos implica que um serviço é desenvolvido peça por peça, onde cada peça poderia apoiar uma das funções de negócios que as necessidades de todo o serviço. Entrega incremental pode resultar em menor tempo de mercado para funções específicas do negócio. O desenvolvimento de cada incremento requer agem de todos ciclo de vida fases. O desenvolvimento iterativo implica que o ciclo de vida vai ser percorrido mais de uma vez, por design. Técnicas como a prototipagem são usados para obter uma melhor compreensão dos requisitos (por meio de testes, gestão e funcional operacional atividades e através da comunicação com usuários). Combinações de iterativo e abordagens incrementais são possíveis. É possível começar com a especificação de requisitos para o serviço completo, seguindose a projeto e ao desenvolvimento do aplicação incremental. Métodos de desenvolvimento RAD, incluindo o Processo Unificado e Método de Desenvolvimento de Sistemas Dinâmicos (DSDM) são vistos como uma resposta às expectativas de negócios, com o objetivo de reduzir o custo da mudança ao longo de um desenvolvimento projeto. DSDM utiliza contínua usuário envolvimento em um desenvolvimento iterativo e abordagem incremental, que é sensível às mudanças de requisitos, para desenvolver um sistema de software que satisfaça os requisitos de negócio no tempo e no orçamento. Outro exemplo, Extreme Programming (XP), apela para os desenvolvedores: • • • • •

Produzir um serviço de entrega primeira semana, para conseguir uma vitória inicial e retorno rápido Inventar soluções simples, para que haja menos de modificar e também facilitar a mudança Melhorar a qualidade do projeto continuamente Teste precoce para menos caro de busca de avarias Use disciplinas básicas, tais como revers, configuração e gestão da mudança para manter o controle.

ITIL V3 - Service Design - Página:

100 de 477

Para fazer bom uso de uma abordagem incremental, o projeto processo tem de ser baseada numa separação de interesses, Agrupando as funções dentro de incrementos, de tal modo que a sua interdependência é minimizado. Em termos gerais, métodos de desenvolvimento acelerado de aplicações adotar um modelo de três fases do ciclo de vida: análise acelerado e design, desenvolvimento, tempo encaixotado e produção e implementação. Os métodos são normalmente apoiadas por tecnologia de engenharia de software, e dependem de articulação (IT-usuário) Trabalhando e prototipagem rápida para definir os requisitos e criar um protótipo funcional. A partir de um perspectiva de negócios, O uso de desenvolvimento incremental e entrega por desenvolvedores significa que uma parte, válido distinta do serviço global pode ser entregue antes de a equipe de desenvolvimento está em uma posição para concluir todo o projeto. Esta abordagem oferece benefícios imediatos para a negócio, E oferece uma oportunidade para os empresários e equipe de desenvolvimento para descobrir emergente serviço propriedades e aprender com a sua experiência. No entanto, muitas vezes é difícil encontrar um incremento suficientemente pequeno primeiro que pode proporcionar um serviço significativo para os negócios. Métodos que incorporem RAD iteração e entrega incremental pode ser usado para reduzir o desenvolvimento e os riscos de implementação. O real projetos pode não ser necessariamente mais fácil de gerir, mas eles podem facilitar a implementação e aceitação. Eles oferecem mais opções de contingência e permitir aos desenvolvedores a lidar com a mudança de requisitos de negócio e das condições ambientais. Eles também fornecem ambos os marcos e pontos de decisão para fins de controle do projeto. Estes métodos podem adicionalmente ser utilizadas para: • • •

Alcançar ou convergir para um desenho aceitável para o cliente e viáveis para a equipe de desenvolvimento Limitar a exposição do projeto para os elementos imprevisíveis de negócios e mudança ambiental Economize tempo de desenvolvimento, embora para um projeto RAD sucesso, algo diferente de programação deve ser negociável. (RAD tem a melhor chance de sucesso se o negócio está disposto a negociar sobre a funcionalidade e qualidade).

Importantes Desenvolvimento Rápido de Aplicações (RAD) restrições ou Fator Crítico de Sucessos (QCA) incluem: • •

'Aptidão para fins comerciais ", como o critério para aceitação de entregas Representação de todas as partes que podem afetar os requisitos de aplicação em todo o desenvolvimento processo

ITIL V3 - Service Design - Página:

101 de 477

•

• • • •

Clientes, desenvolvedores e gerência aceitar entregas informais, por exemplo, notas de usuário oficinas em vez de documentos formais exigências Criando a documentação mínima necessária para facilitar o futuro desenvolvimento e manutenção Capacitação das equipes de desenvolvimento para tomar decisões tradicionalmente esquerda para a gestão Iteração ser usado de tal maneira a convergir para uma solução comercial aceitável Protótipos que podem incorporar requisitos em evolução rapidamente, para obter consenso no início da ciclo de vida.

A utilização de abordagens RAD requer qualificados, equipes multidisciplinares, que são capazes de aconselhar sobre quando aplicar essas abordagens. Categoria

Desenvolvimento convencional

Desenvolvimento acelerado

Abordagem geral

Fases seqüenciais

Evolutivo

Usuário comprometimento de recursos

± 15% durante todo o projeto

100% ao longo do projeto para patrocinador do projeto, ± 30% para os outros selecionados

Risco

Superior - projeto de longo prazo problemas não podem surgir até bem dentro do projeto de desenvolvimento

Abaixe - superfície problemas no início da desenvolvimento processo rápido e que exige resolução

Patrocínio executivo

Tem autoridade de aprovação, mas não ativamente envolvidos

Elevada participação - conjuntos escopo, Analisa os progressos e problemas resolve

Utilização de técnicas conjuntas de iteração sessão, e prototipagem

Opcional

Exigido

Habilidades desenvolvedor

Especialistas, alguns com experiência limitada aceitável

Altamente experientes, multiqualificados profissionais necessários

Utilização de processo tecnologia de e, por exemplo, Ferramentas CASE

Opcional

Exigido

Estrutura da equipe

Normalmente grande com conjuntos de habilidades especializadas

Geralmente, os pequenos com conjuntos de habilidades gerais, complementadas por especialistas como necessária

Gerenciamento de escopo rigorosa

Necessário

Crítico

ITIL V3 - Service Design - Página:

102 de 477

Estrutura de fase

Fases 4-5

3 fases

Responsabilidade individual

Difícil avaliar

Prestação de contas precisa

Comparação Tabela 3.4 entre as abordagens convencionais ("cascata") e RAD 3.11.3.2 Off-the-shelf soluções

Muitos organizaçãos agora escolher a cumprir seu De serviços de TI requisitos através de compra e implementação de comercial off-the-shelf (COTS) pacote de soluções de software. Uma estrutura para selecionar, personalizar e implementar essas soluções off-the-shelf embalados é necessário e inclui a necessidade de: • • • • • • • • •

Compreender plenamente as vantagens e desvantagens da abordagem pacote Definir um quadro de seleção eficaz pacote de software Definir um quadro de personalização e integração eficaz Definir os requisitos funcionais ao nível adequado Desenvolver uma lista de gestão e operacional requisitos Definir o produto e fornecedor requisitos Definir os requisitos de integração de serviços Identificar e investigar possíveis off-the-shelf soluções de pacotes de software Apresentar recomendações sobre o ataque de um pacote de software selecionado off-the-shelf contra os requisitos acordados, e definir as implicações desta.

Padrões detalhados serão necessários em: • • •

Pacotes e prototipagem Definição da estrutura de ponderação avaliação matrizes Iteração na seleção de pacotes.

Adicionalmente, procedimentos para avaliar e comparar pacotes de concorrentes em termos de customização / integração requisitos são necessários e devem incluir: • • • •

Avaliando o jogo funcional Manifestações escritas e de avaliação orientada para o utilizador Avaliando a partida de gestão e operacionais Avaliando os requisitos de implementação corresponder.

Normas para documentar os requisitos antes da investigação de mercado pacote deve incluir aqueles especificamente mostrando:

ITIL V3 - Service Design - Página:

103 de 477

• • • • • • •

Funções de alto nível (para fins de definição de escopo) Funções de negócios e eventos significativos De entrada e de requisitos de saída Dados (estático) estruturas Identificar relaçãos entre essas estruturas, funções e eventos Serviço em toda a gestão e requisitos operacionais Requisitos não-funcionais, tais como atuação,rendimento, Desastre recuperação capacidades de infra-estrutura e segurança padrões.

Ao avaliar soluções COTS, considere as seguintes três maneiras em que um exigência pode ser cumprida: • •

•

Disponível off-the-shelf Pode ser configurado. Estimar o esforço para executar a configuração. Isso só precisa ser feito uma vez e será preservado ao longo atualizações do produto Deve ser personalizado. Estimar o esforço para realizar a personalização inicialmente e repeti-lo em cada atualização do produto, tendo em conta que o conceito de personalização pode não ser aplicável a futuros lançamentos.

Também investigar a estratégia e plano de lançamento do pacote fornecedor e verificar se ele está alinhado ao seu, e em que medida se pode esperar suas necessidades futuras a serem cumpridas pelo pacote.

ITIL V3 - Service Design - Página:

104 de 477

4 design processos de serviço Este capítulo descreve e explica os fundamentos dos principais processos de design de apoio de serviço. Estes processos são os principais responsáveis por fornecer informações importantes para o projeto de soluções de serviços novos ou alterados. Há cinco aspectos de design que precisam ser considerados: • • • • •

O design dos serviços, incluindo todos os requisitos funcionais, recursos e as capacidades necessárias e acordadas A concepção de Serviço de Gestão de sistemas e ferramentas, em especial os Portfólio de Serviços, Para a gestão e controlar de serviços por meio de sua ciclo de vida O design das arquiteturas de tecnologia e sistema de gestãos necessária para fornecer o serviços O desenho dos processos necessários para projetar, transição,operar e melhorar a atenção, os arquiteturas e os processos próprios O design dos métodos de medição e métricas dos serviços, as arquitecturas e seu constituinte componentes e os processos.

Uma abordagem baseada em resultados devem ser adoptadas para cada um dos cinco aspectos acima. Em cada um, o negócio desejado resultados e os resultados planejados deve ser definido de modo que o que é entregue atende às expectativas do clientes e usuários. Assim, esta abordagem estruturada devem ser adoptadas em cada um dos cinco aspectos para entregar qualidade, Consistência repetível e melhoria contínua em todo o organização. Não há situações dentro De serviços de TI próvisão com interno ou externo provedor de serviçoss em que não há processos no Design de Serviços área. Todos Provedor de serviços de TI organizações já têm alguns elementos de sua abordagem a estes aspectos cinco no lugar, não importa o quão básica. Antes de iniciar a implementação da melhoria das atividades e processos, uma rever deve ser conduzida de quais elementos estão no lugar e trabalhando com sucesso. Muitos provedor de serviços organizações já têm maturidade processoes no lugar para a concepção de serviços de TI e soluções. Todos os projetos e atividades do projeto precisam ser impulsionados principalmente pelas necessidades e requisitos de negócio da organização. Dentro deste contexto, também deve refletir as necessidades das estratégias, planos e políticas produzidas por Estratégia de Serviço processos, tal como ilustrado na Figura 4.1.

ITIL V3 - Service Design - Página:

105 de 477

Figura 4.1 As ligações principais, entradas e saídas de Design de Serviços

Figura 4.1 dá uma boa visão geral das ligações, entradas e saídas envolvidos em cada fase do ciclo de vida de serviços. Ela ilustra os principais resultados produzidos por cada fase, os quais são usados como entradas pelas fases subsequentes. O Portfólio de Serviços atua como "a coluna vertebral" do Ciclo de Vida do Serviço. É a única fonte integrada de informações sobre o estado de cada serviço, juntamente com outros detalhes do serviço e as interfaces e dependências entre serviços. A informação na Carteira de serviço é usado pelas atividades dentro de cada fase do ciclo de vida de serviços. O resultado fundamental do Design de Serviços estágio é o projeto de soluções de serviços para atender as novas exigências do negócio. No entanto, ao projetar essas soluções, a entrada de diversas áreas precisa ser considerado dentro das diversas atividades envolvidas na concepção da solução de serviços, desde a identificação e análise de requisitos, até a construção de uma solução e SDP a entregar a Transição de Serviço.

ITIL V3 - Service Design - Página:

106 de 477

A fim de desenvolver soluções de serviços eficazes e eficientes que atendam e continuam a cumprir os requisitos do negócio e as necessidades de TI, é essencial que todas as entradas e as necessidades de todas as outras áreas e processos são reconsiderados dentro de cada uma das atividades do projeto de serviço , como ilustrado na Figura 4.2. Isso irá garantir que todas as soluções de serviços são coerentes e compatíveis com as soluções existentes e irá satisfazer as expectativas dos clientes e usuários. Isso vai ser mais eficazes, consolidando essas facetas da chave processoes em todas essas atividades de design de serviço, de modo que todas as entradas são automaticamente referenciado toda vez que uma solução de serviço novo ou alterado é produzido.

Figura 4.2 Service Design - a grande imagem

ITIL V3 - Service Design - Página:

107 de 477

4.1 Gestão Catálogo de Serviços 4.1.1 Finalidade objetivo / / objetivo O objetivo da Gestão Catálogo de Serviço é oferecer uma única fonte de informações consistentes sobre todos os serviços acordados, e garantir que ele está amplamente disponível para aqueles que são aprovados para á-lo. O objectivo do processo de gestão de serviço de catálogo é o de assegurar que um Catálogo de Serviços é produzido e mantido, contendo informação precisa sobre todos operacional serviços e aqueles que estão sendo preparados para ser executado operacionalmente. O objetivo Gestão de Catálogo de Serviço é gerenciar as informações contidas dentro do Catálogo de Serviço, e para garantir que ele está correto e reflete os detalhes atuais, estado, Interfaces e dependências de todos os serviços que estão sendo executados, ou sendo preparado para correr, no viver ambiente.

4.1.2 Âmbito O escopo do processo de Gerenciamento de Catálogo de Serviço é fornecer e manter informações precisas sobre todos os serviços que estão sendo transitaram ou foram transferidos para o meio ambiente ao vivo. As atividades de serviços de Gestão Catálogo deve incluir: • • • • •

Definição de serviço Produção e manutenção de um preciso Catálogo de Serviços Interfaces, dependências e de consistência entre o Catálogo de Serviços e Portfólio de Serviços Interfaces e dependências entre todos serviços e serviços de apoios dentro do Catálogo de Serviço e da CMS Interfaces e dependências entre todos os serviços, e de apoio componentes e Item de Configuraçãos (IC) dentro do Catálogo de Serviço e da CMS.

4.1.3 Valor para o negócio O Catálogo de Serviços é uma fonte central de informações sobre os serviços de TI entregues pelo provedor de serviços organização. Isto assegura que todas as áreas do negócio pode ver uma imagem precisa e consistente do De serviços de TIs, os seus pormenores e suas estado. Ele contém uma vista de frente para o cliente dos serviços de TI em uso, como se se destinam a ser utilizadas, o processo de negócioes que permitem, e os níveis e qualidade do serviço de cliente pode esperar para cada serviço. ITIL V3 - Service Design - Página:

108 de 477

4.1.4 Políticas, princípios e conceitos básicos Ao longo dos anos, as organizações " Infra-estrutura de TIs têm crescido e se desenvolvido, e não pode ser uma visão clara de todos os serviços atualmente prestados e os clientes de cada serviço. A fim de estabelecer um quadro preciso, recomenda-se que um portfólio de serviços de TI contendo um Catálogo de Serviços é produzido e mantido para fornecer um conjunto central de informações precisas sobre todos os serviços e desenvolver um serviço com foco cultura. O portfólio de serviços deve conter todos os requisitos futuros de serviços e do Catálogo de Serviço deve conter detalhes de todos serviços sendo fornecido ou aqueles que estão sendo preparados para transição para o meio ambiente ao vivo, um resumo de suas características, e os detalhes dos clientes e mantenedores de cada um. Um grau de "trabalho de detetive" podem ser necessários para compilar essa lista e concorda com os clientes (peneirar documentação antiga, procurando bibliotecas de programas, falando com a equipe de TI e os clientes, olhando para aquisições registros e conversando com fornecedors e empreiteiros, etc.) Se um CMS ou qualquer tipo de banco de dados ativo existe, estes podem fornecer valiosas fontes de informação, embora eles devem ser verificados antes da inclusão dentro ou o Serviço de Carteira ou Catálogo de Serviços. O Portfólio de Serviços é produzido como parte de Estratégia de Serviço e deve incluir a participação de todos os envolvidos em Design de Serviço, Transição, Operação e Melhoria. Uma vez que um serviço é 'fretado' (a ser desenvolvido para uso por clientes, Design de Serviços produz o especificaçãos para o serviço e é neste ponto que o serviço deve ser adicionado ao Catálogo de Serviços. Cada organização deve desenvolver e manter um política no que diz respeito tanto à Carteira do eo Catálogo, relativo aos serviços gravadas no seu interior, o que os detalhes são gravados e o status são gravadas para cada um dos serviços. A política deve conter também informações sobre as responsabilidades de cada seção do portfólio de serviços em geral e do escopo de cada uma das secções que o constituem. O serviço de processo de Gestão de Catálogo produz e mantém o Catálogo de Serviços, garantindo que uma fonte central, precisa e consistente dos dados é fornecido, registrando a estado de todos operacional serviços ou serviços a ser transferida para o viver ambiente, Juntamente com os detalhes adequados de cada serviço. O que é um serviço? Esta questão não é tão fácil de responder, pois pode parecer à primeira vista, e muitas organizações não conseguiram chegar a uma definição clara em um contexto de TI. A equipe de TI muitas vezes confundem um 'serviço' como é percebida pelo cliente com um sistema de TI. Em muitos casos, um "serviço" pode ser feito de outros "serviços" (e assim por diante), que

ITIL V3 - Service Design - Página:

109 de 477

são eles mesmos compostos de um ou mais sistemas de TI dentro de uma infraestrutura em geral, incluindo hardware, software, redes, juntamente com ambientes, dados e aplicaçãos. Um bom ponto de partida é muitas vezes a pedir aos clientes que os serviços de TI que eles usam e como os serviços de mapas para e apoiar a sua processo de negócioes. Os clientes muitas vezes têm uma maior clareza do que eles acreditam ser um serviço. Cada organização precisa desenvolver uma política de que é um serviço e como ele é definido e acordado dentro de sua própria organização. Para evitar confusão, pode ser uma boa idéia para definir uma hierarquia de serviços na Catálogo de Serviços, Qualificando exatamente que tipo de serviço é registrado, por exemplo, serviço de negócio (O que é visto pelo cliente). Alternativamente, serviços de apoios, tais como serviço de infra-estruturas serviços, de rede, serviços de aplicativos (todos invisíveis para o cliente, mas essencial para a prestação de serviços de TI) também precisam ser registradas. Isso muitas vezes dá origem a uma hierarquia de serviços incorporando serviços ao cliente e outros serviços relacionados, incluindo serviços de apoio, serviços compartilhados e serviços de commodities, cada um com definido e acordado nível de serviços. Quando inicialmente preenchido, o catálogo de serviço pode ser constituído por uma matriz de mesa, ou folha de cálculo. Muitas organizações integrar e manter a sua Portfólio de Serviços e Catálogo de Serviços como parte de seu CMS. Ao definir cada serviço como um Item de Configuração (IC) e, se for caso disso, relacionando-as de modo a formar uma hierarquia de serviço, o organização é capaz de se relacionar eventos tais como acidentes e RFCs aos serviços afectados, assim fornecendo a base para o serviço monitoramento e relatórios utilizando uma ferramenta integrada ('lista ou dar o número de incidentes que afectam este serviço particular ", por exemplo). Portanto, é essencial que as mudanças dentro do portfólio de serviços e Catálogo de Serviços estão sujeitos à Gestão da Mudança processo. O catálogo de serviço pode também ser utilizado para outros Serviço de Gestão de fins (por exemplo para a realização de um Análise de Impacto no Negócio (BIA) como parte da Continuidade do Serviço de TI Planejamento, Ou como um ponto de partida para re-distribuição carga de trabalhos, como parte de Gerenciamento da Capacidade). O custar e esforço de produzir e manter o catálogo, com a sua relaçãos para a tecnologia de sustentação componentes, é, portanto, facilmente justificável. Se isso for feito em conjunto com a definição de prioridades de BIA, então é possível garantir que os serviços mais importantes são cobertos em primeiro lugar. Um exemplo de um simples Catálogo de Serviços que pode ser usada como um ponto de partida é dado no Apêndice G. O Catálogo de Serviços tem dois aspectos:

ITIL V3 - Service Design - Página:

110 de 477

•

•

O Negócio Catálogo de Serviços: detalhes contendo de todos os serviços de TI entregues ao cliente, Em conjunto com as relações para o unidade de negócioss eo processo de negócios que dependem da De serviços de TIs. Esta é a opinião do cliente Catálogo de Serviços. O Catálogo de Serviços Técnicos: Contendo detalhes de todos os serviços de TI entregues ao cliente, juntamente com relações com os serviços de e, serviços compartilhados, componentes e CIs necessários para apoiar a prestação do serviço à negócio. Isto deve apoiar o Catálogo de Serviços de Negócios e não fazem parte da visão do cliente.

A relação entre estes dois aspectos é ilustrado na Figura 4.3.

Figura 4.3 O Catálogo de Serviços de Negócios e ao Catálogo de Serviços Técnicos

Algumas organizações só mantenham um Catálogo de Serviços de Negócios ou de um Catálogo de Serviços Técnicos. A situação preferida adoptada pelas organizações mais maduras mantém ambos os aspectos dentro de um catálogo de serviço única, que é parte de um totalmente integrado Serviço de Gestão de atividade e Portfólio de Serviços. Mais informações sobre o projeto e conteúdo de um Catálogo de Serviços está contido no Anexo G. O Catálogo de Serviços de Negócios facilita o desenvolvimento de um processo SLM muito mais próativo ou até mesmo preventiva, permitindo que ela desenvolva mais no campo de Business Service Management. O Catálogo de Serviço Técnico é extremamente benéfica ao construir a relação entre os serviços, SLAs, e esteio OLAs outro acordos e componentes, uma vez que irá identificar a tecnologia

ITIL V3 - Service Design - Página:

111 de 477

necessária para ar um serviço eo grupo de apoio(S) que am os componentes. A combinação de um Catálogo de Serviços de Negócios e um Catálogo de Serviços Técnicos é de valor inestimável para avaliar rapidamente o impacto de incidentes e mudars no negócio. Um exemplo de relações entre as partes de negócios e técnicas de um Catálogo de Serviços é mostrada na Figura 4.4.

Figura 4.4 Exemplo de Catálogo de Serviço

4.1.5 as atividades de processo, métodos e técnicas As principais atividades dentro do processo de Gestão de Serviços Catálogo deve incluir: • • •

Concordando e documentar uma definição de serviço com todas as partes relevantes Interface com Gestão de Portfólio de Serviços concordar os conteúdos da Portfólio de Serviços e Catálogo de Serviços Produzir e manter uma Catálogo de Serviços e seu conteúdo, em conjunto com o portfólio de serviços

ITIL V3 - Service Design - Página:

112 de 477

•

•

•

Interface com o negócio e Gerenciamento da Continuidade do Serviço nas dependências do unidade de negócioss e a sua processo de negócioes com os serviços de e de TI, contido dentro do Catálogo de Serviços de Negócios Interface com as equipes de apoio, fornecedors e Gerenciamento da Configuração em interfaces e dependências entre os serviços de TI e os serviços de apoios, e os componentes contidos dentro do IC Catálogo de Serviço Técnico Interface com Gestão de Relacionamento com Empresas e Gerenciamento de Nível de Serviço para garantir que a informação está alinhado ao processo de negócio e de negócios.

4.1.6 Triggers, entradas, saídas e interfaces Há um número de fontes de informação que são relevantes para o processo de gestão de serviço de catálogo. Estes devem incluir: •

•

• • • •

Informações de negócios de negócio da organização e de TI estratégia, Os planos e os planos financeiros e informações sobre suas necessidades atuais e futuras do Portfólio de Serviços Análise de Impacto no Negócio, Fornecendo informações sobre o impacto, prioridade e risco associado a cada serviço ou mudança de requisitos de serviço Requisitos de negócios: detalhes sobre qualquer acordados, os requisitos de negócios novos ou alterados do Portfólio de Serviços O portfólio de serviços O CMS Retorno de todos os outros processos.

Os gatilhos para o processo de Gestão de Catálogo de Serviço são as mudanças nos requisitos de negócio e serviços e, portanto, uma das principais causas é Requisição de Mudanças (RFCs) e do processo de Gerenciamento de Mudança. Isso vai incluir novos serviços, mudanças nos serviços existentes ou serviços que estão sendo reformados. As saídas do processo de SCM são: • • •

A documentação e acordo de uma "definição do serviço ' Atualizações para o Portfólio de Serviços: Deve conter o actual estado de todos os serviços e os requisitos para serviços O Catálogo de Serviços: Deve conter os detalhes e as atuais estado de cada viver serviço prestado pela provedor de serviços ou serviço a ser transferida para o viver ambiente, Em conjunto com as interfaces e dependências. Um exemplo de um Catálogo de Serviços está contido no Anexo G.

ITIL V3 - Service Design - Página:

113 de 477

4.1.7 Gestão da informação A informação-chave dentro do processo de Gestão de Serviços Catálogo é que continha dentro do Catálogo de Serviço. A entrada principal para esta informação vem do portfólio de serviços e do negócio, quer através da Gestão de Relacionamento com Empresas (BRM) ou Gerenciamento de Nível de Serviço (SLM) processos. Esta informação tem de ser verificada para a exatidão antes de ser gravado dentro do Catálogo de Serviço. A informação e os serviços de catálogo si devem ser mantidas utilizando o Gestão da Mudança processo.

4.1.8 Indicadores Chave de Desempenho Os dois principais Key Performance Indicators (KPIs) associado com o Catálogo de Serviços e sua gestão são: •

•

O número de serviços registradas e gerenciado dentro do Catálogo de Serviços como uma percentagem dos que são fornecidos e transferida no ambiente real O número de variaçãos detectado entre as informações contidas dentro do Catálogo de Serviço e da situação do 'mundo real'.

Outras medidas e KPIs que podem ser utilizados são os seguintes: •

•

Negócio usuárioconsciência s 'dos serviços prestados, ou seja, no aumento percentual completude do Catálogo de Serviços de Negócios contra operacional serviços Sensibilização do pessoal de TI da tecnologia de e dos serviços: • Aumento percentual integralidade da Catálogo de Serviço Técnico Contra ele componentes que am os serviços • Service Desk ter o à informação para ar todos os serviços ao vivo, medido pela percentagem de incidentes sem a informação adequada de serviços relacionados.

4.1.9 Desafios, Fatores Críticos de Sucesso e riscos O maior desafio para o processo de Gestão de Serviço de Catálogo é a de manter um preciso Catálogo de Serviços como parte de um Portfólio de Serviços, Incorporando tanto o Catálogo de Serviços de Negócios e da Catálogo de Serviço Técnico como parte de um CMS geral e SKMS. Este é o melhor abordado por desenvolvimento autônomo planilhas ou bancos de dados antes de tentar integrar o Catálogo de Serviços e Portfólio de Serviços dentro do CMS ou SKMS. A fim de alcançar este objectivo, o cultura do organização tem de aceitar que o Catálogo e Portfolio são fontes essenciais de informação que todos dentro da organização de TI precisa usar e ajudar a manter. Isso, muitas vezes, ajudar na padronização do Catálogo de Serviço e do portfólio de serviços e permitir aumento no custo atuação através economias de escala.

ITIL V3 - Service Design - Página:

114 de 477

O principal Fator Crítico de Sucessos para o processo de Gestão de Serviços Catálogo são: • • •

Um Catálogo de Serviços precisa Negócio usuárioconsciência s 'dos serviços que estão sendo prestados Sensibilização do pessoal de TI da tecnologia de e aos serviços.

Os riscos associados com a prestação de um Catálogo de Serviços são precisos: • •

• • • • • •

Inexactidão dos dados no catálogo e não estar sob controle de mudanças rigoroso Pobre aceitação do Catálogo de Serviços e a sua utilização em todo o operacional processoes. Quanto mais ativo o catálogo é, o mais provável é ser preciso em seu conteúdo Inexatidão das informações recebidas do negócio, TI e Portfólio de Serviços, No que se refere à informação de serviço As ferramentas e recursos necessária para manter as informações Pouco o a informações precisas Gestão da Mudança informações e processos Falta de o a e apoio da CMS apropriado e up-to-date e SKMS Neutralização da utilização do Portfólio de Serviços e Catálogo de Serviços A informação é demasiado detalhado para manter a precisão ou em um nível muito alto para ser de qualquer valor. Ela deve ser consistente com o nível de detalhe dentro do CMS e os SKMS.

ITIL V3 - Service Design - Página:

115 de 477

4.2 Gestão de Nível de Serviço Gerenciamento de Nível de Serviço (SLM) negocia, concorda e documentos apropriados De serviços de TI alvos com representantes das empresas e, em seguida monitora e gera relatórios sobre a capacidade do prestador de serviços para entregar o nível acordado de serviço. SLM é um processo vital para cada Provedor de serviços de TI organização na medida em que é responsável por concordar e documentar meta de nível de serviços e responsabilidades dentro de SLAs e SLRs, para cada atividade dentro da TI. Se essas metas são adequadas e refletir com precisão as necessidades do negócio, então o serviço prestado pelos provedores de serviços vão se alinhar com os requisitos de negócios e atender as expectativas do clientes e usuários em termos de serviço qualidade. Se as metas não estão alinhados com as necessidades do negócio, em seguida, provedor de serviços actividades e nível de serviços não será alinhada com as expectativas do negócio e problemas irão desenvolver. O SLA é efetivamente um nível de garantia ou garantia no que diz respeito ao nível de qualidade do serviço prestado pelo fornecedor de serviços para cada um dos serviços fornecidos para o negócio. O sucesso da SLM é muito dependente da qualidade da Portfólio de Serviços e a Catálogo de Serviços e seus conteúdos, porque fornecem as informações necessárias sobre os serviços a serem gerenciados dentro do processo SLM.

4.2.1 Finalidade objetivo / / objetivo O objetivo da Gerenciamento de Nível de Serviço processo é garantir que um nível acordado de serviço de TI é fornecido para todos os atuais serviços de TI, e que os serviços são entregues aos futuros concordou objectivos atingíveis. Medidas pró-ativas também são levados a buscar e implementar melhorias ao nível do serviço prestado. A finalidade do processo de SLM é assegurar que todos operacional serviços e seus atuação são medidos de uma maneira profissional e consistente ao longo de TI organização, E que os serviços e os relatórios produzidos atender as necessidades do negócio e clientes. O objetivos de SLM são os seguintes: • • • • •

Definir, documentar, concordar, monitor, medida relatório e analisar o nível de serviços de TI prestados Fornecer e melhorar o relação e comunicação com o negócio e clientes Assegurar que as metas específicas e mensuráveis são desenvolvidos para todos os serviços de TI Monitorar e melhorar a satisfação do cliente com a qualidade do serviço prestado Garantir que a TI e os clientes têm uma expectativa clara e inequívoca de o nível de serviço a ser entregue

ITIL V3 - Service Design - Página:

116 de 477

•

Assegurar que as medidas pró-ativas para melhorar os níveis de serviço entregues são implementados onde quer que seja custo-justificável para fazê-lo.

4.2.2 Âmbito SLM deve fornecer um ponto de contato regular e comunicação aos clientes e gerentes de negócios de uma organização. Ele deve representar a Provedor de serviços de TI para a empresa, e os negócios à TI provedor de serviços. Este atividade deve abranger tanto o uso dos serviços existentes e os requisitos futuros potenciais para novos ou alterados serviços. SLM precisa gerenciar a expectativa e percepção dos negócios, clientes e usuários e garantir que a qualidade do serviço prestado pelo provedor de serviço corresponde às expectativas e necessidades. A fim de fazer isso de forma eficaz, SLM deve estabelecer e manter SLAs para todos os atuais viver serviços e gerenciar o nível de serviço prestado para cumprir as metas e qualidade medidas contidas no SLAs. SLM também deve produzir e acordar SLR para todos os serviços planejados novos ou alterados. Isto irá permitir SLM para garantir que todos os serviços e componentes são projetados e entregues a cumprir as suas metas em termos de necessidades de negócio. A SLM processoes deve incluir o: • • •

•

•

•

• •

Desenvolvimento de relações com o negócio Negociação e acordo de necessidades atuais e metas, ea documentação e gestão de SLAs para todos os serviços operacionais Negociação e acordo das necessidades futuras e metas, ea documentação e gestão de SLRs para todos os serviços propostos novos ou alterados Desenvolvimento e gestão de adequada Acordo de Nível Operacionals (OLAS) para assegurar que as metas estão alinhadas com as metas de SLA Revisão de toda a sustentação fornecedor contratos e acordos com Gestão de Fornecedores para assegurar que os objectivos estão alinhados com as metas de SLA Prevenção pró-ativa de serviço falhas, redução de riscos de serviços e de melhoria da qualidade de serviço, em conjunto com todos os outros processos Elaboração de relatórios e gestão de todos os serviços e revisão de todas as violações de SLA e fracos Instigação e coordenação de um Plano de Melhoria de Serviço (SIP) para a gestão, planejamento e implementação de todos os serviços e melhorias de processo.

ITIL V3 - Service Design - Página:

117 de 477

4.2.3 Valor para o negócio SLM oferece uma interface consistente para o negócio para todos os problemas relacionados ao serviço. Ele fornece o negócio com as metas de serviço acordadas e os necessários gestão da informação para garantir que os objectivos foram alcançados. Caso os objectivos sejam violados, SLM deve fornecer sobre a causa da violação e detalhes das ações tomadas para evitar a violação de recorrentes. Assim SLM oferece um canal de comunicação confiável e uma relação de confiança com o apropriado clientes e representantes das empresas.

4.2.4 Políticas / princípios / conceitos básicos SLM é o nome dado aos processos de planejamento, coordenação, elaboração, concordando, monitoramento e relatórios de SLAs, eo curso rever de realizações de serviços para garantir que o serviço necessário e custo-justificável qualidade é mantido e melhorado gradualmente. No entanto, SLM é não se preocupa apenas com a garantia de que os serviços atuais e SLAs são geridos, mas também está envolvido na garantia de que os novos requisitos são capturados e que os serviços novos ou alterados e SLAs são desenvolvidos para atender às necessidades de negócios e expectativas. SLAs fornecem a base para a gestão do relação entre o provedor de serviços eo cliente, e SLM prevê que ponto central de foco para um grupo de clientes, unidade de negócioss ou linhas de negócios. Um SLA é um escrito acordo entre um provedor de serviços de TI eo cliente de TI (s), que define as metas de chave e responsabilidades de ambas as partes. A ênfase deve estar em concordância, e SLAs não devem ser utilizados como uma forma de realização de um lado ou do outro de resgate. Um verdadeiro parceria deve ser desenvolvido entre o Provedor de serviços de TI eo cliente, para que um acordo mutuamente benéfico é alcançado - caso contrário, o SLA pode cair rapidamente em descrédito e uma "cultura da culpa" poderia desenvolver que impediria qualquer melhoria de qualidade de serviços verdadeiros ocorra. SLM também é responsável por garantir que todos os objectivos e as medidas acordadas em SLAs com o negócio são ados por OLAs subjacentes apropriados ou contratos, com unidades de apoio internos e parceiros externos e fornecedors. Isto é ilustrado na Figura 4.5.

ITIL V3 - Service Design - Página:

118 de 477

Figura 4.5 Service Level Management

Figura 4.5 mostra a relação entre a empresa e seu processoes e a serviços, e a tecnologia associada, serviços de apoios, equipes e fornecedores necessários para satisfazer as suas necessidades. Isso demonstra a importância dos SLAs, OLAs e contratos estão em definição e alcançar o nível de serviço exigido pelo negócio. Uma OLA é um acordo entre um Provedor de serviços de TI e outra parte da mesma organização que auxilia na prestação de serviços - por exemplo, um departamento de instalações que mantém o ar condicionado, ou a equipe rede de apoio que a o serviço de rede. Um OLA deve conter metas que sustentam aqueles dentro de um SLA para garantir que as metas não será ultraado pelo fracasso do apoio atividade.

4.2.5 As atividades de processo, métodos e técnicas As principais atividades dentro do processo SLM deve incluir:

ITIL V3 - Service Design - Página:

119 de 477

•

• • • • • • • • • •

Determinar, negociar, documentar e aprovar os requisitos para serviços novos ou modificados em SLRs, e gerenciar e revê-los através do ciclo de vida de serviço em SLAs para operacional serviços Monitorar e medir serviços atuação conquistas de todos os serviços operacionais contra alvos dentro de SLAs Cotejar, medir e melhorar a satisfação do cliente Produzir relatórios de serviço Realizar avaliação de serviços e instigar melhorias dentro de um plano global de Melhoria de Serviço (SIP) Analisar e rever SLAs, serviço escopo Olas, contratos, e qualquer outro esteio acordos Desenvolver e contatos de documentos e relações com o negócio, clientes e das partes interessadass Desenvolver, manter e operar procedimentos para registro, acionando e resolver todas as queixas, e para registro e distribuir elogios Registrar e gerenciar todas as reclamações e elogios Proporcionar a adequada gestão da informação para auxiliar gestão de desempenho e demonstram a realização de serviços Disponibilizar e manter-se atualizado-SLM documento modelos e padrões.

As interfaces entre as principais actividades encontram-se ilustrados na Figura 4.6.

ITIL V3 - Service Design - Página:

120 de 477

Figura 4.6 O Serviço de Gerenciamento de Nível de processo

Embora Figura 4.6 ilustra todas as principais atividades da SLM como atividades separadas, elas devem ser implementadas como um SLM integrado processo que podem ser aplicadas de forma consistente a todas as áreas das empresas e de todos os clientes. Estas atividades são descritas nas seções seguintes. 4.2.5.1 SLA estruturas Projetando

Usando o Catálogo de Serviços como auxiliar, SLM deve projetar a estrutura de SLA mais adequado para assegurar que todos os serviços e todos os clientes são abordados de uma forma mais adequada para o organização'S precisa. Há um número de opções potenciais, incluindo o seguinte. Baseada em serviços SLA Este é o lugar onde um SLA cobre um serviço, para todos os clientes desse serviço - por exemplo, um SLA pode ser estabelecido para o serviço de uma organização de e-mail - que abrange todos os clientes que serviço. Isto pode parecer bastante simples. No entanto, as dificuldades podem surgir se os requisitos específicos de clientes diferentes variar para o mesmo serviço, ou se as características da infra-estrutura significa que diferentes nível de serviços são

ITIL V3 - Service Design - Página:

121 de 477

inevitáveis (por exemplo, pessoal de escritório cabeça pode ser ligado através de uma rede local de alta velocidade, enquanto os escritórios locais pode ter que usar uma menor velocidade de linha WAN). Em tais casos, os alvos distintos pode ser necessário no interior de um contrato. Dificuldades podem também surgir na determinação de quem devem ser os signatários desse acordo. No entanto, onde os níveis comuns de serviço são fornecidos através de todas as áreas do negócio, E.g. e-mail ou de telefonia, o SLA baseada em serviços pode ser uma abordagem eficiente de usar. Várias classes de serviço, por exemplo, prata, ouro e bronze, também pode ser usado para aumentar o eficácia de serviço com base SLAs. Cliente baseado em SLA Trata-se de um acordo com um grupo de clientes individuais, cobrindo todos os serviços que utilizam. Por exemplo, os acordos podem ser alcançados com uma organização departamento financeiro cobertura, por exemplo, o sistema financeiro, o sistema de contabilidade, o sistema de folha de pagamento, o sistema de faturamento, o sistema de compras, e quaisquer outros sistemas de TI que utilizam. Os clientes que muitas vezes preferem um tal acordo, como todos os seus requisitos são cobertos em um único documento. Apenas um signatário é normalmente necessário, o que simplifica o problema. Uma combinação de qualquer uma destas estruturas pode ser apropriado, fornecendo todos os serviços e clientes são cobertos, sem sobreposição ou duplicação. Multi-nível SLAs Algumas organizações têm optado por adotar uma estrutura SLA multi-nível. Por exemplo, uma estrutura de três camadas como se segue: •

•

•

Nível corporativo: Abrangendo todas as questões SLM genéricos apropriados para cada cliente em toda a organização. Estes problemas tendem a ser menos voláteis, de modo actualizações são menos frequentemente necessário Nível de cliente: Abrangendo todas as questões relevantes para o SLM determinado grupo de clientes ou unidade de negócios, Independentemente do serviço a ser utilizado Nível de serviço: Abrangendo todas as questões relevantes para o SLM serviço específico, em relação a um grupo de clientes específicos (um para cada serviço abrangido pela SLA).

Conforme mostrado na Figura 4.7, tal estrutura permite que os SLAs sejam mantidos a um tamanho istrável, evita a duplicação desnecessária, e reduz a necessidade de atualizações freqüentes. No entanto, isso não significa

ITIL V3 - Service Design - Página:

122 de 477

que o esforço extra é necessário para manter o necessário relaçãos e links dentro do Catálogo de Serviços e do. CMS

Figura 4.7 Multi-nível SLAs

Muitos organizaçãos ter encontrado valioso para produzir normas e um conjunto de pro-formas ou modelos que podem ser usados como ponto de partida para todas as SLRs, SLAs e Olas. O pró-forma muitas vezes pode ser desenvolvido juntamente com o SLA projecto. Orientação sobre os itens a serem incluídos em um SLA é dada no Apêndice F. Desenvolvimento de normas e modelos irá garantir que todos os acordos são desenvolvidos de uma forma consistente, e isso vai facilitar o seu uso posterior, operação e gestão. Fazer papels e responsabilidades uma parte do SLA. Considere três perspectivas - o provedor de TI, o cliente de TI e do real usuários. A formulação de SLAs deve ser clara e concisa e não deixam margem para ambiguidades. Normalmente, não há necessidade de acordos para ser escrito em terminologia jurídica, e uma linguagem simples ajuda um entendimento

ITIL V3 - Service Design - Página:

123 de 477

comum. Muitas vezes, é útil ter uma pessoa independente, que não foi envolvido com a redação, para fazer uma final leia-through. Isso muitas vezes joga-se ambigüidades potenciais e as dificuldades que podem ser abordados e esclarecidos. Por esta razão, recomenda-se que todos os SLAs conter um glossário, definindo os termos e proporcionando clareza para todas as áreas de ambiguidade. Também vale a pena lembrar que os SLAs podem ter de cobrir os serviços oferecidos internacionalmente. Nesses casos, o SLA pode ter que ser traduzida em várias línguas. Lembre-se também que um SLA redigido em um único idioma pode ter que ser revistos para adequação em várias partes do mundo (ou seja, um versão redigido na Austrália pode ter que ser revistos para adequação nos EUA ou no Reino Unido - e diferenças de estilo, terminologia e cultura Deve ser tomado em conta). Onde o De serviços de TIs são proporcionados ao outro por uma organização prestador de serviços externo, Por vezes, o serviço alvos estão contidos dentro de um contrato e em outras vezes eles estão contidos dentro de um SLA ou cronograma anexo ao contrato. Seja o que for documento é usada, é essencial que as metas documentados e acordados são claras, específica e não ambígua, uma vez que será a base da relação e a qualidade do serviço prestado. 4.2.5.2 Determinar, documentar e acordar requisitos para novos serviços e produzir SLRs

Esta é uma das primeiras actividades dentro do Design de Serviços fase do ciclo de vida de serviços. Uma vez que o Catálogo de Serviços foi produzido e da estrutura SLA acordado, uma SLR primeiro deve ser elaborado. É aconselhável envolver clientes, desde o início, mas ao invés de ir junto com uma folha em branco para começar, pode ser melhor para produzir um projecto primeiro esboço da atuação metas e da gestão e operacional requisitos, como um ponto de partida para discussão mais detalhada e profunda. Tenha cuidado, porém, para não ir muito longe e parecem estar apresentando ao cliente um "fato consumado". Não pode ser over-stressed quão difícil isso atividade de determinar as metas iniciais para a inclusão com uma SLR ou SLA é. Todos os outros processoes devem ser consultados a sua opinião sobre o que são metas realistas que podem ser alcançados, tais como Gerenciamento de Incidentes em incidente alvos. A capacidade e Gerenciamento de Disponibilidade processos serão de particular valor na determinação da disponibilidade de serviço adequado e metas de desempenho. Se houver qualquer dúvida, as metas provisórias devem ser incluídos em um piloto SLA, que é monitorizado e ajustado por meio de um garantia de serviço período, tal como ilustrado na Figura 3.5. Embora muitas organizações têm de dar prioridade inicial para a introdução de SLAs para serviços existentes, é também importante estabelecer procedimentos ITIL V3 - Service Design - Página:

124 de 477

por concordar Nível Requisitos de Serviço (SLR) para novos serviços a serem desenvolvidos ou adquiridos. As SLRs deve ser uma parte integrante do Design de Serviços critérios, de que o funcional especificação é uma parte. Eles devem, desde o início, fazem parte do teste / experimentação critérios como o serviço progride através dos estágios de projeto e desenvolvimento ou aquisição. Este SLR será gradualmente refinado como o serviço progride através dos estágios de seu ciclo de vida, até que finalmente se torna um SLA piloto durante o início do período de vida de e. Este SLA piloto ou projecto deverá ser desenvolvido juntamente com o serviço em si, e deve ser assinado e formalizado antes que o serviço é introduzido em uso ao vivo. Pode ser difícil estabelecer os requisitos, tal como o negócio pode não saber o que eles querem - especialmente se não pediu anteriormente - e eles podem precisar de ajuda para entender e definir as suas necessidades, especialmente em termos de capacidade,segurança,disponibilidade e serviços de TI continuidade. Esteja ciente de que os requisitos inicialmente expressos não podem ser aqueles finalmente concordou. Várias iterações de negociações podem ser necessárias antes de um equilíbrio económico está fechado entre o que é pedido eo que é viável e ível. Este processo pode envolver uma reformulação da solução de serviço de cada vez. Se novos serviços estão a ser introduzido de uma forma perfeita para o viver ambiente, Outra área que requer atenção é o planejamento e formalização dos mecanismos de apoio para o serviço e sua componentes. Conselho deve ser solicitada Gestão da Mudança e Gerenciamento da Configuração para assegurar a planejamento é abrangente e cobre a implementação, desenvolvimento e apoio do serviço e seus componentes. Responsabilidades específicas precisam ser definidos e adicionado ao existente contratos / ANO, ou novos precisam ser acordados. O regime de apoio e de todos os escalada rotas também precisa de adicionar ao SCC, incluindo o Catálogo de Serviços se for o caso, para que o Service Desk e outro pessoal de apoio estão cientes deles. Se necessário, formação inicial e familiarização para o Service Desk e outros grupo de apoios e transferência de conhecimento deve ser concluída antes de apoio ao vivo é necessário. Deve notar-se que os recursos de e adicionais (isto é, mais pessoal) pode ser necessário para ar novos serviços. Muitas vezes existe uma expectativa de que um já sobrecarregado grupo de apoio pode magicamente lidar com o esforço adicional imposta por um novo serviço. Usando o projecto acordo como base, as negociações devem ser realizadas com o cliente (s), ou representantes do cliente para finalizar o conteúdo do SLA eo inicial meta de nível de serviços, e com a provedor de serviçoss para assegurar que estes são realizáveis.

ITIL V3 - Service Design - Página:

125 de 477

4.2.5.3 desempenho serviço Monitor contra SLA

Nada deve ser incluído em um SLA a menos que possa ser efetivamente monitorados e medidos em um ponto de comum acordo. A importância desta não pode ser negligenciado, como a inclusão de itens que não podem ser eficazmente controlado quase sempre resulta em disputas e eventual perda de fé na SLM processo. Um monte de organizaçãos descobriram o caminho mais difícil e, como resultado, absorvido pesado custars, tanto no sentido financeiro como também em termos de negativo impactos da sua credibilidade. Um provedor de rede global acordado metas de disponibilidade para a prestação de um serviço de rede gerenciado. Essas metas de disponibilidade foram acordados no ponto em que o serviço entrou nas instalações do cliente. No entanto, o provedor de rede global só poderia monitorar e medir disponibilidade no ponto de conexão deixaram suas instalações. As ligações de rede foram fornecidos por um número de diferentes telecomunicações nacionais provedor de serviçoss, com níveis muito variados de disponibilidade. O resultado foi uma incompatibilidade completa entre os valores de disponibilidade produzidos pelo fornecedor da rede e a cliente, Com debate correspondentemente prolongada e aquecida e argumento. Existente monitoramento capacidades deve ser revisto e atualizado conforme necessário. Idealmente isto deve ser feito antes de, ou em paralelo com a elaboração de SLAs, para que o monitoramento pode estar no lugar para ajudar com o validação das metas propostas. É essencial que o controlo corresponde a verdadeira percepção do cliente sobre o serviço. Infelizmente, isto é frequentemente muito difícil de alcançar. Por exemplo, a monitorização de indivíduo componentes, tais como a rede ou servidor, Não garante que o serviço estará disponível até o momento que o cliente está em causa. Percepção do cliente muitas vezes é que, apesar de um falha pode afetar mais de um serviço, tudo o que estão preocupadas é o serviço que não pode ar no momento do relataram incidente - Embora isso nem sempre é verdade, então é necessário cautela. Sem acompanhamento de todas as componentes do serviço de ponta-a-ponta (que pode ser muito difícil e caro para conseguir) uma imagem verdadeira não pode ser adquirida. Do mesmo modo, usuários devem ser conscientes de que devem relatar incidentes imediatamente para diagnóstico de ajuda, especialmente se eles estão relacionadas com o desempenho, de modo que a provedor de serviços está ciente de que as metas de serviço estão sendo violados. Um número considerável de organizações usam seu Service Desk, ligado a um CMS completo, para monitorar a clientePercepção é de disponibilidade. Isso pode envolver fazer mudanças específicas para incidente /problema log telas e pode exigir rigorosas observância com registro de incidentes procedimentos.

ITIL V3 - Service Design - Página:

126 de 477

Toda essa discussão necessidades e de acordo com o Gerenciamento de Disponibilidade processo. O Service Desk é usado também para monitorar incidente tempo de respostas e resolução vezes, mas mais uma vez a tela de pode precisar de alterações para acomodar captura de dados e registro de chamadas de procedimentos pode precisar apertar e devem ser rigorosamente seguidas. Se o apoio está sendo prestado por um terceiro, Esta monitoramento também podem apoiar Gestão de Fornecedores. É essencial assegurar que todos os alvos do incidente / problema de manipulação incluídos no SLA são os mesmos que os incluídos nas ferramentas de atendimento e utilizadas para escalada e efeitos de acompanhamento. Onde as organizações têm falhado em reconhecer isso, e talvez usada padrões fornecidos pela ferramenta fornecedor, Eles terminaram em uma situação onde eles estão monitorando algo diferente do que foi acordado no SLA e, portanto, incapaz de dizer se as metas de SLA foram cumpridos, sem esforço considerável para manipular os dados. Algumas alterações podem ser necessárias para ar as ferramentas, de modo a incluir os campos necessários para que os dados relevantes podem ser capturados. Outra área notoriamente difícil de controlar é transação os tempos de resposta (o tempo entre o envio de uma tela e recebendo uma resposta). Muitas vezes end-to-end de resposta são tecnicamente muito difícil de controlar. Em tais casos, pode ser adequado para lidar com este como se segue: •

• •

•

Incluir uma declaração no SLA ao longo das seguintes linhas: «Os serviços abrangidos pelo SLA são projetados para alta velocidade de resposta e não há atrasos significativos devem ser encontradas. Se um atraso de tempo de resposta de mais de x segundos é experimentado por mais de minutos y, isso deve ser comunicado imediatamente à Central de Serviço '. Concordar e incluir no SLA uma meta aceitável para o número de incidentes que podem ser tolerados no período de referência. Criar um incidente categoria de 'má resposta' (ou similar) e garantir que todos esses incidentes são registrados com precisão e que estão relacionadas com o serviço adequado. Produzir relatórios regulares de ocasiões em SLA transação metas de tempo de resposta foram violados, e abertura de inquéritos via Gerenciamento de Problemas para corrigir a situação.

Esta abordagem não só supera as dificuldades técnicas de monitoramento, mas também garante que os incidentes de má resposta são relatados no momento em que eles ocorrem. Isto é muito importante, como resposta pobre é muitas vezes causado por uma série de acontecimentos que interagem transientes que só podem ser detectados se eles são investigadas imediatamente.

ITIL V3 - Service Design - Página:

127 de 477

O método preferido, no entanto, é a aplicação de alguma forma de automatizado cliente/servidor monitoramento de tempo de resposta em estreita consulta com o Operação de Serviço. Sempre que possível, implementar amostragem ou "robô" ferramentas e técnicas para dar indicações de desempenho lento ou pobre. Estas ferramentas fornecem a capacidade de medir ou provar os tempos de resposta reais ou muito semelhantes àquelas experimentadas por uma variedade de usuários, e estão se tornando cada vez mais disponíveis e cada vez mais rentável para usar. Alguns organizaçãos descobriram que, na realidade, 'má resposta "às vezes é um problema de usuário percepção. O usuário, Tendo-se utilizado a um nível particular de resposta ao longo de um período de tempo, começa a lamentar, logo que este é mais lenta. Da opinião de que "se o usuário acha que o serviço é lento, então é '. Se o SLA inclui metas para a avaliação e implementação de pedidos de Mudança (RFC), o acompanhamento das metas relativas ao Gestão da Mudança devem, idealmente, ser realizada utilizando qualquer ferramenta Alterar Gestão está em uso (de preferência, parte de um sistema integrado Serviço de Gestão de Ferramenta de apoio) e mudança telas de registro e escalonamento processoes devem apoiar isso. 4.2.5.4 Intercalar, medir e melhorar a satisfação do cliente

Há um número de importantes questões "soft" que não podem ser monitorados por meio mecanicistas ou processual, tais como clientes sentimentos gerais (estes não precisam necessariamente coincidir com o 'hard' monitoramento). Por exemplo, mesmo quando houve uma série de falhas de serviço comunicados, os clientes ainda podem sentir positivo sobre as coisas, porque eles podem se sentir satisfeito de que as ações apropriadas estão sendo tomadas para melhorar as coisas. Naturalmente, o oposto pode ser aplicável, e clientes podem se sentir insatisfeito com alguns problemas (por exemplo, o costume de alguns funcionários no Posto de Serviço) quando as metas de SLA poucos ou nenhuns foram quebrados. Desde o início, é sábio para tentar gerenciar as expectativas dos clientes. Isso significa definir expectativas adequadas e metas apropriadas, em primeiro lugar, e colocando um processo sistemático no local para gerenciar as expectativas daqui para frente, como a satisfação = percepção - expectativa (onde uma pontuação zero ou positivo indica um cliente satisfeito). SLAs são apenas documentos, e em si não alterar significativamente a qualidade de serviço sendo fornecido (embora possam afetar o comportamento e ajudar a engendrar um adequado cultura de serviço, Que pode ter um efeito benéfico imediato, e fazer melhorias de longo prazo possível). Um certo grau de paciência é, portanto, necessária e deve ser construído em expectativas.

ITIL V3 - Service Design - Página:

128 de 477

Quando as taxas estão sendo feitas para os serviços prestados, este deve modificar as demandas dos clientes. (Os clientes podem ter tudo o que pode custar-justificar - desde que se encaixa dentro concordou corporativa estratégia E ter autorizado orçamento para, mas não mais.) Onde encargos directos não são feitas, o apoio dos gerentes seniores devem ser recrutados para garantir que as exigências excessivas ou irrealista não são colocados no provedor de TI por qualquer grupo individual do cliente. Portanto, é recomendável que as tentativas de ser feito para monitorar a percepção do cliente sobre estas questões suaves. Métodos de fazer isso incluem: • • •

• • • •

Questionários periódicos e pesquisas com clientes A opinião dos clientes a partir de reuniões de avaliação de serviços O dos Comentários pós implementação (PIRs), realizado como parte da Gestão da Mudança processo de grandes mudanças, lançamentos, serviços novos ou alterados, etc Telefone pesquisas de percepção (talvez ao acaso no Service Desk, ou usando representantes de ligação dos clientes regulares) Satisfação apostilas de pesquisa (da esquerda com clientes, visitas seguintes instalações de serviços, etc) Grupo de usuários ou fórum reuniões Análise das reclamações e elogios.

Sempre que possível, deveriam ser fixados objectivos para estes e monitorados como parte do SLA (por exemplo, uma pontuação média de 3,5 deve ser alcançada pelo provedor de serviços em resultados dados, com base em um sistema de pontuação de 1 a 5, onde 1 é pobre atuação e 5 é excelente). Garantir que, se usuários fornecer que recebem algo em troca, e demonstrar-lhes que seus comentários foram incorporadas em um plano de ação, talvez um SIP. Todas as medidas de satisfação dos clientes devem ser revistos, e onde as variações são identificados, eles devem ser analisados com medidas tomadas para corrigir a variação. 4.2.5.5 Análise e rever os acordos subjacentes e escopo de serviços

Provedor de serviços de TIs são dependentes em certa medida, o seu próprio interno e técnico equipes ou em parceiros externos ou fornecedors. Eles não podem se comprometer com metas de SLA de reunião a menos que sua própria equipe de e e desempenho de fornecedores apoiar essas metas. Contratos com fornecedores externos são obrigatórias, mas muitas organizações também identificaram os benefícios de ter acordos com simples interna grupo de apoios, geralmente referidos como Olas. «Determinação acordos" é um termo usado para se referir a todos OLAs sustentação, SLAs e contratos.

ITIL V3 - Service Design - Página:

129 de 477

Muitas vezes, estes acordos são chamados de acordos de 'back-to-back ". Isto é para reflectir a necessidade de garantir que todos os alvos dentro subjacente ou "back-to-back 'acordos estão alinhados com e apoio, metas acordadas com o negócio em SLAs ou Olas. Pode haver várias camadas de estas subjacentes ou "back-to-back 'acordos com metas alinhadas. É essencial que os alvos em cada camada estão alinhadas com, e de apoio, os alvos contida dentro dos níveis mais elevados (isto é, os mais próximos das metas de negócios). OLAs não precisa ser muito complicado, mas deve estabelecer metas específicas de back-to-back para grupo de apoios que sustentam as metas incluídas no SLAs. Por exemplo, se o SLA inclui o tempo global para responder e fixar objectivos para incidentes (variando no prioridade os níveis), então os OLAs deve incluir alvos para cada um dos elementos da cadeia de e. Deve ser entendido, contudo, que os objectivos inerentes de resolução incluídos no SLA não deve, normalmente, coincidir com os mesmos alvos incluídos em contratos ou com olas fornecedors. Isto é porque os alvos de SLA deve incluir um elemento para todas as fases do ciclo de e (por exemplo, detecção tempo, tempo de serviço registro Secretária, escalada tempo, o tempo de referência entre grupos etc, revisão Service Desk e fecho tempo -, assim como o tempo real, que fixa o falha). A meta de SLA deve cobrir o tempo necessário para atender as chamadas, escalar incidentes e técnico pessoal, e do tempo necessário para começar a investigar e resolver incidentes atribuídos a eles. Além disso, em geral horas de e deve ser estipulado para todos os grupos que sustentam os tempos disponibilidade de serviço necessários no SLA. Se especial procedimentos existem para funcionários ados (por exemplo, o e por telefone forade-horas), estes também devem ser documentados. OLAs devem ser monitorados contra alvos OLA e SLA e relatórios sobre as realizações previstas como para os gerentes da apropriadas de cada equipe de e. Isso destaca áreas de problemas potenciais, que podem precisar de ser abordados internamente ou por mais rever de SLA ou o OLA. Séria consideração deve ser dada à introdução OLAs formais para todas as equipes de e interno, que contribuem para o apoio de operacional serviços. Antes de cometer a SLAs nova ou revista, por isso é importante que as actuais disposições contratuais são investigadas e, se necessário, atualizado. Esta é provavelmente a incorrer adicional custars, que deve ser absorvido pela TI ou ado para o cliente. Neste último caso, o cliente deve concordar com isso, ou os alvos mais relaxado em contratos existentes devem ser acordados para inclusão em SLAs. Este atividade deve ser concluído em estreita consulta com o Gestão de Fornecedores processo, para garantir não só que os requisitos sejam cumpridos SLM, mas também que todos os requisitos de outros processos são considerados, particularmente fornecedor e políticas contratuais e normas.

ITIL V3 - Service Design - Página:

130 de 477

4.2.5.6 serviço relatórios Produzir

Imediatamente após o SLA está acordado e aceite, o monitoramento deve ser instigado, e os relatórios de realização de serviços devem ser produzidos. Relatórios operacionais devem ser produzidos com freqüência (semanal - talvez até com mais freqüência) e, sempre que possível, relatório de exceçãos deve ser apresentado sempre que um SLA foi quebrado (ou ameaçados, se for o caso limiars foram criados para dar um "alerta precoce"). Às vezes, encontrar dificuldades no cumprimento das metas do novo serviços durante o período inicial de e de vida por causa do alto volume de RFCs. Limitar o número de RFCs processados durante o período inicial de vida de e pode limitar a impacto de mudars. O SLA mecanismos de notificação, intervalos e formatos de relatório devem ser definidos e acordados com os clientes. A frequência eo formato de reuniões de avaliação de serviços também deve ser acordado com os clientes. Intervalos regulares são recomendados, com relatórios periódicos sincronizados com o ciclo de revisão. Relatórios periódicos deve ser produzido e distribuído aos clientes (ou seus representantes) e apropriados gerentes de TI de alguns dias de antecedência nível de serviço revisões, de modo que quaisquer dúvidas ou divergências podem ser resolvidas antes da reunião de avaliação. A reunião não é então desviado por tais questões. Os relatórios periódicos devem incorporar detalhes de desempenho em relação a todas as metas de SLA, juntamente com detalhes de quaisquer tendências ou ações específicas que estão sendo tomadas para melhorar o serviço qualidade. Uma técnica útil consiste em incluir um SLA Monitoring gráfico (SLAM) na parte frontal de um relatório de serviço para dar uma "a-um-relance 'visão geral de como as realizações mediram-se contra alvos. Estes são mais eficazes se codificados por cores (vermelho, laranja, verde, e algumas vezes referido como gráficos RAG como resultado). Outros relatórios intercalares pode ser exigido por gerenciamento de TI para OLA ou interno atuação opiniões e / ou fornecedor ou gestão de contratos. Isto é susceptível de ser um processo evolutivo - um primeiro esforço é pouco provável que seja o último resultado. O recursos necessário para produzir e verificar relatórios não devem ser subestimados. Ele pode ser extremamente demorado, e se os relatórios não refletem a clientePrópria percepção da qualidade do serviço de precisão, podem piorar a situação. É essencial que a informação correcta de todas as zonas e todas processoes (por exemplo, Gerenciamento de Incidentes,Gerenciamento de Problemas,Gerenciamento de Disponibilidade,Gerenciamento da Capacidade, Mudança e Gerenciamento da Configuração) É analisado e compilados em um relatório conciso e abrangente sobre o desempenho do serviço, medida contra alvos comerciais acordadas.

ITIL V3 - Service Design - Página:

131 de 477

SLM deve identificar as necessidades de informação específicas e automatizar a produção dos relatórios, na medida do possível. A medida, precisão e facilidade com que os relatórios automatizados pode ser produzido deve fazer parte dos critérios de selecção para as ferramentas de apoio integrados. Estes relatórios de serviços não só deve incluir detalhes sobre o desempenho atual contra alvos, mas também deve fornecer informações históricas sobre o desempenho ado e as tendências, de modo que o impacto das ações de melhoria pode ser medido e previsto. 4.2.5.7 Conduta revisões do serviço e instigar melhorias dentro de um SIP geral

Reuniões de avaliação periódica deve ser realizada em uma base regular com os clientes (ou seus representantes) para analisar a realização de serviços no último período e para visualizar todas as questões para o próximo período. É normal para realizar tais reuniões mensais ou, no mínimo, trimestrais. As ações devem ser colocadas no cliente e fornecedor, conforme apropriado para melhorar áreas fracas que as metas não estão sendo atendidas. Todas as ações devem ser ata, e os progressos devem ser revistas na próxima reunião para garantir que os itens de ação estão sendo acompanhados e devidamente executados. Particular atenção deve ser focada em cada violação de nível de serviço para determinar exatamente o que causou a perda de serviço eo que pode ser feito para evitar que se repitam. Se for decidido que o nível de serviço era, ou se tornou, inatingível, pode ser necessário rever, renegociar, rever-acordar metas de serviços diferentes. Se a quebra de serviço foi causado por uma falha de um terceiro ou interno grupo de apoio, Também pode ser necessário rever a base acordo ou OLA. Análise dos custos e do impacto das violações de serviço fornece informações valiosas e justificação das atividades SIP e ações. A necessidade constante de melhoria precisa ser equilibrado e focado nas áreas com maior probabilidade de dar o benefício maior de negócios. Os relatórios devem também ser produzido sobre o progresso e sucesso da SIP, como o número de ações SIP que foram concluídas eo número de ações que entregou seu benefício esperado. 'Espião Um em ambos os campos "- Gestores de Nível de Serviço pode ser visto com uma certa desconfiança tanto pela Provedor de serviços de TI pessoal e os representantes dos clientes. Isto é devido a dupla natureza do trabalho, onde eles estão atuando como um representante do cliente não-oficial ao falar com a equipe de TI, e como um representante do provedor de TI quando falar com o clientes. Isso geralmente é agravada quando se tem para representar a 'oposição' ponto de vista em qualquer reunião etc Para evitar isso o Gerente de Nível de Serviço deve ser tão aberta e útil quanto possível (dentro dos limites de

ITIL V3 - Service Design - Página:

132 de 477

qualquer propriedade comercial) quando se tratar de ambos os lados, embora colegas nunca devem ser abertamente criticada. 4.2.5.8 e Revisão de SLAs, o escopo de serviços e acordos subjacentes

Todos acordos e os acordos subjacentes, incluindo os SLAs, subjacente contratos e Olas, deve ser mantido up-to-date. Eles devem ser colocados sob Mudança e Gerenciamento da Configuração controle e revistos periodicamente, pelo menos anualmente, para garantir que eles ainda estão atual e abrangente, e ainda estão alinhados com as necessidades do negócio e estratégia. Estes revers deve garantir que os serviços cobertos e as metas de cada ainda são relevantes - e que nada de significativo mudou que invalida o acordo de qualquer forma (isto deve incluir mudanças de infra-estrutura, mudanças empresariais, fornecedor alterações, etc.) Onde mudars são feitas, os acordos devem ser atualizados em Gestão da Mudança controlar a refletir a nova situação. Se todos os acordos são registados como IC dentro da CMS, é mais fácil avaliar o impacto e implementar as mudanças de uma maneira controlada. Esses exames devem incluir também os documentos estratégia global, para garantir que todos serviços e contratos de serviços são mantidos em linha com os negócios e estratégias de TI e políticas. 4.2.5.9 Desenvolver contatos e relacionamentos

É muito importante que SLM desenvolve a confiança e respeito com o negócio, Especialmente com os contatos de negócios. Usando o Catálogo de Serviços, especialmente o elemento Negócios Catálogo de Serviço do mesmo, permite SLM ser muito mais pró-ativa. O Catálogo de Serviços fornece a informação que permite compreender o SLM relaçãos entre os serviços e os unidade de negócioss e de processos de negócios que dependem desses serviços. Ela também deve fornecer as informações sobre todos os negócios chave e os relacionados com os serviços, a sua utilização e sua importância. A fim de garantir que isso seja feito de uma forma consistente, SLM deve realizar as seguintes atividades: • • •

•

Confirmar das partes interessadass, clientes e os gerentes de negócios e usuários dos serviços. Ajudar com a manutenção de informações precisas dentro do Portfólio de Serviços e Catálogo de Serviços. Seja flexível e sensível às necessidades dos negócios, clientes e usuários, e compreender atual e planejada nova processo de negócioes e seus requisitos para serviços novos ou modificados, documentação e comunicação a esses requisitos a todos os outros processos, bem como facilitar e mudança inovando sempre que há o benefício do negócio. Desenvolver uma compreensão completa do cliente de negócios, e usuário estratégias, planos, necessidades de negócio e objetivos,

ITIL V3 - Service Design - Página:

133 de 477

•

• •

• •

•

• • • • •

garantindo que ele está trabalhando em parceria com a negócio, Clientes e usuários, desenvolvendo relacionamentos de longo prazo. Regularmente fazer a viagem do cliente e provar a experiência do cliente, fornecendo sobre os problemas dos clientes a ele. (Isto aplicase a ambos os clientes de TI e também os clientes externos de negócios, no uso de De serviços de TIs). Garantir que os processos de relacionamento corretas estão no local para alcançar os objetivos e que eles são submetidos a melhoria contínua. Conduzir e concluir inquéritos aos clientes, ajudar com a análise dos inquéritos concluídos e garantir que as ações são tomadas sobre os resultados. Atuar como um representante de TI na organização e atendimento usuário grupos. Proativamente comercializar e explorar o Portfólio de Serviços e Catálogo de Serviços e a utilização dos serviços dentro de todas as áreas do negócio. Trabalhar com a empresa, clientes e usuários para garantir que ele fornece os níveis mais adequados de serviço para atender às necessidades de negócios atualmente e no futuro. Promover a consciência de serviço e compreensão. Aumentar a consciência dos benefícios de negócios a ganhar com a exploração de novas tecnologias. Facilitar o desenvolvimento e negociação de SLRs adequados, exequíveis e realistas e SLAs entre o negócio e TI. Assegurar o negócio, clientes e usuários a compreender suas responsabilidades / compromissos de TI (ou seja, dependências). Ajudar com a manutenção de um registo de todas as melhorias pendentes e melhorias.

4.2.5.10 Reclamações e elogios

A SLM processo deve incluir também atividades e procedimentos para a exploração e gestão de todas as reclamações e elogios. Os procedimentos de registo são geralmente realizadas pela central de serviços que sejam análogas às de Gerenciamento de Incidentes e Cumprimento de Requisição. A definição de uma reclamação e elogio devem ser acordados com os clientes, juntamente com pontos de o e procedimentos acordados para a sua gestão e análise. Todas as reclamações e elogios devem ser registradas e comunicadas às partes interessadas. Todas as reclamações também devem ser acionadas e resolveu a satisfação do seu autor. Se não for, deverá haver uma escalada contato e procedimento para todas as queixas que não são acionadas e resolveu dentro de um prazo adequado. Todas as reclamações pendentes devem ser revistos e encaminhado para a gerência sênior quando apropriado. Os relatórios devem ser produzidos sobre os números e tipos de reclamações, as tendências identificadas e as medidas tomadas para reduzir os números recebidos. Relatos semelhantes também devem ser produzidos para elogios.

ITIL V3 - Service Design - Página:

134 de 477

4.2.6 Triggers, entradas, saídas e interfaces Há muitos gatilhos que instigam SLM atividade. Estes incluem: • • • • • • •

Mudanças na Portfólio de Serviços, Como requisitos de negócios novos ou modificados ou serviços novos ou alterados Acordos novos ou alterados, SLRs, ou SLAs, Olas contratos Reuniões de avaliação de serviços e ações Violações de serviços ou de violações ameaçadas Elogios e reclamações Atividades periódicas, tais como a revisão de relatórios e pesquisas de satisfação de clientes Mudanças nas estratégia ou política.

4.2.6.1 processo entradas SLM

Há um número de fontes de informação que são relevantes para o Gerenciamento de Nível de Serviço processo. Estes devem incluir: •

•

• • • •

• • •

Informações de negócios: a partir do organizaçãoEstratégia do negócio, planos e planos financeiros e informações sobre suas necessidades atuais e futuras Análise de Impacto no Negócio: Fornecimento de informações sobre a impacto,prioridade, Risco e número de usuários associados com cada serviço Requisitos de negócios: detalhes sobre qualquer acordados, os requisitos de negócios novos ou alterados As estratégias, políticas e restrições de Estratégia de Serviço O Portfólio de Serviços e Catálogo de Serviços Alterar as informações: a partir do Gestão da Mudança processo com um cronograma para a frente das mudanças e uma necessidade de avaliar todas as alterações de seu impacto sobre todos os serviços CMS: que contém informações sobre o relaçãos entre o serviço de negócios, o serviços de apoios e a tecnologia Cliente e usuário comentários, reclamações e elogios Outros insumos: incluindo aconselhamento, informação e de entrada de qualquer um dos outros processos (por exemplo, Gerenciamento de Incidentes,Gerenciamento da Capacidade e Gerenciamento de Disponibilidade), Juntamente com os SLAs existentes, SLRs, e OLAs e relatórios de serviços ados no qualidade do serviço prestado.

4.2.6.2 saídas processo SLM

As saídas dos Gerenciamento de Nível de Serviço deve incluir:

ITIL V3 - Service Design - Página:

135 de 477

•

•

• • •

•

•

• •

• •

Relatórios de serviço: fornecer detalhes da nível de serviços alcançados em relação às metas contidas dentro de SLAs. Estes relatórios devem conter informações sobre todos os aspectos do serviço e de sua entrega, incluindo a corrente e histórico atuação, Violações e fracos, grandes eventos, mudanças planejadas, atuais e previsto carga de trabalhos, de clientes e planos de melhoria e atividades Plano de Melhoria de Serviço (SIP): uma geral programa ou plano de ações de melhoria priorizadas, abrangendo todos os serviços e todos os processos, juntamente com os impactos e riscos associados O Plano de Qualidade de Serviço: documentar e planejamento a melhoria global da qualidade de serviço Modelos de documentos: padrão documento modelos de formato e conteúdo para SLAs, SLRs e Olas, alinhada com os padrões corporativos Acordo de Nível de Serviços (SLAs): um conjunto de metas e responsabilidades devem ser documentadas e acordadas dentro de um SLA para cada operacional serviço Exigência de Nível de Serviços (SLR): um conjunto de metas e responsabilidades devem ser documentadas e acordadas dentro de um SLR para cada novo serviço proposto ou alterados Acordo de Nível Operacionals (ANO): um conjunto de metas e responsabilidades devem ser documentadas e acordadas dentro de um OLA para cada equipe de e interno Relatórios sobre Olas e subjacente contratos Minutos de revisão de reuniões e ações: todas as reuniões devem ser agendadas em uma base regular, com agendas programadas e suas discussões e ações gravadas e progrediu Revisão de SLA e serviços escopo rever ata da reunião: resumir ações acordadas e revisãos ao escopo SLAs e serviço Revisado contratos: alterações SLAs ou SLRs novos contratos existentes pode exigir que sustentam a ser alterados ou novos contratos a serem negociados e acordados.

4.2.7 Indicadores Chave de Desempenho Key Performance Indicators (KPIs) e métricas podem ser usadas para julgar o eficiência e eficácia das atividades SLM eo progresso da SIP. Essas métricas devem ser desenvolvidos a partir do serviço ao cliente, e perspectiva de negócios e deve abranger ambas as medições subjetivas e objetivas, tais como o seguinte. Objetivo: • • •

Número ou percentagem de serviço metas a ser cumpridas Número e gravidade das violações de serviços Número de serviços com up-to-date SLAs

ITIL V3 - Service Design - Página:

136 de 477

•

Número de serviços com relatórios oportunos e comentários de serviços ativos.

Subjetiva: •

Melhorias na satisfação do cliente.

Mais informações sobre KPIs, medições e melhorias podem ser encontradas na seção seguinte e na publicação contínua Melhoria de Serviço. Não caia na armadilha de usar percentagens, a métrica apenas. É fácil de ser pego quando há um pequeno sistema com pontos de medição limitada (ou seja, um único falha numa população de 100 é de apenas 1%, uma única falha de uma população de 50 é de 2% -, se o alvo é de 98,5%, em seguida, a SLA é já quebrado). Sempre ir para o número de incidentes em vez de um percentual sobre a população de menos de 100, e ter cuidado quando as metas são aceitos. Isso é algo organizaçãos aprenderam da maneira mais difícil. A SLM processo muitas vezes gera um bom ponto de partida para um SIP - eo processo de revisão de serviços pode conduzir este, mas todos os processos e todas as áreas da provedor de serviços organização deve ser envolvido na SIP. Quando uma dificuldade subjacente foi identificado que está afetando negativamente no serviço qualidade, SLM deve, em conjunto com Gerenciamento de Problemas e Gerenciamento de Disponibilidade, Instigar um SIP para identificar e implementar as acções necessárias para superar as dificuldades e restaurar qualidade do serviço. Iniciativas SIP também podem se concentrar em questões como usuário serviço de formação e de testes e documentação. Nestes casos, as pessoas relevantes precisam estar envolvidos e retorno adequado dado a fazer melhorias para o futuro. A qualquer momento, uma série de iniciativas distintas que fazem parte do SIP pode ser executado em paralelo para resolver dificuldades com uma série de serviços. Algumas organizações estabeleceram anual inicial orçamento realizada pela SLM de que iniciativas SIP pode ser financiado. Isto significa que a acção pode ser efectuada rapidamente e que é demonstravelmente efectiva SLM. Este prática deve ser incentivado e ampliado para permitir SLM para tornar cada vez mais pró-ativa e preditiva. A SIP precisa ser detida e gerida, com todas as ações de melhoria a ser avaliados para risco e impacto em serviços, clientes e a negócio, E então priorizados, prevista e implementada. Se uma organização é terceirização sua prestação de serviços a um terceiro, A questão da melhoria do serviço deve ser discutido no início e coberto (e orçamentado para) na contrato, Caso contrário, não há incentivo durante a vigência do contrato para o fornecedor para melhorar a metas de serviço se eles

ITIL V3 - Service Design - Página:

137 de 477

já estão cumprimento das obrigações contratuais e despesas adicionais é necessário para fazer as melhorias. 4.2.7.1 KPIs

Gerenciar a qualidade geral do De serviços de TI necessário, tanto em número e nível de serviços fornecidos e gerenciados: • • •

• •

Percentual de redução nas metas de SLA perdeu Percentual de redução nas metas de SLA ameaçado Aumento percentual na percepção e satisfação do cliente de realizações de SLA, através de comentários e respostas de serviço Pesquisa de Satisfação do Cliente Redução percentual em violações de SLA causado por causa de contratos de e de terceiros (subjacente contratos) Redução percentual em violações de SLA causado por causa de internos Acordos de Nível Operacional (ANO).

Oferecer serviços como anteriormente acordado a preços íveis custars: • • • • • •

Número total e percentual de aumento em SLAs totalmente documentado no lugar Aumento percentual de SLAs acordados contra operacional serviços que estão sendo executados Percentagem de redução dos custos associados ao serviço próvisão Percentagem de redução do custo de monitoramento e relatórios de SLAs Aumento percentual da velocidade e da elaboração e adopção de SLAs apropriado Frequência de reuniões de avaliação de serviços.

Gerenciar interface de negócios: • • • • • •

•

Maior porcentagem de serviços abrangidos por SLAs Documentados e acordados processos de SLM e procedimentos estão em vigor Redução do tempo necessário para responder a pedidos de SLA e implementar Maior porcentagem de SLA revers concluídas a tempo Redução no percentual de SLAs excelente para renegociação anual Redução da percentagem de SLAs requerendo mudanças de correcção (por exemplo, não tem como alvo atingível; mudanças nos níveis de utilização). Cuidado deve ser tomado ao usar este KPI Aumento percentual na cobertura de Olas e de terceiros contratos no lugar, enquanto que, possivelmente, reduzir o número real de acordos (consolidação e centralização)

ITIL V3 - Service Design - Página:

138 de 477

• • •

Prova documental de que as questões levantadas no serviço de opiniões e SLA estão sendo acompanhados e resolvidos Redução do número e gravidade das violações de SLA Eficaz de revisão e acompanhamento de todos os SLA, OLA e subjacente contrato violações.

4.2.8 Gestão da Informação SLM fornece informações importantes sobre todos os serviços operacionais, os seus objectivos esperados e as realizações de serviços e violações de todos os serviços operacionais. Ela auxilia Gestão Catálogo de Serviço com a gestão do Catálogo de Serviços e também fornece a informação e tendências na satisfação do cliente, incluindo suas reclamações e elogios. SLM é crucial no fornecimento de informações sobre a qualidade de De serviços de TI fornecida ao cliente, E informações sobre a expectativa do cliente ea percepção de que a qualidade do serviço. Esta informação deve estar amplamente disponíveis para todas as áreas do provedor de serviços organização.

4.2.9 Desafios, Fatores Críticos de Sucesso e riscos Um desafio enfrentado por SLM é o de identificar os representantes dos clientes adequados com quem negociar. Quem 'possui' a serviço? Em alguns casos, isso pode ser óbvia, e um gerente único cliente está disposto a agir como o signatário do acordo. Em outros casos, pode levar um pouco de negociação ou bajulando para encontrar 'voluntário' um representante (cuidado que os voluntários muitas vezes querem expressar seu próprio ponto de vista pessoal e não representam um consenso geral), ou pode ser necessário para obter todos os clientes para . Se existem representantes dos clientes que são capazes de realmente representar os pontos de vista da comunidade de clientes, pois eles freqüentemente se reunir com uma grande variedade de clientes, este é o ideal. Infelizmente, muitas vezes representantes são sede base e raramente entram em contato com os clientes de serviços genuínos. No pior caso, SLM pode ter de realizar seu / sua própria programa de discussões e reuniões com os clientes para garantir verdadeiros requisitos são identificados. Na negociação do atual e horas de e para um serviço de grande porte, uma organização encontrada uma discrepância no tempo necessário de uso entre a sede eo escritório de campo clientes. Sede (com um número limitado usuário população) queria horas de serviço cobrindo 8,00-18,00, enquanto o escritório de campo (com pelo menos 20 vezes o usuário população) afirmou que a partir de uma hora antes seria melhor - mas todos os escritórios fechados ao público por 16,00, o mais tardar, e assim wouldn 't exigem um serviço muito

ITIL V3 - Service Design - Página:

139 de 477

além disso. Sede ganhou o argumento "político", e então a banda 8,00-18,00 foi definida. Quando o serviço ou a ser usado (e, portanto, monitorado) verificou-se que as extensões de serviços eram geralmente solicitado pelo escritório de campo para cobrir a hora extra no período da manhã, e os valores reais de utilização mostraram que o serviço não havia sido ada após 17,00, exceto em ocasiões muito raras. O Gerente de Nível de Serviço foi responsabilizado pela equipe de TI para ter de cobrir uma tarde deslocar, E pelo representante do cliente para carregamento por um serviço que não foi utilizado (ou seja, pessoal e custos de funcionamento). Cuidados devem ser tomados ao abrir discussões sobre nível de serviços, pela primeira vez, como é provável que 'problemas atuais "(a falha que ocorreu ontem) ou de longa duração queixas (aquela impressora velha que temos vindo a tentar obter substituído por idades) são susceptíveis de ser exibido no início. Importante ainda que estes possam ser, eles não devem ser autorizados a entrar no caminho de estabelecer os requisitos de longo prazo. Esteja ciente, no entanto, que pode ser necessário para resolver quaisquer questões levantadas no início antes de ganhar alguma credibilidade para avançar. Se não houve nenhuma experiência prévia de SLM, então é aconselhável começar com um projecto de SLA. A decisão deve ser tomada no qual o serviço ou os clientes estão a ser utilizados para o projecto. É útil se o cliente selecionado é entusiasta e deseja participar - talvez porque eles estão ansiosos para ver melhorias na qualidade do serviço. Os resultados de um levantamento inicial do cliente a percepção pode dar dicas para um SLA projecto inicial adequado. Não escolher uma área onde existem grandes problemas como o SLA primeiro. Tente escolher uma área que tende a mostrar alguns benefícios rápidos e desenvolver o processo de SLM. Nada encoraja a aceitação de uma nova idéia mais rápido do que o sucesso. Uma dificuldade encontrada é, por vezes, que o pessoal em diferentes níveis dentro da comunidade cliente pode ter diferentes objetivos e percepções. Por exemplo, um gerente sênior raramente pode usar um serviço e podem estar mais interessados em questões como valor para o dinheiro e saída, enquanto que um membro júnior do pessoal pode usar o serviço durante todo o dia, e podem estar mais interessados em questões como capacidade de resposta,usabilidade e confiança. É importante que todos os requisitos dos clientes apropriados e relevantes, a todos os níveis, são identificadas e incorporadas no SLA. Alguns organizaçãos ter formado grupos focais de diferentes níveis dentro da comunidade de clientes para ajudar a garantir que todos os problemas tenham sido correctamente tratadas. Isto toma adicional recursos, mas pode ser bem vale o esforço.

ITIL V3 - Service Design - Página:

140 de 477

O outro grupo de pessoas que tem que ser consultado durante todo este processo é o representantes adequados de dentro do lado do provedor de TI (interno ou externo a partir de uma fornecedor ou parceiro). Eles precisam concordar que as metas são realistas, viáveis e íveis. Se eles não estiverem, as negociações são necessários até que um compromisso aceitável para todas as partes for acordado. Os pontos de vista de fornecedores também devem ser procurados, bem como as implicações contratuais devem ser levados em conta durante a fase de negociação. Caso não existam dados monitorados ado está disponível, é aconselhável deixar o acordo em formato de projecto por um período inicial, até monitoramento pode confirmar que as metas iniciais são realizáveis. Os alvos podem ter de ser re-negociado, em alguns casos. Muitas organizações negociar um prazo acordado para a TI para negociar e criar uma linha de base para o estabelecimento de metas de serviço realistas. Quando as metas e os prazos foram confirmados, os SLAs devem ser assinados. Uma vez que o SLA inicial já foi concluída, e as dificuldades iniciais superar, em seguida, seguir em frente e gradualmente introduzir SLAs para outros serviços / clientes. Se for decidido, desde o início para ir para uma estrutura multi-nível, é provável que os problemas de nível corporativo têm que ser cobertos para todos os clientes no momento do SLA inicial. Também vale a pena experimentação as questões corporativas durante esta fase inicial. Não vá para alvos fáceis no nível corporativo. Podem ser fácil de alcançar, mas não têm valor na melhoria do serviço qualidade ou credibilidade. Além disso, se os objectivos são fixados a um nível suficientemente elevado, o SLA corporativo pode ser usado como o padrão que todos os novos serviços devem alcançar. Um ponto para garantir é que no final do processo de elaboração e negociação, o SLA é realmente assinado pelos gerentes apropriados para o cliente e Provedor de serviços de TI lados para o acordo. Isso dá um firme compromisso de ambas as partes que cada tentativa será feita para cumprir o acordo. De um modo geral, o mais alto dos signatários estão dentro de suas respectivas organizações, a mais forte mensagem de compromisso. Uma vez que um SLA é acordado, ampla publicidade precisa ser usado para garantir que os clientes, usuários e equipe de TI são igualmente conhecimento da sua existência e dos objectivos-chave. Devem ser tomadas medidas para anunciar a existência da nova SLAs e OLAs entre o Service Desk e outros grupo de apoios, com detalhes de quando eles se tornam operacional. Pode ser útil para extrair principais alvos desses acordos em tabelas que podem estar em exibição em áreas de e, de modo que os funcionários estão sempre cientes dos objectivos a que eles estão trabalhando. Se as ferramentas de apoio permitem, essas metas devem ser registrados dentro das ferramentas, como dentro de um Catálogo de Serviços ou CMS, de

ITIL V3 - Service Design - Página:

141 de 477

modo que o seu conteúdo pode ser amplamente divulgado a todos os funcionários. Eles também devem ser incluídos como limiars, e automaticamente alertado contra quando um alvo é ameaçado ou violado, na verdade. SLAs, OLAs e as metas que eles contêm também deve ser divulgado entre os usuário comunidade, de modo que os usuários estão cientes do que eles podem esperar dos serviços que utilizam, e saber em que ponto de começar a expressar insatisfação. É importante que a equipe de Service Desk estão comprometidos com a SLM processo, E tornar-se embaixadores pró-ativas para SLAs, abraçando o necessário cultura de serviço, Pois eles são o primeiro ponto de contato para incidentes de clientes, reclamações e consultas. Se a equipe de Service Desk não estão plenamente conscientes de SLAs no lugar, e não agir de acordo com seu conteúdo, os clientes muito rapidamente perder a fé em SLAs. 4.2.9.1 Fatores Críticos de Sucesso

O principal Fator Crítico de Sucessos para o processo de Gerenciamento de Nível de Serviço são: • • •

Gerenciar a qualidade geral do De serviços de TIs exigido Entregar o serviço como previamente acordado a preços íveis custars Gerenciar a interface com o negócio e usuários.

Os riscos associados com respeito à provisão de um preciso Catálogo de Serviços são os seguintes: • • •

• • • • • •

A falta de entrada precisos, envolvimento e comprometimento com o negócio e clientes As ferramentas e recursos obrigados a concordar, o documento, monitor relatório, e os acordos de revisão e nível de serviços O processo torna-se um processo burocrático e istrativo, em vez de um processo ativo e pró-ativa entregando benefício mensurável para o negócio O o e apoio do CMS adequado e up-to-date e SKMS Ignorando o uso dos processos de SLM Medidas de negócios e de clientes são muito difíceis de medir e melhorar, por isso não são registradas Negócio inadequado e contatos de clientes e relaçãos são desenvolvidos Altas expectativas dos clientes e baixa percepção A comunicação deficiente e inadequado é obtida com o negócio e clientes.

ITIL V3 - Service Design - Página:

142 de 477

4,3 Gerenciamento da Capacidade Gerenciamento da Capacidade é um processo que se estende por todo o ciclo de vida de serviço. Um fator-chave de sucesso na gestão de capacidade é garantir que é considerado durante o projeto fase. É por esta razão que o processo de gestão de capacidade é incluída na presente publicação. Gerenciamento da Capacidade é apoiado inicialmente em Estratégia de Serviço onde as decisões e análise de requisitos de negócio e resultados dos clientes influenciar o desenvolvimento de padrões de atividade de negócio (PBA), níveis de serviço (LOS) e pacote de nível de serviços (PLSs). Isto fornece os indicadores de capacidade de previsão e permanente necessários para alinhar a capacidade de demanda.

Finalidade 4.3.1 meta / / objetivo "O objetivo do processo de Gerenciamento da Capacidade é garantir que custo justificável de capacidade de TI em todas as áreas de TI sempre existe e é adaptado às necessidades atuais e futuras acordadas do negócio, em tempo hábil".

O objetivo do Gerenciamento da Capacidade é de fornecer um ponto de foco e de gestão para toda a capacidade e problemas relacionados ao desempenho, relativos a ambos os serviços e recursos. O objetivos de Gerenciamento da Capacidade são: • •

•

• • •

Produzir e manter uma adequada e up-to-date Plano de capacidade, Que reflete as necessidades atuais e futuras do negócio Prestar assessoria e orientação para todas as outras áreas de negócio e de TI em todas as capacidades e problemas relacionados ao desempenho Garantir que o serviço atuação realizações atender ou exceder todas as suas metas de desempenho acordadas, através da gestão do desempenho e da capacidade de ambos os serviços e recursos Auxiliar no diagnóstico e resolução de desempenho e capacidade de incidentes relacionados e problemas Avaliar a impacto de todas as alterações no plano de capacidade, e do desempenho e da capacidade de todos os serviços e recursos Assegurar que as medidas pró-ativas para melhorar o desempenho dos serviços são implementados onde quer que seja de custo justificável para fazê-lo.

4.3.2 Âmbito O Gerenciamento da Capacidade processo deve ser o ponto focal de toda a performance de TI e problemas de capacidade. Funções de tecnologia de gestão, tais como e de rede, e do servidor ou Gestão de Operação

ITIL V3 - Service Design - Página:

143 de 477

pode realizar a maior parte do dia-a-dia operacional funções, mas irá fornecer informações sobre o desempenho do processo de Gerenciamento da Capacidade. O processo deverá abranger todas as áreas de tecnologia, tanto de hardware e software, de toda a tecnologia de TI componentes e ambientes. Gerenciamento da Capacidade também deve considerar o espaço planejamento e sistemas ambientais capacidade bem como certos aspectos de recursos humanos, mas apenas onde a falta de recursos humanos pode resultar em uma violação do SLA ou OLA alvos, um atraso no desempenho final-de-final ou serviço tempo de resposta, Ou uma incapacidade para cumprir os compromissos e planos futuros (por exemplo, dados durante a noite apoios não concluído a tempo, porque não estavam presentes operadores de carregar fitas). Em geral, a gestão de recursos humanos é uma responsabilidade de gestão da linha, embora o pessoal de um Service Desk deve usar idêntico Gerenciamento da Capacidade técnicas. O agendamento de recursos humanos, os níveis de pessoal, os níveis de habilidade e capacidade níveis devem, por conseguinte, ser incluídos dentro do escopo de Gerenciamento da Capacidade. A força motriz para Gerenciamento da Capacidade devem ser os requisitos de negócio da organização e planejar os recursos necessários para fornecer nível de serviços, de acordo com os SLAs e Olas. Gerenciamento da Capacidade precisa entender de TI total e ambientes de negócios, incluindo: • • • •

O negócio atual operação e suas necessidades, através dos padrões de actividade Os futuros planos de negócio e requisitos através da Portfólio de Serviços As metas de serviço e da corrente Operação de Serviço de TI embora SLAs e Procedimentos Operacionais Padrão Todas as áreas da tecnologia da informação e de sua capacidade e desempenho, incluindo infra-estrutura, dados, ambiente e aplicaçãos.

Entender tudo isso vai permitir Gerenciamento da Capacidade para garantir que toda a capacidade atual e futura e atuação aspectos serviços são fornecidos de forma rentável. Gerenciamento da Capacidade é também sobre a compreensão do potencial para o fornecimento de novos serviços. Nova tecnologia precisa ser entendida e, se for o caso, usado para inovar e realizar os serviços requeridos pelo cliente. Gerenciamento da Capacidade precisa reconhecer que a taxa de mudança tecnológica vai provavelmente aumentar e que a nova tecnologia deve ser aproveitada para assegurar que os serviços de TI continuar a satisfazer as expectativas de negócios em mudança. Um link direto para a Estratégia de Serviço e Portfólio de Serviços é necessária para assegurar que as tecnologias emergentes são considerados no planejamento futuro serviço. O Gerenciamento da Capacidade processo deve incluir:

ITIL V3 - Service Design - Página:

144 de 477

•

• •

• •

• •

Monitoramento padrões de atividade de negócio e de nível de serviço, através de planos de utilização, desempenho e rendimento de serviços de TI e infra-estrutura de apoio, ambientais, de dados e aplicações componentes e a produção de relatórios de regular e ad hoc em serviço e a capacidade do componente e desempenho Empresa afinação atividades para tornar mais eficiente o uso de recursos de TI existentes Entender as demandas acordadas atuais e futuros que estão sendo feitas pelo cliente para recursos de TI, e produzir previsões para necessidades futuras Influenciar Gerenciamento da Demanda, Talvez em conjunto com a gestão financeira Produzir um plano de capacidade que permite a provedor de serviços para continuar a prestar serviços da qualidade definida em SLAs e que abrange um período de tempo suficiente para atender o planejamento futuro nível de serviços exigido, tal como definido na Portfólio de Serviços e SLRs Assistência com a identificação e resolução de quaisquer incidentes e problemas associados com o serviço ou componente atuação A melhoria pró-ativa de serviço ou o desempenho dos componentes onde quer que seja justificável custo e atende às necessidades do negócio.

Gerenciando o capacidade da grande distribuição Infra-estrutura de TIs é uma tarefa complexa e exigente, especialmente quando a capacidade de TI eo investimento financeiro necessário é cada vez maior. Portanto, faz ainda mais sentido para planejar o crescimento. Enquanto o custar da atualização de um componente individual em um ambiente distribuído é geralmente menor do que a atualização para um componente em um ambiente de mainframe, muitas vezes há muitos componentes mais no ambiente distribuído que precisam ser atualizados. Também não poderia ser agora economias de escala, Porque o custo por componente individual pode ser reduzida quando muitos componentes precisam de ser comprado. Gerenciamento da Capacidade deve ter entrada para o Portfólio de Serviços e contratos processo para assegurar que as melhores ofertas com fornecedors são negociados. Gerenciamento da Capacidade fornece as informações necessárias sobre atual e planejada recurso utilização de componentes individuais para permitir às organizações decidir, com confiança: •

•

Quais componentes para upgrade (ou seja, mais memória, dispositivos de armazenamento mais rápido, processadores mais rápidos, maior largura de banda) Quando a atualização - idealmente, esta não é cedo demais, resultando em excesso de capacidade caro, nem demasiado tarde, deixando de aproveitar os avanços em novas tecnologias, resultando em gargalos,

ITIL V3 - Service Design - Página:

145 de 477

•

desempenho inconsistente e, em última análise, insatisfação dos clientes e perda de oportunidades de negócios Quanto a atualização vai custar - a previsão e elementos de planejamento de Gerenciamento da Capacidade alimentar em ciclos orçamentais, garantindo investimento previsto.

Muitos dos outros processos são menos eficazes se não houver entrada de los do processo de Gerenciamento da Capacidade. Por exemplo: • •

• •

Pode o Gestão da Mudança processo de avaliar adequadamente o efeito de qualquer mudar na capacidade disponível? Quando um novo serviço é implementado, o processo pode ser SLM certeza de que as SLRs do novo serviço são realizáveis, e que os SLAs de serviços existentes não serão afetados? Pode o Gerenciamento de Problemas processo de diagnosticar corretamente a causa de incidentes causados pela baixa atuação? Pode o Continuidade do Serviço de TI processo determinar com precisão as necessidades de capacidade dos principais processos de negócios?

Gerenciamento da Capacidade é um dos processos de previsão que, quando bem conduzida, pode prever eventos empresariais e impactos, muitas vezes antes que eles aconteçam. Gerenciamento da Capacidade bom garante que não há surpresas em relação ao serviço e componente projeto e desempenho. Gerenciamento da Capacidade tem uma estreita, de mão dupla relação com a Estratégia de Serviço e planejamento processos dentro de uma organização. Em uma base regular, a longo prazo estratégia de uma organização é encapsulado em uma atualização dos planos de negócios. O Estratégia de Serviço refletirá os planos de negócios e estratégia, Que são desenvolvidos a partir de entendimento da organização dos fatores externos, como o mercado competitivo, perspectivas econômicas e legislação, e sua interna capacidade em termos de mão de obra capacidade de entrega, etc Muitas vezes, um prazo mais curto tático planoOu plano de mudança de negócios é desenvolvido para implementar as mudanças necessárias no curto e médio prazo para o progresso do plano de negócios global e Estratégia de Serviço. Gerenciamento da Capacidade precisa entender os planos de curto, médio e longo prazo da negócio ao fornecer a informação sobre as últimas idéias, tendências e tecnologias sendo desenvolvidas pelo fornecedors de hardware de computação e software. O negócio da organização planeja dirigir o Estratégia de Serviço de TI específicas, cujo conteúdo Gerenciamento da Capacidade precisa estar familiarizado com, e para o qual precisa de Gerenciamento da Capacidade de ter tido significativa e permanente nível input.The direito de capacidade no momento certo é fundamental. Planos de estratégia de serviço será útil para o

ITIL V3 - Service Design - Página:

146 de 477

planejamento de capacidade, identificando o tempo para aquisição e implementação de novas tecnologias, hardware e software.

4.3.3 Valor para o negócio Gerenciamento da Capacidade é responsável por garantir que os recursos de TI são planejadas e programadas para fornecer um nível de serviço consistente que corresponde às necessidades atuais e futuras do negócio, conforme acordado e documentado dentro de SLAs e Olas. Em conjunto com a empresa e os seus planos, Gerenciamento da Capacidade fornece uma Plano de capacidade que descreve os recursos de TI e de financiamento necessários para apoiar o plano de negócios, juntamente com uma justificação custo do que as despesas.

4.3.4 Políticas / princípios / conceitos básicos Gestão da Capacidade garante que o capacidade e o desempenho da De serviços de TIs sistemas e corresponda às exigências acordadas evolução do negócio da forma mais eficaz e oportuna. Gerenciamento da Capacidade é essencialmente um ato de equilíbrio: •

•

Balanceamento condenação recursos necessários: a necessidade de garantir que a capacidade de processamento que é comprado é de custo justificável em termos de necessidade de negócio, ea necessidade de se fazer o uso mais eficiente desses recursos. Equilíbrio entre a oferta em relação à demanda: A necessidade de garantir que a oferta disponível de TI poder de processamento corresponda às exigências feitas sobre o assunto pela empresa, agora e no futuro. Também pode ser necessário para controlar ou influenciar a procura de um determinado recurso.

Processos de capacidade de gestão e de planejamento devem estar envolvidos em todas as etapas do serviço Ciclo de Vida de Estratégia e Projeto, Através Transição e Operação de Melhoria. A partir de um estratégico perspectiva, o Portfólio de Serviços contém os recursos de TI e capacidades. O advento da Arquitetura Orientada a Serviços, virtualização eo uso de rede de valors em serviço de TI próvisão são fatores importantes para a gestão da capacidade. A capacidade adequada e desempenho devem ser projetados para serviços e componentes, desde as fases iniciais do projeto. Isto assegurará não apenas que o atuação de qualquer serviço novo ou alterado cumpra suas metas esperados, mas também que todos os serviços existentes continuam a cumprir todos os seus objectivos. Esta é a base da pró serviço estávelvisão. O Gerenciamento da Capacidade geral processo está continuamente procurando custo-benefício para combinar com TI recursos e capacidade para as necessidades em constante mudança e os requisitos do negócio. Isto exige

ITIL V3 - Service Design - Página:

147 de 477

que o afinação e otimização dos recursos existentes ea eficácia estimativa e planeamento dos recursos futuros, como ilustrado na Figura 4.8.

Figura 4.8 O processo de Gerenciamento da Capacidade

Gestão da Capacidade é uma técnica extremamente processo complexo e exigente e, a fim de alcançar resultados, ela exige três sub-processos de apoio. Uma das principais atividades de Gerenciamento da Capacidade é produzir um plano que documenta os níveis atuais de utilização de recursos e desempenho do serviço e, após análise do Estratégia de Serviço e planos, prevê os requisitos futuros para novos recursos de TI para ar os serviços de TI que sustentam as atividades empresariais. O plano deve indicar claramente quaisquer suposições feitas. Ele também deve incluir todas as recomendações quantificados em termos de recursos necessários, custos, benefícios, impacto, etc A produção e manutenção de um Plano de capacidade deve ocorrer em intervalos pré-definidos. É, essencialmente, um plano de investimento e, portanto, deve ser publicado anualmente, em linha com o negócio ou orçamento ciclo de vida, e concluída antes do início das negociações sobre os orçamentos futuros. A re-edição trimestral do plano actualizado pode ser necessário levar em conta mudanças em planos de serviço, para informar sobre a precisão das previsões e fazer recomendações ou refinar. Isso exige esforço extra, mas, se

ITIL V3 - Service Design - Página:

148 de 477

ele é atualizado regularmente, o Plano de Capacidade é mais provável que seja preciso e para refletir a necessidade de negócio em mudança. Os conteúdos típicos de um plano de capacidade são descritos no Apêndice J. 4.3.4.1 Gerenciamento da Capacidade de Negócios

Este sub-processo traduz as necessidades de negócios e planos em requisitos de serviço e infraestrutura de TI, garantindo que os requisitos de negócios futuros para os serviços de TI são quantificados, concebido, planejado e implementado em tempo hábil. Isto pode ser conseguido utilizando os dados existentes sobre a utilização dos recursos de corrente pelas várias serviços e recursos para a tendência, a previsão do modelo, ou prever necessidades futuras. Estes requisitos futuros provenientes do Estratégia de Serviço e Portfólio de Serviços detalhando novos processos e exigências de serviço, mudanças, melhorias, e também o crescimento nos serviços existentes. 4.3.4.2 Gerenciamento da Capacidade Serviço

O foco deste sub-processo é a gestão, controlar e previsão do desempenho fima-fim e capacidade do vivo, operacional De serviços de TIs de uso e carga de trabalhos. Ele garante que o desempenho de todos os serviços, conforme detalhado nas metas de serviços dentro de SLAs e SLRs, é monitorado e medido, e que os dados coletados são registrados, analisados e relatados. Onde quer que as medidas necessárias, pró-ativa e reativa deve ser iniciada, para garantir que o atuação de todos os serviços atenda às suas metas de negócios acordados. Isto é realizado por uma equipe com conhecimento de todas as áreas de tecnologia utilizada na entrega de fim-a-fim do serviço, e muitas vezes envolve o conselho busca dos especialistas envolvidos na Gestão da Capacidade de componentes. Sempre que possível, automatizado limiars deve ser usado para gerenciar todos os serviços operacionais, para garantir que as situações em que as metas de serviço são violados ou ameaçados são rapidamente identificados e custo-efetivas ações para reduzir ou evitar o seu potencial impacto implementadas. 4.3.4.3 Gerenciamento da Capacidade Componente

O foco neste sub-processo é a gestão, controle e previsão do desempenho, utilização e capacidade da tecnologia de TI indivíduo componentes. Ele garante que todos os componentes dentro da infra-estrutura de TI que têm recurso finito são monitorados e medidos, e que os dados coletados são registrados, analisados e relatados. Mais uma vez, sempre que possível, os limiares automatizados devem ser implementadas para gerenciar todos os componentes, para garantir que as situações em que as metas de serviço são violados ou ameaçados pelo uso de componentes ou de desempenho são rapidamente identificados, e custo-efetivas ações para reduzir ou evitar o seu impacto potencial são implementadas. ITIL V3 - Service Design - Página:

149 de 477

Há muitas atividades semelhantes que são executadas por cada um dos subprocessos acima, mas cada sub-processo tem um foco muito diferente. Gerenciamento da Capacidade de negócios é focado nas necessidades de negócios atuais e futuras, enquanto Gerenciamento da Capacidade de serviço concentra-se na entrega dos serviços existentes que am o negócioE Gestão da Capacidade de componentes é focado no Infra-estrutura de TI que sustenta o serviço provisão. O papel que cada um destes sub-processos desempenha no global processo e o uso de ferramentas de gestão encontra-se ilustrada na Figura 4.9.

Figura 4.9 Gerenciamento da Capacidade sub-processos

Os instrumentos utilizados pelos Gerenciamento da Capacidade necessidade de estar em conformidade com o organização"Arquitetura de gerenciamento de s e integrar com outras ferramentas utilizadas para a gestão de sistemas de TI e automatizar os processos de TI. O monitoramento e atividades de controle dentro Operação de Serviço irá fornecer uma boa base para as ferramentas de apoio e analisar informações para Gerenciamento da Capacidade.

ITIL V3 - Service Design - Página:

150 de 477

4.3.5 as atividades de processo, métodos e técnicas Algumas atividades do processo de Gerenciamento da Capacidade são reativas, enquanto outros são pró-ativa. As atividades pró-ativas de Gerenciamento da Capacidade deve incluir: • •

•

•

• •

Antecipar problemas de desempenho, tomando as ações necessárias antes que eles ocorram Tendências produtoras do atual componente utilização e estimar as necessidades futuras, usando as tendências e limiars para atualizações de planejamento e melhorias Modelagem e tendências das mudanças previstas nos serviços de TI, e identificar as mudanças que precisam ser feitas para serviços e componentes da infra-estrutura de TI e aplicaçãos para assegurar que apropriado recurso está disponível Garantir que as atualizações estão orçados, planejados e implementados antes de SLAs e metas de serviço sejam violados ou atuação problemas ocorrem Buscando ativamente para melhorar o desempenho do serviço onde quer que seja custo-justificável Afinação e otimizar o desempenho dos serviços e componentes.

As atividades reativas de Gerenciamento da Capacidade deve incluir: • • •

Monitoramento, medição, relatório e analisar o desempenho atual de ambos os serviços e componentes Respondendo a todos "capacidade relacionadalimiar'Eventos e ações corretivas instigante Reagindo a e ajudando com problemas de desempenho específicos. Por exemplo, o Service Desk pode referir-se incidentes de mau desempenho para Gestão de Tecnologia, que vai empregar Gerenciamento da Capacidade técnicas para resolvê-los.

A mais bem sucedida das atividades proativas e preditivas de gestão da capacidade, menos necessidade haverá para as atividades reativas de Gerenciamento da Capacidade. 4.3.5.1 Gerenciamento da Capacidade de Negócios

O principal objetivo do Gerenciamento da Capacidade de negócios sub-processo é assegurar que os futuros requisitos de negócios (cliente resultados) para os serviços de TI são consideradas e compreendidas, e que suficiente TI capacidade para ar todos os serviços novos ou alterados é planejado e implementado em um prazo adequado. Figura 4.10 ilustra que o BCM é influenciada pelos padrões de atividade de negócio e como os serviços são utilizados.

ITIL V3 - Service Design - Página:

151 de 477

Capacidade figura 4.10 deve ar os requisitos de negócios

O Gerenciamento da Capacidade processo deve ser sensível a mudanças nos requisitos para a demanda de capacidade. Novos serviços ou serviços alterados serão necessárias para sustentar o negócio em mudança. Serviços existentes exigirá modificações para fornecer funcionalidade extra. Serviços de idade vai se tornar obsoleto, liberando capacidade de reposição. Como resultado, a capacidade para satisfazer o clienteSLRs s 'e SLAs serão afetados. É da responsabilidade do Gerenciamento da Capacidade de prever a demanda por capacidade para tais mudanças e gerenciar a demanda. Estas novas exigências podem vir a atenção de Gestão da Capacidade de muitas fontes diferentes e por muitas razões diferentes, mas as principais fontes de abastecimento deve ser o Padrão de Atividade de Negócios de Gerenciamento da Demanda e a Pacote de Nível de Serviços produzidas pela Portfólio de Serviços. Estes indicam uma janela de preditores futuros de capacidade. Tais exemplos poderiam ser uma recomendação para atualizar para tirar proveito da nova tecnologia, ou a aplicação de um afinação atividade para resolver um atuação problema. Figura 4.11 mostra o ciclo da gestão da procura.

ITIL V3 - Service Design - Página:

152 de 477

Figura Gerenciamento da Capacidade 4,11 toma nota do padrão de demanda

Gestão de capacidade tem de ser incluído em todos estratégico,planejamento e as atividades do projeto, que está sendo envolvido tão cedo quanto possível dentro de cada processo, Tais como: • • •

Assistência e apoio a desenvolvimento de Estratégia de Serviço Envolvimento na revisão e melhoria de estratégias de TI e políticas Envolvimento na revisão e melhoria de arquiteturas de tecnologia.

Gestão de capacidade não deve ser uma de última hora 'carrapato na caixa pouco antes da aceitação do cliente e operacional aceitação. Se o envolvimento precoce pode ser alcançado a partir de Gestão de Capacidade dentro desses processos, o planejamento e projeto de capacidade de TI pode ser estreitamente alinhados com os requisitos de negócio e pode garantir que serviço metas podem ser alcançadas e mantidas. Auxiliar em concordar Requisitos de Nível de Serviço Gerenciamento da Capacidade deve ajudar na compreensão da SLM clientes ' capacidade e requisitos de desempenho, em termos de serviço requerido / sistema tempo de respostas, esperado rendimento, Os padrões de uso e volume de usuários. Gerenciamento da Capacidade deve ajudar no processo de negociação, oferecendo soluções possíveis para um número de cenários. Por exemplo, se o volume de usuários é menor do que 2,000, então os tempos de resposta podem ser garantidos para ser inferior a dois segundos. Se mais de 2.000 usuários se conectam ao mesmo tempo, então a largura de banda extra é necessário para garantir o tempo de resposta requerido, ou um tempo de ITIL V3 - Service Design - Página:

153 de 477

resposta mais lento terá que ser aceite. Modelagem, tendências ou aplicação dimensionamento técnicas são frequentemente utilizados aqui para garantir que as previsões refletem exatamente a situação real. Adquirir o projeto, ou alterar a configuração de serviços Gerenciamento da Capacidade devem ser envolvidos na concepção de novos serviços ou mudança e fazer recomendações para a aquisição de hardware e software, onde o desempenho e / ou capacidade são fatores. Em alguns casos, Gerenciamento da Capacidade instiga a implementação do novo exigência através Gestão da Mudança, Onde está também envolvida como um membro do Conselho Change Advisory. No interesse de balanceamento custar e capacidade, o Gerenciamento da Capacidade processo obtém os custos de soluções alternativas propostas e recomenda a mais adequada solução de custo eficaz. Verifique SLA O SLA deve incluir detalhes sobre o serviço antecipado rendimentos e os requisitos de desempenho. Gerenciamento da Capacidade informa SLM em metas realizáveis que podem ser monitorados e em que a Design de Serviços tem sido baseada. Confiança de que o Design de Serviços irá atender as SLRs e fornecer a capacidade de crescimento futuro pode ser adquirida por meio modelagem, Dimensionamento de tendências ou técnicas. Negociação SLA apoio Os resultados das técnicas preditivas fornecer o verificação de capacidades de desempenho de serviço. Pode haver uma necessidade de SLM renegociar SLAs com base nestes resultados. Gerenciamento da Capacidade fornece e para SLM deve renegociações ser necessário, recomendando soluções potenciais e informações de custo associado. Uma vez assegurado que os requisitos são realizáveis, que é de responsabilidade do SLM para acordar a nível de serviços e o SLA. Controle e implementação Todos mudars para serviço e recurso capacidade deve seguir todos os processos de TI, tais como Gestão da Mudança, de Lançamento de Configuração, e do Projeto para garantir que grau o direito de controlar e coordenação está no lugar em todas as alterações e que qualquer novo ou alteração componentes são registrados e monitorados por meio de sua ciclo de vida. 4.3.5.2 Gerenciamento da Capacidade Serviço

ITIL V3 - Service Design - Página:

154 de 477

O principal objetivo do Gerenciamento da Capacidade de serviço sub-processo é identificar e compreender o De serviços de TIs, o seu uso de recursos, os padrões de trabalho, os picos e as depressões, e para assegurar que o serviços cumprir as metas de SLA, ou seja, para garantir que os serviços de TI executem conforme necessário. Neste sub-processo, o foco é na gestão de serviços atuação, Como determinado pelas metas contidas no SLAs acordados ou SLRs. O Serviço de Gerenciamento da Capacidade sub-processo garante que os serviços atendam às metas de serviço acordados capacidade. O serviço monitorado fornece dados que podem identificar as tendências a partir do qual normais nível de serviços pode ser estabelecido. Por regular monitoramento e comparação com esses níveis, condições de exceção pode ser definido, identificados e relatados. Portanto Gerenciamento da Capacidade informa SLM de quaisquer violações de serviços ou quase. Haverá ocasiões em que incidentes e problemas são chamados de Gerenciamento da Capacidade de outros processoes, ou identifica-se que um serviço poderia deixar de cumprir suas metas de SLA. Em algumas dessas ocasiões, a causa do potencial falha não pode ser resolvido por Gerenciamento da Capacidade componente. Por exemplo, quando a falha é analisada pode ser encontrado que não há falta de capacidade, Ou nenhum componente individual é super-utilizados. No entanto, se o projeto ou codificação de um aplicação é ineficiente, então o desempenho de rede poderá ter de ser gerido, bem como de hardware individual ou recursos de software. Gerenciamento da Capacidade de serviço também deve estar monitorando serviço carga de trabalhos e transaçãos para garantir que eles permanecem dentro dos limites acordados e limiars. A chave para uma gestão de sucesso Serviço capacidade é de prever problemas, sempre que possível, através do monitoramento mudanças no desempenho e acompanhamento da impacto de mudanças. Portanto, este é um outro sub-processo que tem de ser proativo e preditivo, mesmo preventiva, ao invés de reativo. No entanto, há momentos em que é necessário reagir a problemas de desempenho específicos. A partir de um conhecimento e entendimento dos requisitos de desempenho de cada um dos serviços que estão sendo utilizados, os efeitos de mudanças no uso dos serviços pode ser estimado, e as medidas tomadas para garantir que o desempenho do serviço requerido pode ser alcançado. 4.3.5.3 Gerenciamento da Capacidade Componente

O objetivo principal do Gerenciamento da Capacidade componente (CCM) é identificar e compreender o desempenho, capacidade e utilização de cada um dos indivíduos componentes no âmbito da tecnologia utilizada para apoiar o De serviços de TIs, incluindo a infra-estrutura, ambiente, Dados e aplicaçãos. Isto assegura a melhor utilização possível da corrente de hardware e recursos de software, a fim de alcançar e manter o acordado nível de serviços. Todos os

ITIL V3 - Service Design - Página:

155 de 477

componentes de hardware e componentes de software muitos na infra-estrutura de TI têm uma capacidade finita de que, quando se aproximou ou ultraado, tem o potencial de causar problemas de desempenho. Este sub-processo está preocupado com componentes como processadores, memória, discos, largura de banda de rede, conexões de rede etc Então, informações sobre a utilização dos recursos têm de ser recolhidos em uma base contínua. Monitores deve ser instalado no hardware individual e os componentes de software e, em seguida, configurada para recolher os dados necessários, o que é acumulado e armazenado durante um período de tempo. Trata-se de um atividade geralmente levada a cabo através monitoramento e controlar dentro Operação de Serviço. Um direto ao CCM deve ser aplicado dentro deste sub-processo. Como em Gerenciamento da Capacidade de serviço, A chave para o sucesso CCM é a previsão questões, sempre que possível, e, portanto, tem que ser próativa e preditiva. No entanto, há ocasiões em que CCM tem que reagir a problemas específicos que são causadas por uma falta de capacidade, ou a utilização ineficiente do componente. A partir de um conhecimento e compreensão do uso dos recursos por cada um dos serviços que estão sendo executados, os efeitos de mudanças no uso dos serviços pode ser estimada e hardware ou atualizações de software pode ser orçado e planejado. Como alternativa, os serviços podem ser equilibrada entre os recursos existentes para fazer uso mais eficaz dos recursos atuais. 4.3.5.4 As atividades subjacentes de Gerenciamento da Capacidade

As atividades descritas nesta seção são necessários para apoiar os processos de sub- Gerenciamento da Capacidade, E essas atividades pode ser feito tanto de forma reativa ou proativa, ou mesmo preventivamente. A principal diferença entre os sub-processos está nos dados que estão sendo monitorados e coletados, ea perspectiva de que é analisado. Por exemplo, o nível de utilização dos componentes individuais no infra-estruturas - tais como processadores, discos e as ligações de rede - é de interesse em Gerenciamento da Capacidade componente, Enquanto que a operação rendimento taxas e tempo de respostas são de interesse em Gerenciamento da Capacidade de serviço. Para Gerenciamento da Capacidade de negócios, As taxas de transação de transferência para a necessidade do serviço online a ser traduzido em volumes de negócios - por exemplo, em termos de facturas de venda levantada ou pedidos. O maior desafio Gerenciamento da Capacidade é entender a relação entre as demandas e exigências do negócio e os negócios carga de trabalho, E de ser capaz de traduzir estes em termos de impacto e efeito destas sobre o serviço e recurso carga de trabalhos e utilizações, de modo que adequado limiars pode ser fixada em cada nível.

ITIL V3 - Service Design - Página:

156 de 477

Atividades de ajuste e otimização Um certo número de actividades têm de ser realizadas de forma iterativa e formar um ciclo natural, tal como ilustrado na Figura 4.12.

Figura 4.12 Iterativo actividades em curso de Gerenciamento da Capacidade

Estas atividades proporcionam a informação histórica básica e dispara necessário para todas as outras atividades e processos dentro Gerenciamento da Capacidade. Os monitores devem ser estabelecidos em todos os componentes e para cada um dos serviços. Os dados devem ser analisados utilizando, sempre que possível, os sistemas de especialistas para comparar os níveis de utilização contra limiars. Os resultados da análise devem ser incluídas nos relatórios e recomendações feitas conforme o caso. Alguma forma de mecanismo de controle pode então ser colocado em prática para dar seguimento às recomendações. Isto pode assumir a forma de serviços de compensação, equilibrando carga de trabalhos, mudando simultaneidade níveis e adicionar ou remover recursos. Toda a informação acumulada durante estas actividades devem ser armazenadas no Capacidade do Sistema de Informação de Gestão (CMIS) e, em seguida, o ciclo começa novamente, monitorando as alterações feitas para garantir que eles tiveram um efeito benéfico e coletando mais dados para ações futuras.

ITIL V3 - Service Design - Página:

157 de 477

Monitorar a utilização Os monitores devem ser específicos para sistemas operacionais específicos, configurações de hardware, aplicaçãos, etc É importante que os monitores podem coletar todos os dados necessários para o processo de gestão de capacidade, de um componente ou serviço específico. Típicos dados monitorizados inclui: • • • • • • • • • • • • • •

A utilização do processador Utilização de memória Por cento por processador transação tipo Taxas de ES (física e buffer) e utilização de dispositivo Comprimentos de fila Utilização de disco Taxas de transação Os tempos de resposta Lote duração O uso de banco de dados O uso de índice Taxas de acerto Concorrente usuário números Tráfego taxas de rede.

Ao considerar os dados que precisam ser incluídos, uma distinção deve ser feita entre os dados coletados para monitorar capacidade (E.g. rendimento) E os dados para monitorizar atuação (E.g. tempo de respostas). Os dados de ambos os tipos é exigido pelo serviço e Gerenciamento da Capacidade componente sub-processos. Este monitoramento e recolha precisa incorporar todos os componentes na serviço, Assim, monitorar a experiência do "end-to-end 'do cliente. Os dados devem ser recolhidas a nível total de utilização de recursos e com um perfil mais detalhado para a carga que cada serviço coloca em cada componente particular. Isso precisa ser realizado em toda a tecnologia de acolhimento, ou servidor, O local, rede servidor e cliente ou estação de trabalho. Da mesma forma que os dados precisam ser coletados para cada serviço. Parte do monitoramento atividade deve ser de limiares e linhas de base ou os perfis dos níveis normais de operação. Se estes são ultraados, os alarmes devem ser levantadas e relatório de exceçãos produzidos. Esses limiares e linha de bases deveriam ter sido determinada a partir da análise dos dados gravados anteriormente, e pode ser fixado a ambos os componente e nível de serviço. Todos os limites devem ser fixado abaixo do nível em que o componente ou serviço é sobre-utilizado, ou abaixo das metas do SLA. Quando o limiar é atingido ou ameaçado, ainda há uma oportunidade de tomar medidas corretivas antes que o SLA foi violado, ou o recurso tornou-se sobre-utilizado e tem havido um período de fraco desempenho. O acompanhamento e gestão destes

ITIL V3 - Service Design - Página:

158 de 477

eventos, limites e alarmes é coberto em detalhes no Operação de Serviço publicação. Muitas vezes, é mais difícil obter os dados sobre os volumes de negócios atuais, conforme exigido pela istração de Empresas Capacidade sub-processo. Estas estatísticas podem precisar de ser derivada a partir dos dados disponíveis para o serviço e Gerenciamento da Capacidade componente sub-processos. Monitoramento do tempo de resposta Muitos têm SLAs usuário tempos de resposta como uma das metas a serem medidos, mas igualmente muitos organizaçãos têm grande dificuldade em apoiar esta exigência. Tempos de resposta do usuário de TI e serviços de rede pode ser monitorado e medido pelo seguinte: •

•

•

•

Incorporando código específico dentro cliente e servidor aplicações de software. Isto pode ser usado para fornecer tempos completo 'end-toend "serviço de resposta ou de pontos intermediários de temporização para quebrar a resposta global nos seus componentes constituintes. Os números obtidos com estas ferramentas dão os tempos de resposta reais como percebidos pelos usuários de um serviço. Uso de 'script' sistemas robóticos com software de emulação de terminal. Esses sistemas consistem em sistemas cliente com software de emulação de terminal (navegador por exemplo, ou sistemas de Telnet) e software especializado script para gerar e medir as transações e respostas. Esses sistemas geralmente fornecem vezes amostra "end-toend" de resposta do serviço e são úteis para fornecer tempos de resposta representativas, especialmente para a fase de multi- transaçãos ou interações complexas. Estes só dar tempo de resposta de amostra, não os tempos de resposta reais como percebidos pelos usuários reais do serviço. Usando o software de monitoramento distribuído agente. Informações úteis sobre serviços tempo de respostas pode ser obtida através da distribuição de sistemas de agente de software de monitorização em pontos diferentes de uma rede (por exemplo, em países diferentes na internet). Estes sistemas podem ser usados para gerar transações de uma série de locais e dar medições periódicas de um site de internet como percebido pelos usuários internacionais de um site na Internet. No entanto, novamente as vezes recebemos são apenas indicações dos tempos de resposta e não são o real usuário tempos de resposta. Usando específica monitoramento ivo sistemas. Acompanhamento de um número de amostra representativa de sistemas cliente. Este método baseia-se na conexão de sistemas de monitoramento de rede específicos, muitas vezes referida como "sniffers" sendo inseridos em locais adequados, dentro da rede. Estes podem então monitorar, gravar e tempo de todo o tráfego que a um determinado ponto dentro da rede.

ITIL V3 - Service Design - Página:

159 de 477

Uma vez registrado, o tráfego pode ser analisado a dar informações detalhadas sobre os tempos de resposta dos serviços. Mais uma vez, no entanto, estes só podem ser usados para dar uma aproximação para os tempos de resposta reais do utilizador, embora estes sejam frequentemente muito perto a situação do mundo real, mas isso depende da posição do próprio monitor dentro do Infra-estrutura de TI. Em alguns casos, uma combinação de um número de sistemas podem ser utilizados. O monitoramento dos tempos de resposta é um complexo processo mesmo se se trata de um serviço em casa a funcionar numa rede privada. Se este é um serviço de internet externo, o processo é muito mais complexo devido ao grande número de diferentes organizações e as tecnologias envolvidas. Uma empresa privada com um grande site implementou um serviço de monitoramento de site de um provedor externo fornecedor que proporcionaria alarmes automáticos no disponibilidade e capacidade de resposta do seu site. A disponibilidade e velocidade dos pontos de monitorização foram menores do que as do sítio a ser monitorizado. Portanto, os números produzidos pelo serviço foram da disponibilidade e da capacidade de resposta do monitoramento serviço em si, mais do que os do website monitorado. Ao implementar serviços de monitoramento externos, garantir que o nível de serviços e atuação compromissos do serviço de monitoramento são maiores do que os do serviço (s) que está sendo monitorado. Análise Os dados coletados a partir do monitoramento devem ser analisados para identificar as tendências do qual a utilização normal e nível de serviços, ou linhas de base, pode ser estabelecida. Através da monitorização regular e comparação com este linha de base, Condições de exceção na utilização do indivíduo componentes ou serviço limiars pode ser definido, e as violações ou quase no SLAs podem ser relatados e acionadas. Além disso, os dados podem ser usados para prever o futuro recurso uso, ou para acompanhar o crescimento do negócio real contra o crescimento previsto. A análise dos dados pode identificar problemas, tais como: • • • • • •

'Gargalos' ou 'pontos quentes' na infra-estrutura Distribuição inadequada de carga de trabalho através de recursos disponíveis Indexação de dados Inapropriado Lacunas na aplicação projeto Aumento inesperado nas cargas de trabalho ou transação taxas Programação ineficiente ou uso de memória.

ITIL V3 - Service Design - Página:

160 de 477

A utilização de cada componente e serviço precisa ser considerado sobre o curto, médio e longo prazo, bem como a utilização, mínimo, máximo e médio para esses períodos registrados. Normalmente, o padrão de curto prazo abrange a utilização durante um período de 24 horas, enquanto que a médio prazo, pode cobrir um período de uma a quatro semanas, e a longo prazo, um período de um ano de duração. Ao longo do tempo, a tendência na utilização dos recursos pelas várias De serviços de TIs vai se tornar aparente. A utilidade desta informação é ainda reforçada através da gravação de todos os factores que contribuem para a observados picos e vales na utilização - por exemplo, se uma alteração de processo de negócio ou pessoal coincide com quaisquer desvios a utilização normal. É importante compreender a utilização, em cada um destes períodos, de modo que as alterações na utilização de qualquer serviço pode estar relacionada com alterações previsíveis no nível de utilização do indivíduo componentes. A capacidade de identificar o hardware específico ou componentes de software em que um serviço de TI é particular depende melhorou muito por um preciso, up-todate e CMS abrangente. Quando da utilização de um determinado recurso é considerado, é importante compreender ambos o nível total de utilização e para a utilização dos serviços individuais do recurso. Se um processador que é de 75% carregado durante a hora de ponta está a ser utilizado por dois serviços diferentes, A e B, é importante saber quanto do total de 75% está a ser utilizado por cada serviço. Assumindo que o sistema despesas gerais em que o processador é de 5%, a carga remanescente de 70% pode ser dividida entre os dois serviços. Se um mudar em um serviço ou Serviço B é estimada a dobrar a sua carga no processador, o processador teria ser sobrecarregado. No entanto, se o serviço usa 60% A e B Service usa 10% do processador, em seguida, o processador seria sobrecarregados se um serviço duplicou o seu carregamento no processador. Mas, se o serviço B duplicou o seu carregamento no processador, então o processador não seria, necessariamente, ser sobrecarregado. Afinação A análise dos dados monitorados pode identificar áreas da configuração que podem ser ajustadas para melhorar a utilização dos recursos do sistema de serviço, e o componente ou a melhorar o desempenho do serviço particular. Afinação as técnicas que são de assistência incluem:

ITIL V3 - Service Design - Página:

161 de 477

•

•

•

•

Balanceamento carga de trabalhos de tráfego e - as transações podem chegar ao host ou servidor a uma porta de entrada particular, dependendo do local onde o transação foi iniciado; equilibrar a razão de pontos de iniciação para gateways pode fornecer afinação benefícios Equilíbrio de tráfego disco - armazenamento de dados em disco de forma eficiente e estratégica, por exemplo, divisão de dados em todo fusos muitos podem reduzir a contenção de dados Definição de um bloqueio aceite estratégia que especifica quando os bloqueios são necessários e no nível apropriado, por exemplo, banco de dados, página, arquivo de registro, e linha - atrasando o bloqueio até que uma atualização é necessária pode proporcionar benefícios A utilização eficiente da memória - pode incluir olhando para utilizar memória mais ou menos, dependendo das circunstâncias.

Antes de implementar qualquer uma das recomendações decorrentes da afinação técnicas, pode ser conveniente considerar testar a validade da recomendação. Por exemplo, "Gestão da Demanda pode ser usado para evitar a necessidade de realizar qualquer ajuste? 'Ou' Pode a mudança proposta ser modelado para mostrar a sua eficácia antes de ser implementado? Implementação O objetivo desse atividade é introduzir o viver Serviços de exploração de todas as alterações que foram identificadas pela análise, acompanhamento e afinação actividades. A execução de quaisquer alterações decorrentes dessas atividades deve ser feita através de um rigoroso, formal Gestão da Mudança processo. O impacto de sistema de mudanças de ajuste pode ter implicações importantes sobre a clientes do serviço. O impacto e risco associada com estes tipos de mudanças são prováveis de ser maior do que a de outro tipo diferente de modificações. É importante que o controlo adicional tem lugar, de modo que os efeitos da mudança pode ser avaliado. Pode ser necessário efectuar outras alterações ou regredir algumas das alterações originais. Exploração de novas tecnologias Isso envolve a compreensão de novas técnicas e novas tecnologias e como elas podem ser usadas para apoiar o negócio e inovar melhorias. Pode ser apropriado para introduzir uma nova tecnologia para melhorar a provisão e e do De serviços de TIs em que a organização é dependente. Esta informação pode ser obtida através do estudo de literatura profissional (artigos de revistas e imprensa) e pela participação: •

Seminários de promoção por hardware e fornecedores de software

ITIL V3 - Service Design - Página:

162 de 477

• •

Reuniões de grupos de usuários de fornecedors de hardware e software de potencial Usuário reuniões de grupo para outros profissionais de TI envolvidos na Gerenciamento da Capacidade.

Cada uma delas fornece fontes de informação relacionada com as técnicas possíveis, hardware, tecnologia e software, o que pode ser vantajoso para a TI a implementar para obter benefícios comerciais. No entanto, em todos os momentos Gerenciamento da Capacidade deve reconhecer que a introdução e utilização desta nova tecnologia deve ser custo-justificado e entregar benefício real para o negócio. Não é apenas a nova tecnologia em si que é importante, mas Gerenciamento da Capacidade também deve ter consciência das vantagens de ser obtidos a partir do uso de novas tecnologias, usando técnicas como a "grid computing", "virtualização" e "computação on-demand '. Projetando resiliência Gerenciamento da Capacidade auxilia na identificação e melhoria da resiliência na infra-estrutura de TI ou qualquer subconjunto de que, onde quer que seja economicamente justificado. Em conjunto com a Gerenciamento de Disponibilidade, Gerenciamento de Capacidade deve usar técnicas como Componente Análise de Impacto falha (CFIA, como descrito na seção 4.4 na Gestão de disponibilidade) para identificar como suscetíveis a corrente configuração é o falha ou sobrecarga de indivíduo componentes e fazer recomendações sobre quaisquer soluções custo-eficazes. Gestão da Capacidade deve ser capaz de identificar o impacto na disposição recursos de falhas particulares, e do potencial para a execução dos serviços mais importantes sobre os recursos restantes. Assim, o provisão de reposição capacidade pode atuar como resiliência ou fail-over em situações de falha. Os requisitos para a resistência no Infra-estrutura de TI deve ser sempre considerada no momento do serviço ou sistema projeto. No entanto, para muitos serviços, a resiliência do serviço é apenas considerado se permanecer no vivo operacional usar. Incorporando resiliência em Design de Serviços é muito mais eficaz e eficiente do que tentar adicioná-lo em uma data posterior, uma vez que um serviço tornou-se operacional. 4.3.5.5 Limiar gestão e controle

Os limites técnicos e restrições sobre os serviços e componentes individuais podem ser usados pelas atividades de monitoramento para definir o limite no qual os avisos e alarmes são levantadas e relatórios de exceção são produzidos. No entanto, o cuidado deve ser exercido quando definindo limites, porque muitos limiars são dependentes do trabalho a ser executado no especial componente.

ITIL V3 - Service Design - Página:

163 de 477

A gestão e controlar de serviço e limiares de componentes é fundamental para a prestação efectiva de serviços para atender sua concordou nível de serviços. Ele garante que todos os limites de serviço e componente são mantidos em níveis adequados e estão continuamente, automaticamente monitoradas, e alertas e avisos gerados quando violações ocorrem. Sempre limites monitorados são violados ou ameaçados, em seguida, os alarmes são levantadas e desvios, avisos e relatório de exceçãos são produzidos. Análise da situação deve, então, ser preenchido e medidas correctivas tomadas sempre que se justificar, garantindo que a situação não se repetir. Os mesmos itens de dados podem ser usados para identificar quando os SLAs sejam violados ou susceptível de ser violado ou quando componente atuação degrada ou seja susceptível de ser degradada. Definindo limites abaixo ou acima das metas reais, a ação pode ser tomada e uma violação do SLA metas evitado. Limiar monitoramento não só deve alarmar em exceder um limite, mas também deve monitorar a taxa de mudar e prever quando o limite será atingido. Por exemplo, um monitor de espaço em disco deve monitorar a taxa de crescimento e de gerar um alarme quando a taxa de corrente vai fazer com que o disco para ser completa dentro dos próximos dias N. Se um disco de 1 GB de capacidade atingiu 90%, e está a crescer a 100KB por dia, será 1000 dias antes de estar completa. Se ele está a crescer a 10 MB por dia, só será 10 dias antes ele está cheio. O acompanhamento e gestão destes eventos e alarmes é coberto em detalhes no Operação de Serviçopublicação s. Pode haver ocasiões em que a optimização dos componentes de infra-estrutura e os recursos são necessários para manter ou melhorar o desempenho ou rendimento. Isso muitas vezes pode ser feito através de Workload Management, que é um termo genérico para cobrir tais ações como: •

• •

•

Reprogramação de um determinado serviço ou carga de trabalho para executar em um horário diferente do dia ou dia da semana, etc (geralmente longe de horários de pico para fora do pico janelas) - que, muitas vezes, significa ter que fazer ajustes para trabalho de agendamento de software Mover um serviço ou carga de trabalho de um local ou conjunto de CIs para outro - muitas vezes para equilibrar a utilização ou o tráfico Técnico 'virtualização': configurar e usar técnicas de virtualização e sistemas para permitir a circulação de processamento em torno da infraestrutura para dar melhor atuação/ Resistência de uma forma dinâmica Limitar ou mover demanda por componentes ou recursos através de técnicas de gestão da procura, em conjunto com a gestão financeira (ver secção 4.3.5.6).

Só será possível gerenciar cargas de trabalho de forma eficaz se existe um bom entendimento de que as cargas de trabalho será executado em que momento e quanto a utilização de recursos de cada carga de trabalho lugares na infraestrutura de TI. Monitoramento diligente e análise de cargas de trabalho,

ITIL V3 - Service Design - Página:

164 de 477

juntamente com um CMIS abrangentes, portanto, são necessárias em um curso operacional base. 4.3.5.6 Gerenciamento da Demanda

O principal objetivo de Gerenciamento da Demanda é influenciar usuário e cliente demanda por serviços de TI e gerenciar o impacto recursos de TI. Este atividade pode ser realizada como um curto prazo exigência porque não existem suficientes actual capacidade para apoiar o trabalho a ser executado, ou, como uma política deliberada de gestão de TI, para limitar a capacidade necessária no longo prazo. A curto prazo de Gestão da procura pode ocorrer quando há uma parcial falha de um recurso crítico no Infra-estrutura de TI. Por exemplo, se houver uma falha de um processador dentro de um multi-processador servidor, Pode não ser possível executar a gama de serviços. No entanto, um número limitado de serviços poderia ser executado. Gerenciamento da Capacidade deve estar ciente da prioridade do negócio de cada um dos serviços, conhecer as necessidades de recursos de cada serviço (Neste caso, a quantidade de energia do processador necessário para executar o serviço) e, em seguida, ser capaz de identificar quais os serviços que podem ser executados enquanto há uma quantidade limitada de energia do processador disponível. Longo prazo Gerenciamento de Demanda pode ser necessária quando é difícil justificar um custo-atualização caro. Por exemplo, muitos processadores são muito utilizado por apenas algumas horas por dia, tipicamente 10,00-12,00 e 14,00-16,00. Dentro destes períodos, o processador pode ser sobrecarregado por apenas uma ou duas horas. Para as horas entre 18.00-08.00, estes processadores são só muito levemente carregado e os componentes são subutilizados. É possível justificar o custar de uma atualização para fornecer capacidade adicional para apenas algumas horas em 24 horas? Ou é possível influenciar a demanda e espalhar a exigência de recurso através de 24 horas, deste modo retardando ou evitando totalmente a necessidade de um melhoramento caro? Gerenciamento da Demanda precisa entender que os serviços estão utilizando o recurso e em que nível, eo cronograma de quando eles devem ser executados. Em seguida, uma decisão pode ser tomada em saber se será possível influenciar o uso de recursos e, em caso afirmativo, qual é a opção apropriada. A influência sobre os serviços que estão em execução poderia ser exercida por: •

Restrições físicas: Por exemplo, pode ser possível parar alguns serviços de estar disponível em certos momentos, ou para limitar o número de clientes que podem usar um serviço em particular - por exemplo, através

ITIL V3 - Service Design - Página:

165 de 477

•

da limitação do número de concorrente usuários, a restrição poderia ser implementado em um recurso específico ou componente - Por exemplo, através da limitação do número de ligações físicas a um router ou comutador da rede Restrições financeiras: If carregamento para De serviços de TIs está no lugar, taxas reduzidas podem ser oferecidos para a execução de trabalho em momentos do dia quando há, actualmente, menos demanda para o recurso. Isto é conhecido como taxas diferenciadas.

4.3.5.7 Modelagem e tendências

Um objetivo primordial de Gerenciamento da Capacidade é de prever o comportamento de serviços de TI em um determinado volume e variedade do trabalho. Modelagem é um atividade que pode ser utilizado para efeito benéfico em qualquer dos sub-processos de gestão de capacidade. Os diferentes tipos de modelagem ampla, de fazer estimativas baseadas em experiência e informação actual utilização de recursos, a piloto estudos, protótipos e em grande escala referências. O primeiro é uma abordagem barata e razoável para o dia-a-dia pequenas decisões, enquanto o último é caro, mas pode ser aconselhável quando a implementação de um novo grande projeto ou serviço. Com todos os tipos de modelação, níveis semelhantes de precisão pode ser obtida, mas todos são totalmente dependente da perícia da pessoa que a construção modelo e as informações usadas para criá-lo. Baselining A primeira etapa de modelagem é a criação de um linha de base modelo que reflete com precisão o desempenho que está sendo alcançado. Quando este modelo base foi criada, modelagem preditiva pode ser feito, ou seja, pedir ao 'E se?' Questões que refletem falhas, planeado mudars para o equipamento e / ou o volume / variedade de carga de trabalhos. Se o modelo de base é preciso, em seguida, a precisão do resultado das falhas potenciais e mudanças podem ser confiáveis. Gerenciamento da Capacidade eficaz, juntamente com técnicas de modelagem, permite Gerenciamento da Capacidade para responder à 'E se?' Perguntas. E se o rendimento A dobra de serviço? E se o Serviço B é movido do servidor atual para um novo servidor - O que irá ser o efeito sobre o tempo de respostas dos dois serviços? Análise de tendências Análise de tendências pode ser feito sobre a utilização dos recursos e serviço atuação informação que foi recolhida pelo Gerenciamento da Capacidade processo. Os dados podem ser analisados numa folha de cálculo, e as

ITIL V3 - Service Design - Página:

166 de 477

instalações de gráficos e tendências e previsão utilizadas para mostrar a utilização de um determinado recurso, durante um período de tempo anterior, e como pode ser esperado para mudar no futuro. Normalmente, a análise de tendência só fornece estimativas de informações futuras utilização de recursos. Análise de tendência é menos eficaz na produção de uma estimativa precisa dos tempos de resposta, caso em que um ou outro ou analítico modelagem, simulação devem ser utilizadas. Análise de tendência é mais eficaz quando há um linear relação entre um pequeno número de variáveis, e menos eficaz quando há não-lineares relações entre as variáveis, ou quando há muitas variáveis. Modelagem analítica Modelos analíticos são representações do comportamento de sistemas de computador usando técnicas matemáticas, por exemplo, multi-classe teoria das filas rede. Tipicamente, um modelo é construído usando um pacote de software em um PC, especificando dentro do pacote do componentes e da estrutura da configuração que tem de ser modelado, e a utilização dos componentes, por exemplo, processador, memória e discos, pelos diversos carga de trabalhos ou aplicaçãos. Quando o modelo é executado, a teoria de filas é utilizada para calcular os tempos de resposta do sistema de computador. Se os tempos de resposta previstos pelo modelo são suficientemente próximas para os tempos de resposta gravados na vida real, o modelo pode ser visto como uma representação precisa do sistema de computador. A técnica de modelagem analítica requer menos tempo e esforço do que modelagem, simulação, Mas geralmente dá resultados menos precisos. Além disso, o modelo deve ser mantido up-to-date. No entanto, se os resultados estão dentro de 5% de precisão para a utilização, e de 15-20% para os tempos de resposta da aplicação em linha, os resultados são geralmente satisfatórios. Modelagem, simulação Envolve a simulação modelagem de eventos discretos, por exemplo, transação taxas de chegada, contra determinada configuração de hardware. Este tipo de modelagem podem ser muito precisos no dimensionamento novo aplicaçãos ou prever os efeitos de mudars em aplicações existentes, mas também pode ser muito demorado e, por conseguinte, dispendioso. Ao simular taxas de chegada de transação, tem um número de funcionários entre uma série de transações a partir de scripts preparados, ou usar o software para as mesmas transações de entrada de script com uma taxa de chegada aleatória. Qualquer uma destas abordagens, leva tempo e esforço para preparar e executar. No entanto, pode ser custo-justificado para organizaçãos com

ITIL V3 - Service Design - Página:

167 de 477

grande serviços e os sistemas em que a grandes custar e as implicações de desempenho associados assumem grande importância. 4.3.5.8 Aplicação dimensionamento

Aplicação dimensionamento tem vida útil limitada. Ele é iniciado no projeto fase de um novo serviço, ou quando há uma mudança significativa para um serviço existente, e completa-se quando o aplicação é aceito no ao vivo operacional ambiente. Dimensionamento de atividades deve incluir todas as áreas de tecnologia relacionados com as aplicações, e não apenas os próprios aplicativos. Isto deve incluir a infra-estrutura, meio ambiente e de dados, e, muitas vezes, usar a modelagem e tendências técnicas. O primário objetivo aplicação de cola é o de estimar a recurso requisitos para apoiar uma proposta de alteração a um serviço existente ou a implementação de um novo serviço, para garantir que ele cumpre a sua necessária nível de serviços. Para alcançar este objectivo, a aplicação de dimensionamento tem de ser uma parte integrante do Serviço Ciclo de Vida. Durante os requisitos iniciais e de design, os níveis de serviço exigidos devem ser especificados em uma SLR. Isto permite que o Design de Serviços e desenvolvimento de empregar as tecnologias pertinentes e dos produtos para alcançar um design que satisfaz os níveis desejados de serviço. É muito mais fácil e menos dispendioso para atingir os níveis de serviço exigidos se Design de Serviços considera os níveis de serviço exigidos no início do Ciclo de Vida do Serviço, em vez de em algum momento mais tarde. Outras considerações são a aplicação de colagem resiliência aspectos que podem ser necessárias para a construção, na concepção de novos serviços. Gerenciamento da Capacidade é capaz de fornecer aconselhamento e orientação para o Gerenciamento de Disponibilidade processo sobre os recursos necessários para proporcionar o nível necessário de atuação e resiliência. O dimensionamento do aplicação deve ser refinada como a concepção e desenvolvimento processo progride. O uso de modelação podem ser usados dentro do aplicação dimensionamento processo. As SLRs dos desenvolvimentos de aplicações planejadas não deve ser considerado isoladamente. Os recursos a serem utilizados pela aplicação são susceptíveis de ser compartilhada com outros serviços, potencial e ameaças a metas de SLA existentes devem ser reconhecidos e gerenciado. Ao comprar pacotes de software de fornecedores externos, é tão importante para entender as necessidades de recursos necessários para apoiar o serviço. Muitas vezes pode ser difícil de se obter essa informação a partir do fornecedors e pode variar, dependendo rendimento. Por conseguinte, é benéfico para

ITIL V3 - Service Design - Página:

168 de 477

identificar semelhante clientes do produto e ganhar uma compreensão das implicações de recursos a partir deles. Pode ser pertinentes ao benchmark, avaliar ou o julgamento do produto antes da compra. A qualidade deve ser construído dentro Alguns aspectos do serviço qualidade pode ser melhorada após a aplicação (hardware adicional pode ser adicionado para melhorar o desempenho, por exemplo). Outros - em particular aqueles relacionados, tais como confiança e manutenção software de aplicações - dependem da qualidade a ser 'construído em', uma vez que a tentativa de adicioná-lo numa fase posterior é, no redesenho efeito, e remodelação, normalmente, a um custo muito mais elevado do que o original desenvolvimento. Mesmo no exemplo de hardware citado acima, é provável que o custo para adicionar mais adicional capacidade após a implementação do serviço, e não como parte do original projeto.

4.3.6 Triggers, entradas, saídas e interfaces Há muitos gatilhos que iniciarão as atividades de gerenciamento de capacidade. Estes incluem: • • • • • • • •

Violações de serviços, capacidade ou atuação eventos e alertars, incluindo limiar eventos Relatório de exceçãos Re periódicavisão da capacidade atual e desempenho e à rever de previsões, relatórios e planos Serviços novos e modificados que requerem capacidade adicional Tendência periódica e modelagem Revisão e revisão de negócios e de TI planos e estratégias Revisão e revisão de projetos e estratégias Revisão e revisão de SLAs, Olas, contratos ou quaisquer outros acordos.

Há um número de fontes de informação que são relevantes para a Gestão da Capacidade processo. Alguns destes são os seguintes. 4.3.6.1 Entradas •

•

Informações de negócios: De negócio da organização estratégia, Os planos e os planos financeiros e informações sobre suas necessidades atuais e futuras. Informações de serviço e de TI: De Estratégia de Serviço, A estratégia de TI e planos e atual orçamentos, abrangendo todas as áreas de tecnologia e planos de tecnologia, incluindo a infra-estrutura, ambiente, Dados e aplicaçãos, e da maneira em que eles se relacionam com a estratégia de negócios e planos.

ITIL V3 - Service Design - Página:

169 de 477

• •

•

•

•

•

• •

Componente desempenho e capacidade informação: De tecnologia existentes e novos, de fabricantes e fornecedors. Serviço atuação questões: O incidente e Gerenciamento de Problemas processos, com incidentes e problemas relacionados ao mau desempenho. Informações sobre o serviço: A partir do processo de SLM, com detalhes dos serviços da Portfólio de Serviços e a Catálogo de Serviços e meta de nível de serviços dentro de SLAs e SLRs, e, possivelmente, a partir da monitoramento de SLAs, serviço de opiniões e violações dos SLAs. Informações financeiras: De Gestão Financeira, a custar de serviço profissionalvisão, O custo de recursos, componentes e upgrades, o benefício resultante de negócios e os planos financeiros e orçamentos, bem como os custos associados ao serviço e componente falha. Alguns dos custos de componentes e atualizações para os componentes que serão obtidos a partir de aquisição, fornecedors e os fabricantes. Alterar as informações: De a Gestão da Mudança processo, com um Alterar agendamento e uma necessidade de avaliar todas as mudanças para a sua impacto sobre a capacidade da tecnologia. As informações de desempenho: A partir do Sistema de Informação de Gestão de Capacidade (CMIS) sobre o desempenho atual de ambos os serviços existentes e Infra-estrutura de TI componentes. CMS: Contendo informações sobre a relaçãos entre o negócio, Os serviços, o serviços de apoios e a tecnologia. Workload informação: De a Operações de TI equipe, com horários de todo o trabalho que precisa ser executado, e informações sobre as dependências entre os diferentes serviços e informações, e as interdependências dentro de um serviço.

4.3.6.2 Saídas

As saídas dos Gerenciamento da Capacidade são utilizados em todas as outras partes do processo, Por muitos outros processos e por outras partes do organização. Muitas vezes, essa informação é fornecida como relatórios eletrônicos ou displays em áreas comuns, ou como páginas de intranet servidors, para garantir a informação o mais up-to-date é sempre utilizado. A informação fornecida é como se segue: •

•

O Capacidade do Sistema de Informação de Gestão (CMIS): Contém as informações necessárias a todos os sub-processos dentro do Gerenciamento de Capacidade. Por exemplo, os dados monitorizados e recolhidas como parte do componente e Gerenciamento da Capacidade de serviço é usada em Gerenciamento da Capacidade de negócios para determinar os componentes de infra-estrutura o que ou upgrades componentes são necessárias, e quando. O Plano de capacidade: Usado por todas as áreas do negócio e gestão de TI. e é acionado pela Provedor de serviços de TI ea alta istração

ITIL V3 - Service Design - Página:

170 de 477

•

•

•

•

•

da organização para planejar a capacidade da infra-estrutura de TI. Ele também fornece planejamento de entrada para muitas outras áreas de TI e negócios. Ele contém informações sobre o uso atual de serviço e componentes, e os planos para o desenvolvimento da capacidade de TI para atender às necessidades do crescimento de ambos os serviços existentes e os novos serviços acordados. O Plano de capacidade deve ser usada ativamente como base para a tomada de decisão. Muitas vezes, os planos de capacidade são criadas e nunca referido ou usado. Informações de serviço e relatórios de desempenho: Usado por muitos outros processos. Por exemplo, a Gerenciamento da Capacidade processo de ajuda Gerenciamento de Nível de Serviço com a elaboração de relatórios e análise de serviço atuação eo desenvolvimento de SLRs novos ou mudanças SLAs existentes. Ele também auxilia o processo de gestão financeira, identificando quando o dinheiro precisa ser orçado para atualizações de infraestrutura de TI, ou a compra de novos componentes. Workload análise e relatórios: Usado por operações de TI para avaliar e implementar mudanças em conjunto com a Gestão da Capacidade de agendar ou reagendar quando os serviços ou cargas de trabalho são executados, para garantir que o uso mais eficaz e eficiente é feito dos recursos disponíveis. Ad hoc relatórios de capacidade e desempenho: Usado por todas as áreas de Gerenciamento da Capacidade, TI e do negócio para analisar e resolver questões de serviço e desempenho. Previsões e relatórios de previsão: Usado por todas as áreas para analisar, prever e prever negócio e de TI cenários e suas possíveis soluções. Soleiras, alertas e eventos.

4.3.7 Indicadores Chave de Desempenho Alguns dos KPIs e métricos que podem ser usados para avaliar a eficiência e eficácia das atividades de gerenciamento de capacidade deve incluir: •

•

Precisas previsões de negócios: • Produção de carga de trabalho previsões sobre o tempo • Precisão percentual de previsões de tendências de negócios • Adoção oportuna de planos de negócios para o Plano de Capacidade • Redução do número de variaçãos dos planos de negócios e planos de capacidade. Conhecimento das tecnologias atuais e futuras: • Aumento da capacidade de monitorar o desempenho e rendimento de todos os serviços e componentes • Justificação oportuna e implementação de novas tecnologias, de acordo com os requisitos de negócios (tempo, custar e funcionalidade)

ITIL V3 - Service Design - Página:

171 de 477

•

•

•

Redução no uso de tecnologia de idade, fazendo com que, devido à violado SLAs problemas com e ou desempenho. Capacidade de demonstrar custo-eficácia: • Redução no último minuto de compra para resolver problemas de desempenho urgentes • Redução do excesso de capacidade de TI • Previsões precisas de despesas previstas • Redução da interrupção de negócios causada pela falta de adequada de TI capacidade • Redução relativa do custo de produção da Plano de capacidade. Capacidade de planejar e implementar a capacidade de TI apropriada para atender às necessidades de negócios: • Percentagem de redução do número de incidentes devido à má atuação • Redução percentual em negócios perdidos devido à capacidade inadequada • Todos os novos serviços implementados combinar Nível Requisitos de Serviço (SLRs) • Maior porcentagem de recomendações feitas pelo Gerenciamento da Capacidade são ativados • Redução do número de violações de SLA devido a qualquer serviço de má qualidade atuação ou o desempenho dos componentes pobres.

4.3.8 Gestão da Informação O objetivo do CMIS é fornecer a capacidade e informações relevantes desempenho para produzir relatórios e apoiar a Gestão da Capacidade processo. Esses relatórios fornecem informações valiosas para muitos de TI e Serviço de Gestão de processos. Estes relatórios devem incluir o seguinte. Componente relatórios baseados Para cada componente deve haver uma equipe de técnicos responsáveis pela sua controlar e gestão. Os relatórios devem ser produzidos para ilustrar como os componentes estão realizando e quanto de sua capacidade máxima está sendo usado. Serviço de relatórios baseados Relatórios e informações também devem ser produzidos para ilustrar como o serviço e suas componentes estão realizando com relação às suas metas de serviços gerais e restrições. Esses relatórios servirão de base de SLM e os relatórios de atendimento ao cliente. Relatórios de exceção

ITIL V3 - Service Design - Página:

172 de 477

Relatórios que mostram gestão e pessoal técnico, quando a capacidade eo desempenho de um determinado componente ou serviço se torna inaceitável também são uma exigido a partir da análise de dados de capacidade. É possível definir limites para qualquer componente ou serviço de medição dentro da CMIS. Um exemplo limiar Pode ser que a porcentagem de utilização do processador para um determinado servidor violou a 70% durante três horas consecutivas, ou que o número concomitante de sessão usuários excede o limite acordado. Em particular, relatório de exceçãos são de interesse para o processo de SLM em determinar se os alvos em SLAs foram violados. Também o incidente e Gerenciamento de Problemas processos podem ser capazes de usar os relatórios de excepção na resolução de incidentes e problemas. Relatórios preditivos e previsão Para garantir a Provedor de serviços de TI continua a proporcionar o necessário nível de serviços, o Gerenciamento da Capacidade processo deve prever o futuro carga de trabalhos e crescimento. Para fazer este futuro, componente e serviço capacidade e desempenho deve ser previsto. Isto pode ser feito de uma variedade de maneiras, dependendo das técnicas e da tecnologia utilizada. Mudars para cargas de trabalho por parte do desenvolvimento e implementação de novas funcionalidades e serviços devem ser consideradas juntamente com o crescimento da funcionalidade atual e serviços impulsionada pelo crescimento do negócio. Um exemplo simples de uma previsão de capacidade é uma correlação entre uma empresa motorista e utilização de um componente, por exemplo, utilização do processador com o número de cliente contas. Estes dados podem ser correlacionados para encontrar o efeito que o aumento do número de contas de cliente irá ter sobre a utilização do processador. Se as previsões sobre os requisitos de capacidade futura identificar um requisito para o aumento recurso, Esta exigência precisa de ser entrada para o Plano de capacidade e incluídos dentro do IT orçamento ciclo. Muitas vezes, os relatórios de capacidade são consolidadas em conjunto e armazenado em um site de intranet para que qualquer pessoa pode ar e se referem a eles. 4.3.8.1 Capacidade do Sistema de Informação de Gestão

Muitas vezes, a capacidade de dados é armazenado na tecnologia de ferramentas específicas e bases de dados, e o valor total dos dados, a informação e a sua análise não é obtido. O valor real de dados só podem ser obtidos quando os dados são combinados num único conjunto de integrado, repositórios de informação ou um conjunto de bases de dados. O Capacidade do Sistema de Informação de Gestão (CMIS) é a pedra angular de uma bem sucedida Gerenciamento da Capacidade processo. A informação

ITIL V3 - Service Design - Página:

173 de 477

contida dentro do CMIS é armazenada e analisada por todos os sub-processos de gestão de capacidade, porque é um repositório que contém um número de diferentes tipos de dados, incluindo negócios, serviço de recursos, ou a utilização de dados financeiros, a partir de todas as áreas da tecnologia . No entanto, o CMIS é improvável que seja uma base de dados única, e, provavelmente, existe em várias localizações físicas. Dados de todas as áreas de tecnologia, e todos os componentes que compõem o De serviços de TIs, em seguida, podem ser combinados para análise e provisão de relatórios técnicos e de gestão. Só quando toda a informação está integrado pode relatórios "end-toend 'serviço ser produzido. O integridade e exatidão dos dados dentro do CMIS precisa ser cuidadosamente gerido. Se o CMIS não é parte de um CMS global ou SKMS, então as ligações entre esses sistemas precisam ser implementadas para garantir a consistência e precisão das informações registradas dentro deles. A informação no CMIS é usado para formar a base de relatórios de desempenho e capacidade de gestão e pontos de vista que devem ser entregues a clientes, gestão de TI e pessoal técnico. Além disso, os dados são utilizados para gerar previsões de capacidade futura e permitir Gerenciamento da Capacidade para planejar os requisitos de capacidade futura. Muitas vezes, uma interface web é fornecido para os CMIS para fornecer o o diferentes e pontos de vista requerido fora do Gerenciamento da Capacidade processo si. A gama completa de tipos de dados armazenados dentro do CMIS é o seguinte. Dados comerciais É essencial ter qualidade informações sobre as necessidades atuais e futuras do negócio. Os futuros planos de negócios da organização precisam ser considerados e os efeitos sobre os serviços de TI entendido. Os dados de negócios é usado para prever e validar como as mudanças em drivers de negócio afetam a capacidade eo desempenho do Infra-estrutura de TI. Os dados de negócios devem incluir transações comerciais ou medições, tais como o número de contas, o número de faturas geradas, o número de linhas de produtos. Dados de serviço Para alcançar uma abordagem de serviço orientada para Gerenciamento da Capacidade, serviço dados devem ser armazenados dentro dos CMIS. Dados de serviços típicos são transação tempo de respostas, transação taxas, carga de trabalho volumes, etc Em geral, os SLAs e SLRs fornecer as metas de serviço para o qual o Gerenciamento da Capacidade processo precisa para gravar e monitorar os dados. Para garantir que os alvos na SLAs são alcançados, os limiares de SLM deve ser incluído, de modo que a monitoração atividade pode

ITIL V3 - Service Design - Página:

174 de 477

medir contra esses serviços limiars e aumentar avisos de exceção e relatórios antes de metas de serviço são violados. Utilização de dados de componentes O CMIS também precisa de gravar os dados de recursos consistindo de limite de utilização, e a informação sobre todos os limites da tecnologia componentes apoiar os serviços. A maioria dos componentes de TI têm limitações sobre o nível ao qual eles devem ser utilizados. Além desse nível de utilização, o recurso será mais utilizado eo atuação dos serviços que utilizam o recurso será prejudicada. Por exemplo, o nível máximo de utilização recomendada em um processador pode ser de 80%, ou a utilização de um segmento de LAN Ethernet compartilhada não deve exceder 40%. Além disso, os componentes têm várias limitações físicas além do qual uma maior conectividade ou utilização é impossível. Por exemplo, o número máximo de ligações através de um aplicação ou uma porta de saída é de 100, ou de um determinado tipo de disco tem um físico capacidade de 15GB. Os CMIS deve conter, para cada componente e o máximo desempenho e limites de capacidade, taxas de utilização atuais e do ado e do componente associado limiars. Com o tempo, isso pode exigir grandes quantidades de dados a ser acumulado, então é necessário que haja boas técnicas de análise, agregar e arquivamento de dados. Os dados financeiros O processo de Gerenciamento da Capacidade requer dados financeiros. Para avaliar as opções de atualização alternativos, ao propor vários cenários no Plano de capacidade, O financeira custar das atualizações para os componentes da infra-estrutura de TI, juntamente com a informação sobre o hardware de TI atual orçamento, Deve ser conhecida e incluída nas considerações. A maioria destes dados podem estar disponíveis a partir do Gerenciamento Financeiro para TI processo de serviços, mas de Gestão de Capacidade precisa considerar essas informações ao gerenciar os requisitos de negócios futuros.

4.3.9 Desafios, Fatores Críticos de Sucesso e riscos Um dos grandes desafios Gerenciamento da Capacidade é persuadir o negócio para fornecer informações sobre seus planos de negócios estratégicos, para permitir a Provedor de serviços de TI organização para fornecer eficaz Gestão de Continuidade de Negócios (BCM). Isto é particularmente verdadeiro em situações terceirizados onde pode haver razões comerciais ou confidenciais porque esses dados não podem ser compartilhados. Mesmo que os dados sobre o estratégico de negócios está disponível, pode haver problemas com relação à qualidade e precisão dos dados contidos os planos de negócios em relação a BCM.

ITIL V3 - Service Design - Página:

175 de 477

Um outro desafio é a combinação de todos os dados CCM para um conjunto integrado de informação que pode ser analisada de uma forma consistente para fornecer detalhes do uso de todos os componentes dos serviços. Isto é particularmente desafiador quando as informações das diferentes tecnologias é fornecida por diferentes ferramentas em diferentes formatos. Muitas vezes, o qualidade de informações sobre o desempenho do componente da tecnologia é variável, tanto na qualidade e a sua precisão. As quantidades de informações produzidas por BCM e, especialmente, SCM e CCM, são enormes ea análise dessas informações é difícil de conseguir. As pessoas e os processos precisam se concentrar na chave recursos e a sua utilização, embora não ignorando outras áreas. A fim de fazer isso, apropriada limiars deve ser usado, e confiança colocada sobre as ferramentas e tecnologia para gerenciar automaticamente a tecnologia e fornecer avisos e alertars, quando as coisas se afastam significativamente da "norma". Os QCA principais para o Gerenciamento da Capacidade processo são os seguintes: • • • •

Precisas previsões de negócios Conhecimento das tecnologias atuais e futuras Capacidade de demonstrar custo-eficácia Capacidade de planejar e implementar a TI apropriada capacidade para combinar com necessidade de negócio.

Alguns dos principais riscos associados à gestão de capacidade incluem: • • • • • • •

A falta de compromisso do negócio para o Gerenciamento da Capacidade processo A falta de informação adequada do negócio sobre os planos e estratégias futuras A falta de compromisso da alta istração ou a falta de recursos e / ou orçamento para o processo de Gerenciamento da Capacidade SCM e CCM realizado em isolamento porque BCM é difícil, ou há uma falta de informação de negócio adequadas e precisas Os processos se tornam demasiado burocrático ou manualmente intensivo Os processos se concentrar demais na tecnologia (CCM) e não o suficiente sobre os serviços (SCM) e de negócios (BCM) Os relatórios e informações fornecidas são muito volumosos ou muito técnico e não dão as informações necessárias ou apropriadas para o clientes e os negócios.

ITIL V3 - Service Design - Página:

176 de 477

4.4 Gerenciamento de Disponibilidade 4.4.1 Finalidade objetivo / / objetivo O objetivo da Gerenciamento de Disponibilidade processo é o de assegurar que o nível de serviço disponibilidade entregues em todos os serviços é correspondente a ou excede as necessidades atuais e futuras acordadas do negócio, de uma maneira custo-efetiva. O objetivo do Gerenciamento da Disponibilidade é fornecer um ponto de foco e de gestão para todas as questões relacionadas com a disponibilidade, relativo a ambos os serviços e recursos, garantindo que as metas de disponibilidade em todas as áreas são medidos e alcançados. O objetivos de Gerenciamento de Disponibilidade são: • • •

• • •

Produzir e manter uma adequada e up-to-date Plano de disponibilidade que reflete as necessidades atuais e futuras do negócio Prestar assessoria e orientação para todas as outras áreas de negócio e de TI em todas as questões relacionadas com a disponibilidade Garantir que o serviço disponibilidade realizações atender ou exceder todas as suas metas acordadas, por serviços de gestão e recursos relacionada com a disponibilidade atuação Auxiliar no diagnóstico e resolução de disponibilidade e incidentes relacionados problemas Avaliar a impacto de todos mudars sobre o Plano de disponibilidade e desempenho e capacidade de todos serviços e os recursos Assegurar que as medidas pró-ativas para melhorar a disponibilidade de serviços são implementados onde quer que seja de custo justificável para fazê-lo.

Gerenciamento de Disponibilidade deve garantir o nível acordado de disponibilidade é fornecida. A medição e monitoramento de TI a disponibilidade é uma chave atividade para assegurar os níveis de disponibilidade estão sendo atendidas de forma consistente. Gerenciamento de Disponibilidade deve procurar continuamente otimizar e proativa melhorar a disponibilidade do Infraestrutura de TI, Dos serviços e do sustentadas organização, A fim de proporcionar melhorias econômicas de disponibilidade que pode trazer benefícios de negócios e de clientes.

4.4.2 Âmbito O escopo do Gerenciamento de Disponibilidade processo abrange o projeto, Implementação, avaliação, gestão e melhoria de De serviços de TI e componente disponibilidade. Gerenciamento de Disponibilidade precisa entender

ITIL V3 - Service Design - Página:

177 de 477

o serviço e requisitos de disponibilidade de componentes a partir do perspectiva de negócios em termos de: • • • • •

Atual processo de negócioes, o operação e requisitos Futuros planos de negócio e requisitos Metas de serviço e da corrente de TI Operação de Serviço e entrega Infraestrutura de TI, dados, aplicaçãos e ambiente e o seu desempenho Impactos nos negócios e prioridades em relação aos serviços e seu uso.

Entender tudo isso vai permitir gerenciamento de disponibilidade para garantir que todos os serviços e componentes são projetados e entregues a cumprir as suas metas em termos de necessidades de negócio acordados. O processo de Gerenciamento de Disponibilidade: •

•

•

•

Deve ser aplicada a todos os operacional serviços e tecnologia, nomeadamente as referidas no SLAs. Também pode ser aplicada a estes serviços de TI considerados essenciais de negócios, independentemente de existir SLAs formais Deve ser aplicado a todos os serviços de TI para serviços novos e existentes, onde Nível Requisitos de Serviço (SLRs) ou Contratos de Nível de Serviço (SLAs) foram estabelecidas Deve ser aplicada a todos os serviços de apoios e os parceiros e fornecedors (internos e externos) que formam a organização de e de TI como um precursor para a criação de acordos formais Considera todos os aspectos dos serviços de TI e componentes e organizações de apoio que podem impactar disponibilidade, Incluindo a formação, as habilidades de processo, eficácia,procedimentos e ferramentas.

O processo de gerenciamento de disponibilidade não inclui Gestão de Continuidade de Negócios ea retomada dos negócios após o processamento de um grande desastre. O e de BCM está incluído dentro da TI Gestão da Continuidade do Serviço (ITSCM). No entanto, Gerenciamento de Disponibilidade fornece insumos essenciais para ITSCM, e os dois processos têm fim relação, Em particular no avaliação e gestão dos riscos e na implementação de redução de riscos e resiliência medidas. O processo de gerenciamento de disponibilidade deve incluir: •

• •

Monitoramento de todos os aspectos de disponibilidade, confiança e manutenção de TI serviços e o apoio componentes, com eventos apropriados, alarmes e escalada, Com scripts automatizados para recuperação Manutenção de um conjunto de métodos, técnicas e cálculos para todas as medições de disponibilidade, métricos e relatórios Assistência com avaliação de risco e atividades de gerenciamento

ITIL V3 - Service Design - Página:

178 de 477

• • • •

• • •

Coleta de medições, análise e produção de relatórios regulares e ad hoc sobre o serviço e componente disponibilidade Entender as demandas acordadas atuais e futuras da negócio de serviços de TI e sua disponibilidade Influenciar o design de serviços e componentes para alinhar com as necessidades do negócio Produzir um Plano de disponibilidade que permite que o provedor de serviços continuar a fornecer e melhorar os serviços de acordo com metas de disponibilidade definidos no Acordo de Nível de Serviços (SLAs), e para planejar e prever os níveis de disponibilidade exigidos futuras, conforme definido no Exigência de Nível de Serviços (SLRs) Manter uma agenda de testes para todos os resistentes e fail-over componentes e mecanismos Assistência com a identificação e resolução de quaisquer incidentes e problemas associados com o serviço ou indisponibilidade componente Melhoria proativa de serviço ou disponibilidade de componentes onde quer que seja justificável custo e atende às necessidades do negócio.

4.4.3 Valor para o negócio O Gerenciamento de Disponibilidade processo garante que a disponibilidade de sistemas e serviços corresponde às crescentes necessidades acordadas do negócio. O papel de TI dentro da empresa agora é fundamental. O disponibilidade e confiabilidade de De serviços de TIs pode influenciar diretamente a satisfação do cliente ea reputação do negócio. É por isso que de gerenciamento de disponibilidade é essencial para garantir a TI entrega os níveis adequados de disponibilidade de serviço exigidos pela empresa para satisfazer a sua objetivo de negócios e entregar o qualidade de serviço exigido por sua clientes. No mercado competitivo de hoje, a satisfação do cliente com o serviço (s), desde é primordial. A lealdade do cliente não pode ser invocado, e insatisfação com a disponibilidade e confiança de serviço de TI pode ser um fator chave na clientes que tomam o seu negócio para um concorrente. O processo de gerenciamento de disponibilidade e planejamento, Assim como Gerenciamento da Capacidade, Deve estar envolvido em todas as fases do ciclo de vida de serviço, a partir de Estratégia e Design, através de Transição e Operação de Melhoria. A disponibilidade adequada e resiliência deve ser projetado em serviços e componentes, desde as fases iniciais do projeto. Isso irá garantir não só que a disponibilidade de qualquer serviço novo ou alterado cumpra suas metas esperados, mas também que todos os serviços e componentes existentes continuam a cumprir todas as suas metas. Esta é a base da estabilidade serviço próvisão.

ITIL V3 - Service Design - Página:

179 de 477

4.4.4 Políticas / princípios / conceitos básicos O Gerenciamento de Disponibilidade processo está continuamente tentando garantir que todos os serviços operacionais cumprir as suas metas de disponibilidade acordados, e que os serviços novos ou alterados são concebidos de modo a cumprir os seus objectivos pretendidos, sem comprometer a atuação dos serviços existentes. A fim de conseguir isso, gerenciamento de disponibilidade deve executar as atividades reativas e proativas ilustrados na figura 4.13.

Figura 4.13 O processo de Gerenciamento de Disponibilidade

As actividades reactivos de Gerenciamento de Disponibilidade consistir de monitoramento, Medir, analisar, relatar e analisar todos os aspectos do componente e disponibilidade do serviço. Isto é para assegurar que todos os alvos de serviço acordados são medidos e alcançados. Onde quer que desvios ou violações são detectados, são investigadas e as medidas correctivas instigado. A maioria destas atividades são conduzidas no estágio de Operações

ITIL V3 - Service Design - Página:

180 de 477

do ciclo de vida e estão ligados ao monitoramento e controlar atividades de eventos e Gerenciamento de Incidentes processos. (Veja o Operação de Serviço publicação.) As atividades preventivas consistem em produzir recomendações, planos e documentos sobre o projeto diretrizs e os critérios para serviços novos e modificados, bem como a melhoria contínua do serviço e redução de risco nos serviços existentes onde quer que pode ser custo-justificado. Estes são os principais aspectos a serem considerados dentro Design de Serviços actividades. Um processo eficaz de gerenciamento de disponibilidade, que consiste tanto as atividades reativas e proativas, pode "fazer uma grande diferença 'e será reconhecido como tal pelo negócio, Se a desenvolvimento de gerenciamento de disponibilidade de TI dentro de uma organização tem uma forte ênfase nas necessidades da empresa e clientes. Para reforçar essa ênfase, existem vários princípios orientadores que devem sustentar o processo de gerenciamento de disponibilidade e seu foco: •

•

• •

•

•

A disponibilidade do serviço está no centro de satisfação do cliente eo sucesso do negócio: há uma correlação direta na maioria das organizações entre o serviço disponibilidade eo cliente e usuário satisfação, onde o desempenho serviço de má qualidade é definida como sendo indisponíveis. Reconhecendo que, quando os serviços não conseguem, ainda é possível alcançar clientes de negócios, ea satisfação e reconhecimento: a forma como um provedor de serviços reage de falha situação tem uma grande influência no cliente e usuário percepção e expectativa. Melhorar a disponibilidade só pode começar após a compreensão de como o De serviços de TIs apoiar o operação do negócio. Disponibilidade do serviço é tão bom quanto o elo mais fraco da cadeia: ela pode ser aumentada pela eliminação de pontos únicos de falha (SPoFs) ou um pouco confiáveis ou fraco componente. Disponibilidade não é apenas um processo reativo. O mais pró-ativa do processo, A disponibilidade serviço melhor será. Disponibilidade não deve reagir puramente para serviço e falha de componentes. Os mais eventos e falhas estão previstas, antecipou-se e impediu, quanto maior o nível de disponibilidade do serviço. É mais barato para projetar o nível certo de disponibilidade do serviço em um serviço desde o início, em vez de tentar "parafuso-lo em 'posteriormente. Adicionando resiliência para um serviço ou componente é invariavelmente mais caro do que projetando-o de desde o início. Além disso, uma vez que um serviço tem um nome ruim para insegurança, torna-se muito difícil mudar a imagem. Resiliência é também um elemento-chave do GCSTI, e isso deve ser considerado ao mesmo tempo.

ITIL V3 - Service Design - Página:

181 de 477

O escopo de Gerenciamento de Disponibilidade abrange o projeto, Medição, implementação e gerenciamento de serviço de TI e disponibilidade de infraestrutura. Isto reflecte-se na descrição do processo mostrado na Figura 4.13 e descrito nos parágrafos seguintes. O processo de Gerenciamento de Disponibilidade tem dois elementos-chave: •

•

Atividades reativas: O aspecto reativo de Gerenciamento de Disponibilidade envolve o monitoramento, medição, análise e gestão de todos os eventos, incidentes e problemas envolvendo indisponibilidade. Essas atividades são, principalmente, envolvidos na operacional papéis. Atividades proativas: As atividades pró-ativas de gerenciamento de disponibilidade envolvem a dinâmica de planejamento, design e melhoria da disponibilidade. Essas atividades são, principalmente, envolvidos em papéis de design e planejamento.

Gerenciamento de disponibilidade é concluído em dois níveis inter-relacionados: •

•

Disponibilidade do serviço: Envolve todos os aspectos da disponibilidade do serviço e indisponibilidade e os impacto de componente disponibilidade ou o potencial impacto da indisponibilidade componente da disponibilidade do serviço Disponibilidade dos componentes: Envolve todos os aspectos de disponibilidade de componentes e indisponibilidade.

Gerenciamento de Disponibilidade baseia-se na monitoramento, Medição, análise e elaboração de relatórios dos seguintes aspectos: Disponibilidade: A capacidade de um serviço de componente ou de CI para desempenhar a sua concordou função quando necessário. Muitas vezes, é medido e relatado como um percentual: (Tempo de serviço acordado (AST) - downtime) Disponibilidade (%) = --------------------------------------------- ---------- X 100% Tempo de serviço acordado (AST) Nota: O tempo de inatividade só devem ser incluídos no cálculo acima, quando ocorre no interior da Tempo de serviço acordado (AST). No entanto, o tempo de inatividade total deve também ser registrados e relatados. Confiança: Uma medida de quanto tempo uma serviço, Componente ou CI pode desempenhar sua função acordada sem interrupção. O confiança do serviço pode ser melhorada através do aumento da fiabilidade de componentes individuais ou pelo aumento da resiliência do serviço a falha de um componente

ITIL V3 - Service Design - Página:

182 de 477

individual (ou seja, o aumento do componente redundância, E.g. usando técnicas de balanceamento de carga). Muitas vezes, é medido e relatado como Tempo médio entre Incidentes de Serviço (TMEIS) ou Tempo médio entre falhas (MTBF): Tempo disponível em horas Confiabilidade (TMEIS em horas) = ------------------------------------------- -------Número de quebras Tempo disponível em horas - o tempo de inatividade total em horas Confiabilidade (MTBF em horas) = ------------------------------------------- -------------------------Número de quebras Manutenibilidade: Uma medida de quão rapidamente e efetivamente um serviço de componente, ou CI pode ser restaurard ao normal de trabalho depois de um falha. Ela é medida e relatada como Tempo médio para restaurar o serviço (MTR) e deve ser calculado através da seguinte fórmula: Paralisação total em horas Manutenibilidade (MTRS em horas) = --------------------------------------Número de quebras de serviço MTRS deve ser usado para evitar a ambiguidade do termo da indústria mais comum Mean Time To Repair (MTTR), que em algumas definições inclui somente reparar tempo, 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: • • • • •

Tempo para gravar Tempo para responder Tempo para resolver Tempo para reparar ou substituir fisicamente Tempo para recuperar.

Exemplo: Uma situação em que um 24 x 7 de serviço foi executado por um período de 5.020 horas, com apenas dois intervalos, um de seis horas e uma de 14 horas, daria os seguintes números: Disponibilidade = (5.020 - (6 +14)) / 5020 x 100 = 99,60%

ITIL V3 - Service Design - Página:

183 de 477

Confiabilidade (TMEIS) = 5.020 / 2 = 2.510 horas Confiabilidade (MTBF) = 5020 - (6 +14) / 2 = 2.500 horas Manutenibilidade (MTR) = (6 +14) / 2 = 10 horas Manutenção: A capacidade de um terceiro fornecedor para atender os termos de sua contrato. Muitas vezes, esse contrato vai incluir os níveis acordados de disponibilidade, Confiabilidade e / ou manutenção para uma serviços de apoio ou componente. Estes aspectos e suas inter-relações são ilustrados na figura 4.14.

Figura 4,14 termos de disponibilidade e medições

Embora o alvo principal de serviço contido dentro de SLAs para o clientes e de negócios, é a disponibilidade, como ilustrado na Figura 4.14, alguns clientes exigem também alvos fiabilidade e facilidade de manutenção a serem incluídos. Onde estes estão incluídos devem se relacionar com a confiabilidade do serviço e metas de manutenção, enquanto que as metas de confiabilidade e facilidade de manutenção constantes OLAs e contratos relacionados com componente e serviços de apoio metas e muitas vezes pode incluir metas disponibilidade relativas aos componentes relevantes ou serviços de apoio.

ITIL V3 - Service Design - Página:

184 de 477

O termo Função de Negócios Vital (VBF) é usada para refletir os elementos críticos de negócio do processo de negócio ados por um De serviços de TI. Um serviço de TI pode ar um número de funções de negócios que são menos críticos. Por exemplo, um caixa automático (ATM) ou em dinheiro VBF serviço dispensador seria a distribuição do dinheiro. No entanto, a capacidade de obter uma indicação de um ATM não pode ser considerada como essencial. Esta distinção é importante e deve influenciar o desenho disponibilidade e associados custars. A mais vital do negócio função em geral, quanto maior o nível de resiliência e disponibilidade que tem de ser incorporada no projeto necessária nos serviços de e de TI. Para todos os serviços, quer VBFs ou não, os requisitos de disponibilidade deverá ser determinada pela negócio e não pela TI. As metas de disponibilidade iniciais são muitas vezes fixados em um nível muito alto, e isso leva a tanto sobre preço de serviços ou iterativo discussão entre o provedor de serviços eo negócio de concordar um equilíbrio adequado entre a disponibilidade do serviço e os custos do serviço e sua tecnologia de apoio. VBFs certos pode precisar de projetos especiais, que estão agora a ser utilizados como uma questão de curso dentro Design de Serviços planos, que inclui: •

•

•

•

Alta disponibilidade: A característica do serviço de TI que minimiza ou máscaras de falha os efeitos do componente de TI para o usuários de um serviço. A tolerância a falhas: A capacidade de um serviço de TI, componente CI ou para continuar a operar correctamente depois falha de uma parte do componente. A operação contínua: Uma abordagem ou projeto para eliminar tempo de inatividade planejado de um serviço de TI. Observe que os componentes individuais ou cis pode ser para baixo, mesmo que o serviço de TI permanece disponível. Disponibilidade contínua: Uma abordagem ou desenho para atingir 100% de disponibilidade. Um continuamente disponível De serviços de TI não tem tempo de inatividade planejado ou não.

Muitos fornecedors comprometer com alta disponibilidade ou soluções de disponibilidade contínua somente se rigorosos padrões ambientais e resistente processoes são usados. Eles muitas vezes concordam em tais contratos somente após um levantamento do local foi concluída e adicionais, às vezes caros, melhorias foram feitas. Gerenciamento de Disponibilidade começa assim que os requisitos de disponibilidade de um serviço de TI são claras o suficiente para ser articulada. É um processo contínuo, terminando somente quando o serviço de TI é desclassificada ou aposentado. As principais atividades do processo de Gerenciamento de Disponibilidade são:

ITIL V3 - Service Design - Página:

185 de 477

•

• •

•

•

• • • •

Determinar os requisitos de disponibilidade do negócio por um novo ou aprimorado de serviços de TI e de formular a disponibilidade e recuperação critérios de projeto para os componentes de e de TI Determinar as VBFs, em conjunto com o negócio e ITSCM Determinando o impacto resultante de serviço de TI e falha do componente em conjunto com ITSCM e, se for caso disso, a revisão dos critérios de concepção de disponibilidade para fornecer adicionais resiliência para evitar ou minimizar o impacto para a negócio Definir os objectivos para disponibilidade, Confiabilidade e manutenção para o Infra-estrutura de TI componentes que sustentam o serviço de TI para permitir que estas sejam documentadas e acordadas no âmbito SLAs, e OLAs contratos Estabelecimento de medidas e relatórios de disponibilidade, confiança ea facilidade de manutenção que refletem o negócio, usuário e e de TI organização perspectivas Monitoramento e análise de tendências dos componentes de confiabilidade, disponibilidade e capacidade de manutenção de TI Revisão de serviços de TI e disponibilidade de componentes e identificar os níveis inaceitáveis Investigar as razões subjacentes para inaceitável disponibilidade Produção e manutenção de um Plano de disponibilidade que prioriza e planeja melhorias a disponibilidade de TI.

4.4.5 as atividades de processo, métodos e técnicas O Gerenciamento de Disponibilidade processo depende fortemente da medição de serviço e as realizações de componentes que respeita à disponibilidade. "Se você não medir, você não pode controlá-lo ' "Se você não medir, você não pode melhorá-lo ' "Se você não medir, você provavelmente não se importa ' "Se você não pode influenciar ou controlar, então não medir ' 'O que medir e como denunciá-lo "inevitavelmente depende de qual atividade está a ser apoiada, que os destinatários são e como a informação é para ser utilizado. É importante reconhecer as diferentes perspectivas de disponibilidade para assegurar satisfaz medição e elaboração de relatórios a essas necessidades variadas: •

O perspectiva de negócios considera De serviços de TI disponibilidade em termos de sua contribuição ou impacto sobre os VBFs que impulsionam o negócio operação.

ITIL V3 - Service Design - Página:

186 de 477

•

•

A perspectiva do usuário considera a disponibilidade do serviço como uma combinação de três fatores, ou seja, a frequência, a duração ea escopo de impacto, ou seja, todos os usuários, alguns usuários, todas as funções de negócios ou determinadas funções empresariais - o usuário considera também a disponibilidade do serviço em termos de tempo de respostas. Para muitos de desempenho centrada aplicaçãos, os tempos de resposta pobres são considerados iguais em termos de impacto para falhas da tecnologia. O Provedor de serviços de TI perspectiva considera o serviço de TI e disponibilidade de componentes em relação ao disponibilidade, Confiabilidade e facilidade de manutenção.

A fim de satisfazer as diferentes perspectivas de disponibilidade, gerenciamento de disponibilidade deve considerar o espectro de medidas necessárias para informar o nível de "mesmo" de disponibilidade de formas diferentes. Medidas precisam ser significativa e agregar valor se a medição de disponibilidade e de informação são, em última análise para entregar benefícios para a TI e as organizações empresariais. Esta é fortemente influenciada pela combinação de "o que você medir" e "como você relatar isso". 4.4.5.1 As atividades reativas de gerenciamento de disponibilidade

Monitorar, medir, analisar e relatar serviço e componente disponibilidade A saída a partir da chave Gerenciamento de Disponibilidade processo é a medição e comunicação de TI a disponibilidade. Disponibilidade medidas devem ser incorporadas SLA, OLA e qualquer subjacente contratos. Estes devem ser revistos regularmente em Nível de Serviço rever reuniões. Medição e comunicação proporcionam a base para: • • • • •

Monitorando o real disponibilidade alvos entregues contra concordaram Estabelecer medidas de disponibilidade e concordar metas de disponibilidade com o negócio Identificar os níveis inaceitáveis de disponibilidade que o impacto negócio e os usuários Revendo disponibilidade com o e de TI organização Atividades de melhoria contínua para otimizar disponibilidade.

As organizações prestadoras de serviços de TI que, por muitos anos, medida e informou sobre sua perspectiva de disponibilidade. Tradicionalmente, essas medidas têm se concentrado na disponibilidade de componentes e têm sido um pouco divorciada do negócio e usuário pontos de vista. Tipicamente, estas medidas tradicionais baseiam-se numa combinação de uma percentagem disponibilidade (%), perda de tempo e a frequência de falha. Alguns exemplos destas medidas tradicionais são os seguintes:

ITIL V3 - Service Design - Página:

187 de 477

•

•

•

•

•

Por cento disponível - A verdadeira medida de "tradicional", que representa disponibilidade como uma percentagem e, como tal, muito mais útil como uma medida de disponibilidade dos componentes do que uma medida de disponibilidade do serviço. Ele é geralmente usado para rastrear e relatar conquista contra um alvo de nível de serviço. Isso tende a valorizar o 'número grande "de tal forma que, se o meta de nível de serviço foi de 98,5% e para a realização foi de 98,3%, então não parece tão ruim. Isso pode estimular um comportamento complacente da organização de e de TI. Por cento indisponível - O inverso do acima. Essa representação, no entanto, tem a vantagem de se concentrar em não-disponibilidade. Baseado no exemplo acima, se o alvo para a não-disponibilidade é de 1,5% e para a realização foi de 1,7%, em seguida, esta é uma diferença muito maior relativo. Esse método de comunicação é mais provável que criar a consciência da diferença na entrega do nível de disponibilidade exigido. Duração - Obtido através da conversão a percentagem disponível em horas e minutos. Isso fornece uma medida mais "humano" que as pessoas possam se relacionar. Se o semanal tempo de inatividade meta é de duas horas, mas uma semana o tempo de inatividade real foi de quatro horas, o que representaria uma tendência que leva a um adicional de quatro dias de não-disponibilidade para a empresa durante um ano inteiro. Este tipo de medida e relatórios é mais susceptível de encorajar foco na melhoria dos serviços. Freqüência de falha - Utilizado para registrar o número de interrupções no serviço de TI. Ela ajuda a fornecer uma boa indicação de confiança a partir de um usuário perspectiva. É melhor usado em combinação com a "duração" para ter uma visão equilibrada do nível de interrupção do serviço e da duração do tempo perdido para o negócio. Impacto de falha - Esta é a verdadeira medida de indisponibilidade do serviço. Ela depende maduro incidente gravação onde a incapacidade de usuários para realizar tarefas de seus negócios é a mais importante peça de informação capturada. Todas as outras medidas sofrem de um potencial para mascarar os efeitos reais de falha de serviço e muitas vezes são convertidos em um impacto financeiro.

O negócio pode ter, por muitos anos, aceitou que a disponibilidade de TI que a experiência é representada em termos de disponibilidade de componentes e não global serviço ou de negócios disponibilidade. No entanto, isso não é mais visto como aceitável eo negócio está ansiosa para melhor representar a disponibilidade de medida (s) que mostram as conseqüências positivas e negativas de a disponibilidade de TI em seus negócios e usuários. As medições de disponibilidade mais importantes são aqueles que refletem e medir a disponibilidade do negócio e usuário perspectiva.

ITIL V3 - Service Design - Página:

188 de 477

Gerenciamento de Disponibilidade preciso considerar a disponibilidade de ambos um negócio / TI provedor de serviços perspectiva e do ponto de vista de componentes de TI. Estes são aspectos totalmente diferentes, e enquanto o conceito subjacente é semelhante, na medida, foco e impacto são inteiramente diferentes. O único propósito de produzir essas medidas disponibilidade e relatórios, incluindo os da perspectiva de negócios, É o de melhorar o qualidade e disponibilidade dos serviços de TI fornecidos para a empresa e os usuários. Todas as medidas, relatórios e as atividades devem refletir esta finalidade. Disponibilidade, quando medido e indicado para refletir a experiência do usuário, Fornece uma visão mais representativa em geral De serviços de TI qualidade. O usuário ver de disponibilidade é influenciada por três fatores: • • •

Freqüência de tempo de inatividade Duração do tempo de inatividade Escopo de impacto.

Medições e relatórios de disponibilidade usuário deve, pois, contemplar esses fatores. A metodologia empregada para refletir a disponibilidade do usuário poderia considerar duas abordagens: •

•

Impacto por minuto usuário perdido: Esta é a base de cálculos sobre a duração do tempo de inactividade, multiplicado pelo número de utilizadores afectados. Esta pode ser a base para reportar a disponibilidade quanto a produtividade dos utilizadores perdida, ou para calcular a percentagem de disponibilidade do ponto de vista do utilizador, e pode também incluir o custars de recuperação por perda de produtividade (por exemplo, pagamento de horas extras aumentou). Impacto de negócios transação: Esta é a base de cálculo do número de transações comerciais que não pôde ser processado durante o período de inatividade. Isto proporciona uma melhor indicação do impacto comercial reflectindo diferentes perfis de processamento de transacção através da hora do dia, etc semana, em muitos casos, pode ser o caso de que o usuário impacto correlaciona com uma VBF, e.g. se o usuário recebe ordens de compra dos clientes e um VBF é de vendas dos clientes. Esta medida simples é a base para refletir o impacto para o negócio operação e do usuário.

O método utilizado deve ser influenciada pela natureza da operação de negócio. A operação de negócio de e de dados de atividade entrada é bem adequado ao relatório que reflete usuário perda de produtividade. Operações comerciais que são mais voltados para o cliente, por exemplo, Serviços ATM, beneficiar de relatórios transação impacto. Também deve ser notado que não impacto todos os negócios é de uso relacionado. Com crescente automação e

ITIL V3 - Service Design - Página:

189 de 477

processamento eletrônico, a capacidade de processar transações automatizadas ou atender o mercado de corte vezes também pode ter um grande impacto financeiro que pode ser maior do que a capacidade dos usuários para o trabalho. O e de TI organização precisa ter um conhecimento apurado da experiência do usuário de disponibilidade. No entanto, os benefícios reais vêm de agregar a visão do usuário para a visualização geral dos negócios. Um princípio orientador da Gerenciamento de Disponibilidade processo é que "Melhorar a disponibilidade só pode começar quando a tecnologia forma a o negócio é compreendido". Portanto gerenciamento de disponibilidade não é apenas sobre a compreensão da disponibilidade de cada TI componente, Mas é tudo sobre a compreensão do impacto da falha de um componente no serviço e disponibilidade do usuário. Do ponto de vista comercial, um serviço de TI só pode ser considerado disponível quando o negócio é capaz de realizar todas função de negócios vitals necessário para conduzir a operação do negócio. Para o serviço de TI para estar disponível, por isso, depende de todos os componentes em que a serviço depende sendo disponíveis, ou seja, sistemas, componentes principais, rede de dados e aplicaçãos. A abordagem tradicional de TI seria medir individualmente a disponibilidade de cada um desses componentes. No entanto, a verdadeira medida da disponibilidade tem de basear-se os impactos positivos e negativos sobre os VBFs em que a operação do negócio depende. Esta abordagem assegura que os SLAs de TI e comunicação disponibilidade são baseados em medidas que são entendidos por ambas as empresas e de TI. Ao medir os VBFs que dependem de serviços de TI, medição e elaboração de relatórios torna-se orientado a negócios, com o impacto da falha refletindo as conseqüências para o negócio. Também é importante que a disponibilidade dos serviços é definido e acordado com o negócio e refletida dentro de SLAs. Esta definição de disponibilidade deve incluir: • • • • •

Qual é o nível mínimo de funcionalidade disponível do serviço? Em que nível de resposta do serviço é o serviço considerado indisponível? Onde é que este nível de funcionalidade e de resposta ser medido? Quais são os pesos relativos de indisponibilidade parcial do serviço? Se um local ou escritório é afetado, é considerado todo o serviço indisponível ou é esta considerada "indisponibilidade parcial"? Isso precisa ser acordado com o clientes.

Ferramentas de relatórios e análise são necessários para a manipulação de dados armazenados em diversas bases de dados utilizadas pelo Gerenciamento de Disponibilidade. Essas ferramentas podem ser tanto de plataforma ou baseado em PC e são muitas vezes uma combinação dos dois. Isto vai ser influenciada pelas tecnologias de banco de dados de repositório seleccionados e

ITIL V3 - Service Design - Página:

190 de 477

da complexidade do processamento de dados e relatório necessário. Gerenciamento de Disponibilidade, uma vez implementado e implantado, serão necessários para produzir relatórios regulares sobre uma base de acordo, por exemplo, relatórios mensais de disponibilidade, Plano de disponibilidade,Análise de falha de serviço Relatórios (SFA) de status, etc As atividades envolvidas nessas atividades de relatórios podem exigir esforço manual muito ea única solução é automatizar o máximo de geração de relatório atividade quanto possível. Para efeitos de relatórios, padrões de relatórios organizacionais devem ser utilizados sempre que possível. Se estes não existirem, as normas devem ser desenvolvidos de modo que os relatórios podem ser desenvolvidos usando as ferramentas padrão e técnicas. Isto significa que a integração e consolidação de relatórios posteriormente será muito mais fácil de conseguir. Análise de indisponibilidade Todos os eventos e incidentes que causam indisponibilidade de serviços e componentes devem ser investigadas, com ações corretivas a ser aplicado dentro ou a disponibilidade Plano ou o SIP geral. Tendências devem ser produzidos a partir dessa análise para dirigir e concentrar atividades como Análise de Falhas de Serviço (AGS) para as áreas causando mais impacto ou interrupção dos negócios e da usuários. Os custos globais de um De serviços de TI são influenciadas pelos níveis de disponibilidade necessário e os investimentos necessários em tecnologia e serviços prestados pela organização de e de TI para atender a essa exigência. Disponibilidade certamente não vem de graça. No entanto, é importante indicar que a indisponibilidade de TI também tem um custo, portanto, não é livre indisponibilidade ou. Para o negócio altamente crítica processoes e VBFs, é preciso considerar não apenas o custo da prestação do serviço, mas também os custos que são ados a partir de falha. O equilíbrio óptimo para golpear é o custo da solução disponibilidade comparadas com os custos de indisponibilidade. Antes de qualquer SLR é aceito, e, finalmente, o SLR ou SLA é negociado e acordado entre o negócio ea organização de TI, é essencial que os requisitos de disponibilidade do negócio são analisados para avaliar se / como o serviço de TI pode entregar os níveis requeridos de disponibilidade. Isto aplica-se não só a novos serviços de TI que estão a ser introduzidas, mas também a qualquer pedido mudars para os requisitos de disponibilidade dos actuais serviços de TI. O custar de uma falha que poderia simplesmente ser expresso como o número de negócios ou TI transaçãos impactados, quer como um número real (derivado de instrumentação) ou com base em um estimativa. Quando medido contra os VBFs que am o negócio operação, O que pode proporcionar uma indicação óbvia de a consequência da falha. A vantagem dessa abordagem é a relativa facilidade de obtenção dos dados de impacto e da falta de quaisquer

ITIL V3 - Service Design - Página:

191 de 477

cálculos complexos. Torna-se também um "valor" que é compreendido por ambas as empresas e organização de TI. Isso pode ser o estímulo para a identificação de oportunidades de melhoria e pode se tornar uma chave métrico no controlo da disponibilidade dos serviços de TI. A principal desvantagem desta abordagem é que ela não oferece óbvio valor monetário que seria necessário para justificar quaisquer decisões de investimento financeiros significativos para melhorar a disponibilidade. Onde importantes decisões de investimento financeiro são necessários, é melhor para expressar o custo do fracasso decorrente de serviço, A aplicação do sistema, ou função perda para o negócio como um "valor" monetário. O valor monetário pode ser calculada como uma combinação dos custos associados ao insucesso tangíveis, mas também pode incluir uma série de custos intangíveis. O valor monetário também deve refletir o impacto do custo para o conjunto organização, Ou seja, o negócio ea organização de TI. Custos tangíveis podem incluir: • • • • • •

Perdido usuário produtividade Perdeu a produtividade da equipe Perda de receita Pagamento de horas extraordinárias Bens e materiais desperdiçados Impôs multas e sanções pecuniárias.

Estes custars são muitas vezes bem compreendida pela área financeira do negócio e de TI, organização e em termos relativos são mais fáceis de obter e agregado do que os custos intangíveis associados com TI falha. Custos intangíveis podem incluir: • • • • • •

Perda de clientes Perda da boa vontade do cliente (insatisfação do cliente) Perda de oportunidade de negócio (vender, conquistar novos clientes ou de receita, etc) Danos à reputação do negócio Perda de confiança no Provedor de serviços de TI Danificar a moral do pessoal.

É importante não apenas para descartar o intangível custars (e as possíveis consequências), alegando que eles podem ser difíceis de medir. A indisponibilidade geral do serviço, o custo total tangível e os custos intangíveis totais decorrentes indisponibilidade do serviço são todas as métricas-chave na medição da eficácia do Gerenciamento de Disponibilidade processo.

ITIL V3 - Service Design - Página:

192 de 477

O ciclo de vida do incidente expandida Um princípio norteador de gerenciamento de disponibilidade é reconhecer que ainda é possível ganhar a satisfação do cliente, mesmo quando as coisas dão errado. Uma abordagem para ajudar a atingir este requer disponibilidade de Gestão para garantir que a duração de uma eventual incidente é minimizada para permitir normais operações comerciais para retomar o mais rapidamente possível. Um objectivo de gerenciamento de disponibilidade é garantir a duração e impacto de incidentes impactando De serviços de TIs são minimizadas, para permitir que as operações comerciais de retomar o mais rapidamente possível. A análise da 'ciclo de vida do incidente expandida'Permite que o serviço de TI total de tempo de inatividade por qualquer incidente dado ser discriminados e mapeados contra as grandes etapas através das quais todos os progressos incidentes (o ciclo de vida). Gerenciamento de Disponibilidade deve trabalhar em estreita colaboração com Gerenciamento de Incidentes e Gerenciamento de Problemas Na análise de todos os incidentes que causam indisponibilidade. Uma boa técnica para ajudar com a análise técnica dos incidentes que afectam a disponibilidade de componentes serviços e de TI é ter visão 'ciclo de vida' de um incidente. Cada incidente a por várias fases principais. O tempo decorrido nestas fases pode variar consideravelmente. Para fins de gerenciamento de disponibilidade, "ciclo de vida" do incidente padrão, como descrito em Gerenciamento de Incidentes, foi ampliado para fornecer ajuda e orientação especificamente na área de "projetar para recuperação'. Figura 4.15 ilustra o ciclo de vida do incidente expandido.

Figura 4.15 O ciclo de vida do incidente expandida

ITIL V3 - Service Design - Página:

193 de 477

A partir do acima, pode ser visto que uma incidente pode ser dividida em fases individuais dentro de um ciclo de vida que pode ser cronometrado e medido. Este ponto de vista do ciclo de vida oferece uma estrutura importante para determinar, entre outros, requisitos de sistemas de gestão para evento e incidente detecção, Captura de dados de diagnóstico requisitos e ferramentas para diagnóstico, Planos de recuperação para ajudar na recuperação rápida e como verificar se o serviço de TI foi restaurado. As fases individuais do ciclo de vida são consideradas com mais pormenor como se segue. •

•

•

Detecção de incidentes: O momento em que o IT provedor de serviços organização está ciente de um incidente. Ferramentas de gerenciamento de sistemas de influenciar positivamente a capacidade de detectar eventos e incidentes e, portanto, para melhorar os níveis de disponibilidade que podem ser entregues. Implementação e exploração deve ter um forte foco em atingir alta disponibilidade e reforçada recuperação objetivos. No contexto da recuperação, essas ferramentas devem ser exploradas para proporcionar a detecção automática de falhas, auxiliar no diagnóstico de falhas e e automatizado erro recuperação, com respostas script. Ferramentas são muito importantes na redução de todas as etapas do ciclo de vida do incidente, mas, principalmente, a detecção de eventos e incidentes. Idealmente, o evento é automaticamente detectado e resolvido, antes da usuários ter notado ou foram impactadas de forma alguma. Diagnóstico incidente: O tempo em que o diagnóstico para determinar a causa subjacente tenha sido concluída. Quando a TI componentes falhar, é importante que o nível requerido de diagnóstico é capturada, para permitir a determinação do problema para identificar o causa raiz e resolver o problema. A utilização e capacidade de ferramentas de diagnóstico e habilidades é fundamental para a rápida resolução de questões de serviço. Por certo falhas, a captura de diagnóstico pode estender o tempo de inatividade do serviço. No entanto, a captura não dos diagnósticos apropriados cria e expõe o serviço de repetir falhas. Onde o tempo requerido para levar o diagnóstico é considerado excessivo, ou que varia desde o alvo, um rever deve ser iniciada para identificar se as técnicas e / ou procedimentos pode ser simplificada para reduzir o tempo necessário. Igualmente o escopo dos dados de diagnóstico disponível para a captura pode ser avaliada para assegurar que apenas os dados de diagnóstico consideradas essenciais é tomado. O tempo de inatividade adicional necessária para capturar diagnósticos deveriam ser incluídos na recuperação métricos documentadas para cada componente de TI. Incidente reparar: O tempo em que a falha tiver sido reparada / corrigido. Tempos de reparo de incidentes deve ser continuamente monitorado e comparado com as metas acordadas no âmbito Olas, subjacente contratos e outros acordos. Isto é particularmente importante no que diz respeito aos serviços fornecidos externamente e fornecedor atuação.

ITIL V3 - Service Design - Página:

194 de 477

•

•

Sempre que forem observadas quebras, técnicas devem ser usados para reduzir ou eliminar as falhas de incidentes semelhantes no futuro. Recuperação de incidentes: O momento em que a recuperação de componentes tenha sido concluída. O apoio e requisitos de recuperação para os componentes subjacente a uma nova De serviços de TI devem ser identificados o mais cedo possível no ciclo de design. Estes requisitos devem cobrir hardware, software e dados e de recuperação. O resultado disto atividade deve ser um conjunto de requisitos de recuperação documentado que permite que o desenvolvimento de planos de recuperação apropriados. Para antecipar e se preparar para a realização de recuperação tal reintegração de que o serviço é eficaz e eficiente exige o desenvolvimento e teste de recuperação adequado planos com base nos requisitos de recuperação documentados. Sempre que possível, o operacional atividades dentro da recuperação plano deve ser automatizado. O teste dos planos de recuperação também oferece horários aproximados para a recuperação. Essas métricas de recuperação pode ser usado para apoiar a comunicação de recuperação estimado de serviço e validar ou melhorar o componente falha documentação Análise de Impacto. Gerenciamento de Disponibilidade deve continuamente buscar e promover métodos mais rápidos de recuperação para todos os incidentes potenciais. Isto pode ser conseguido através de uma variedade de métodos, incluindo a não automatizada detecção, Recuperação automatizado, mais rigorosas escalada procedimentos, exploração de ferramentas de recuperação de novas e mais rápidas e técnicas. Os requisitos de disponibilidade devem também contribuir para determinar que peças de reposição são mantidos dentro das Peças definitivas para facilitar reparos rápidos e eficazes, como descrito no Transição de Serviço publicação. Restauração incidente: O tempo no qual normais serviço de negócio é retomada. Um incidente só pode ser considerado 'fechado'Uma vez o serviço foi restaurado e comercial normal operação foi retomado. É importante que o restaurado de serviços de TI é verificado como trabalhar corretamente assim que a restauração do serviço é concluído e antes de qualquer equipe técnica envolvida no incidente são permaneceu baixo. Na maioria dos casos, isso é simplesmente um caso de obter a confirmação de que os usuários afetados. No entanto, os usuários de alguns serviços pode ser clientes do negócio, ou seja, serviços de caixa eletrônico, de serviços de Internet. Para estes tipos de serviços, recomenda-se que o serviço de TI verificação procedimentos são desenvolvidos para permitir a Provedor de serviços de TI organização para verificar se um restaurado de serviços de TI agora está trabalhando como esperado. Estes poderiam ser simplesmente controlos visuais transação rendimento ou scripts de usuário de simulação que validam o serviço end-to-end.

ITIL V3 - Service Design - Página:

195 de 477

Cada fase, e o tempo associado tomadas, influencia o total tempo de inatividade percebido pela usuário. Ao adotar essa abordagem, é possível ver que o tempo está sendo "perdido" para a duração de um incidente. Por exemplo, o serviço não estava disponível para o negócio por 60 minutos, mas levou apenas cinco minutos para aplicar uma correção - onde os outros 55 minutos vão? Usando essa abordagem identifica possíveis áreas de ineficiência que se combinam para tornar a perda de serviço experimentado pelo negócio maior do que o necessário. Estes poderiam abranger áreas como automação pobres (alertars, recuperação automática etc), pobres ferramentas de diagnóstico e scripts, claro escalação procedimentos (o que demora a escalada para o apropriado grupo de e técnico ou fornecedor), Ou falta de documentação operacional abrangente. Gerenciamento de Disponibilidade deve trabalhar em estreita associação com a Incidentes e Gerenciamento de Problemas para assegurar ocorrências repetidas são eliminados. Recomenda-se que estas medidas são estabelecidas e capturado para todos os incidentes disponibilidade. Isto proporciona Gerenciamento de Disponibilidade com métricos para ambos os incidentes específicos e informações de tendências. Esta informação pode ser usada como entrada para SFA atribuições, atividades SIP e relatórios de gestão regular Disponibilidade e para fornecer um impulso para a melhoria contínua atividade para prosseguir melhoramentos rentáveis. Ele também pode permitir a fixação de objectivos para fases específicas do ciclo de vida do incidente. Embora itindo que cada incidente pode ter uma ampla gama de complexidade técnica, os alvos podem ser usados de modo a reflectir a consistência da forma como a TI provedor de serviços organização responde a incidentes. Uma saída do Gerenciamento de Disponibilidade processo é a requisitos de monitoramento em tempo real para De serviços de TIs e componentes. Para atingir os níveis de disponibilidade necessária e / ou assegurar a rápida restauração do serviço na sequência de um IT falha requer investimento e exploração de um conjunto de ferramentas de gerenciamento de sistemas. Ferramentas de gerenciamento de sistemas, são um elemento essencial para os serviços de TI que requerem um alto nível de disponibilidade e pode fornecer um valor inestimável papel em reduzir a quantidade de tempo de inatividade incorridos. Requisitos de gerenciamento de disponibilidade cobrir a detecção e alerta de TI serviço e exceções de componentes, escalação automatizada e notificação de falhas de TI e da recuperação automatizada e recuperação dos componentes de situações de falha conhecido. Isto faz com que seja possível identificar onde "tempo é perdido e proporciona a base para a identificação de factores que podem melhorar os tempos de recuperação e de restauração. Estas atividades são realizadas em uma base regular dentro Operação de Serviço. Análise de falha de serviço

ITIL V3 - Service Design - Página:

196 de 477

Análise de falha de serviço (SFA) é uma técnica destinada a proporcionar uma abordagem estruturada para identificar as causas das interrupções de serviço para o usuário. SFA utiliza uma variedade de fontes de dados para avaliar onde e por deficiências na disponibilidade estão ocorrendo. SFA permite uma visão holística do ser tomados para não impulsionar melhorias apenas de tecnologia, mas também melhorias no e de TI da organização, processos, procedimentos e ferramentas. SFA é executado como uma tarefa ou projeto, E pode utilizar métodos disponibilidade outros e técnicas de gestão para formular as recomendações de melhoria. A análise detalhada das interrupções de serviço podem identificar oportunidades para melhorar os níveis de disponibilidade. SFA é uma técnica estruturada para identificar oportunidades de melhoria no fim-definal a disponibilidade do serviço, que pode trazer benefícios para o usuário. Muitas das atividades envolvidas na SFA estão estreitamente alinhados com os de Gerenciamento de Problemas, e em um número de organizações essas atividades são realizadas em conjunto pela Problema e Gerenciamento de Disponibilidade. O alto nível objetivos de SFA são: •

• • • •

Para melhorar a disponibilidade global de serviços de TI através da produção de um conjunto de melhorias para a implementação ou de entrada para o Plano de disponibilidade Para identificar as causas de interrupção do serviço aos usuários Para avaliar o eficácia do e de TI e processos de organização chave Para produzir relatórios detalhando as principais conclusões e recomendações Que as melhorias Disponibilidade derivados de SFA-driven atividades são medidos.

Iniciativas SFA deve usar a entrada de todas as áreas e todos os processos, incluindo, principalmente, o negócio e usuários. Cada atribuição SFA deve ter um patrocinador reconhecido (s) (de preferência, o patrocínio conjunto da TI e de negócios) e envolver recursos de diversas áreas técnicas e de processo. A utilização da abordagem SFA: • • •

•

Fornece a capacidade de oferecer melhores níveis de disponibilidade sem grande custar Fornece o negócio com o compromisso visível da organização de e de TI Desenvolve-se em casa de habilidades e competências para evitar atribuições de consultoria caros relacionadas com a melhoria disponibilidade Incentiva multifuncional equipe de trabalho e quebra as barreiras entre as equipes, e é um facilitador para o pensamento lateral, desafiando

ITIL V3 - Service Design - Página:

197 de 477

• • •

pensamentos tradicionais e fornecendo inovador, de baixo custo e, muitas vezes, soluções Fornece uma programa de oportunidades de melhoria que podem fazer uma diferença real para o serviço qualidade e usuário percepção Oferece oportunidades que estão focados em oferecer benefício para o usuário Fornece um "exame de saúde" independente de IT Service Management processos e é o estímulo para melhorias de processo.

Para maximizar o tempo de indivíduos afectados à atribuição SFA e a qualidade do relatório entregue, uma abordagem estruturada é necessária. Esta estrutura é ilustrada na Figura 4.16. Esta abordagem é semelhante a muitos consultoria modelos utilizados na indústria, e de muitas maneiras Gerenciamento de Disponibilidade pode ser considerado como proporcionando uma via SFA forma de consultadoria interno.

Figura 4.16 A abordagem estruturada para a Análise de Falhas de Serviço (AGS)

A estrutura de alto nível acima é descrito resumidamente como se segue.

ITIL V3 - Service Design - Página:

198 de 477

•

•

•

•

•

•

Selecione oportunidade: Antes de agendar uma atribuição SFA, é necessário que haja acordo quanto ao que De serviços de TI ou tecnologia é para ser selecionado. Recomenda-se que um número acordado de atribuições são programadas por ano dentro do Plano de disponibilidade e, se possível, os serviços de TI são selecionados com antecedência como parte da abordagem proativa para Gerenciamento de Disponibilidade. Antes de se iniciar com o SFA, é importante que a atribuição tem um promotor reconhecido a partir da organização de TI e / ou o negócio e que eles estão envolvidos e atualizado regularmente com o progresso da SFA atividade. Isso garante visibilidade organizacional à SFA e garante recomendações são aprovados em um nível sênior dentro da organização. Escopo atribuição: Esta é a declarar explicitamente que áreas são e não são cobertas pela atribuição. Isto é normalmente documentada em Termos de referência emitidos antes da atribuição. Plano de atribuição: A atribuição SFA precisa ser planejado um número de semanas de antecedência da atribuição início, com um acordo projeto plano e um conjunto de recursos comprometidos. O projeto deve olhar para a identificação de oportunidades de melhoria que beneficiem a usuário. Portanto, é importante que uma visão fim-a-fim dos dados e Sistema de Gerenciamento de Informações (MIS) requisitos é tomada. Os dados e documentos devem ser recolhidas e analisadas todas as áreas do usuário e perspectiva de negócios. Um "virtual" time SFA deve ser formado a partir de todas as áreas relevantes para assegurar que todos os aspectos e perspectivas são considerados. O tamanho da equipe deve refletir o escopo e complexidade do serviço SFA. Construir hipótese: Este é um método útil de construção de cenários prováveis, que podem ajudar a equipe do estudo tirar conclusões iniciais dentro do período de análise. Esses cenários podem ser construídos a partir de discutir a atribuição próxima com a chave papels, por exemplo, alta istração e os usuários, ou usando o planejamento sessão de brainstorm a lista da equipe montada. A lista completa hipóteses devem ser documentados e entrada para o período de análise para fornecer algum foco inicial dos dados e Sistema de Gerenciamento de Informações (MIS) que coincidem com os cenários individuais. Deve notar-se que esta abordagem também elimina os problemas percebidos, isto é, não existem dados ou MIS substancia que é percebido como um serviço questão. Analisar os dados: O número de pessoas que formam a equipe SFA dita como atribuir responsabilidades específicas de análise. Durante este período, a análise da lista hipóteses devem ser usados para ajudar a extrair algumas conclusões iniciais. Pessoal-chave da entrevista: É essencial que os representantes-chave de negócios e usuários são entrevistados para garantir o negócio e usuário perspectivas são capturados. É surpreendente como este diálogo pode identificar oportunidades de ganhos rápidos, como muitas vezes o que a empresa vê como um grande problema pode ser resolvido através

ITIL V3 - Service Design - Página:

199 de 477

•

•

•

•

de uma solução de TI simples. Portanto, essas entrevistas deve ser iniciado o mais cedo possível dentro da atribuição SFA. A equipe de estudo também deve procurar a entrada de pessoas-chave dentro da Provedor de serviços de TI organização para identificar áreas problemáticas e possíveis soluções adicionais que podem ser alimentadas de volta para a equipe de estudo. O diálogo também ajuda a capturar aquelas questões que não são facilmente visíveis a partir dos dados reunidos e relatórios MIS. Resultados e conclusões: Após a análise dos dados fornecidos e MIS, entrevistas e re contínuavisão da lista de hipóteses, a equipe de estudo deve estar em uma posição para começar a documentar os resultados iniciais e conclusões. Recomenda-se que a equipe de atender imediatamente após o período de análise para compartilhar suas descobertas individuais e, em seguida, ter uma visão agregada para formar os resultados preliminares e as conclusões. É importante que os resultados podem ser comprovadas através de dados recolhidos durante a análise. Durante esta fase do trabalho, pode ser necessário para validar encontrar (s) por uma análise adicional para garantir a equipe SFA pode fazer backup de todos os resultados com evidências documentadas claro. Recomendações: Depois de todos os resultados e as conclusões foram validadas, a equipe SFA deve estar em condições de formular recomendações. Em muitos casos, as recomendações para apoiar uma conclusão particular, são simples e óbvio. No entanto, o benefício de trazer uma equipe multifuncional juntos para a atribuição SFA é criar um ambiente para o pensamento inovador-lateral abordagens. O líder atribuição SFA deve facilitar esta sessão com o objectivo de identificar as recomendações que são práticos e sustentáveis, uma vez implementado. Relatório: O relatório final deve ser entregue ao patrocinador com um resumo de gestão. Estilos de relatórios normalmente são determinados pelas organizações individuais. É importante que o relatório mostra claramente que a perda de disponibilidade está sendo incorridos e como as recomendações resolver esta questão. Se o relatório contém várias recomendações, uma tentativa deverá ser feita para quantificar a vantagem da disponibilidade de cada uma recomendação, juntamente com o esforço estimado de implementar. Isto permite escolhas informadas a ser feito sobre a forma de receber as recomendações para a frente e como estes devem ser priorizados e com recursos. Validação: Recomenda-se que para cada SFA, medidas-chave que refletem o negócio e usuário perspectivas antes da atribuição são capturados e registrado como o 'antes' vista. Como recomendações SFA estão progredindo, o positivo impactos de disponibilidade deverá ser capturada para proporcionar o ponto de vista do "depois" para fins comparativos. Onde os benefícios esperados não foram entregues, esta deve ser investigada e ações corretivas tomadas. Depois de ter investido tempo e esforço em completar a tarefa SFA, é importante que as recomendações, uma vez aprovadas pelo patrocinador, então, são

ITIL V3 - Service Design - Página:

200 de 477

levados para a frente para a implementação. O melhor mecanismo para conseguir isso é através da incorporação das recomendações como atividades para ser concluído dentro do Plano de disponibilidade ou o SIP global. O sucesso do trabalho SFA como um todo deve ser monitorado e medido para garantir a sua continuidade eficácia. Considere categorizar as recomendações sob os seguintes títulos: DETECÇÃO: Recomendações que, se implementado, vai fornecer relatórios reforçada de indicadores-chave para garantir TI subjacente questões de serviço são detectados cedo para permitir uma resposta pró-ativa. REDUÇÃO: Recomendações que, se implementado, vai reduzir ou minimizar o usuário impacto da TI interrupção do serviço, por exemplo, recuperação e / ou restauração pode ser melhorado para reduzir a duração do impacto. PREVENÇÃO: Recomendações que, se implementado, irá eliminar esta causa especial de De serviços de TI interrupção. 4.4.5.2 As atividades pró-ativas de gerenciamento de disponibilidade

O capacidade do Gerenciamento de Disponibilidade processo é positivamente influenciada pela variedade e qualidade de métodos e técnicas pró-activas utilizadas pelo processo. As seguintes atividades são as técnicas proativas e atividades do processo de Gerenciamento de Disponibilidade. Identificação de funções vitais para o negócio (VBFs) O termo Função de Negócios Vital (VBF) é usada para refletir os elementos críticos de negócio do processo de negócio ados por um serviço de TI. O serviço pode também apoiar as funções de negócio menos críticas e processos, e é importante que os VBFs são reconhecidos e documentados para fornecer o alinhamento de negócios adequado e se concentrar. Projetando para disponibilidade O nível de disponibilidade exigida pela negócio influencia a global custar do serviço oferecido. Em geral, quanto maior o nível de disponibilidade requerido pela empresa, maior o custo. Estes custos não são apenas os contratos da base de tecnologia da informação e serviços necessários para apoiar o Infra-estrutura de TI. Os custos adicionais são incorridos na prestação do adequado Serviço de Gestão de processos, sistemas de gestão e ferramentas de alta disponibilidade soluções necessárias para atender os requisitos de disponibilidade mais rigorosos. O maior nível de disponibilidade deverá ser incluída na projeto dos serviços de apoio a mais crítica das VBFs.

ITIL V3 - Service Design - Página:

201 de 477

Ao considerar como os requisitos de disponibilidade do negócio devem ser satisfeitos, é importante para assegurar que o nível de disponibilidade de ser prevista uma De serviços de TI é, na verdade, ao nível necessário, e é ível e economicamente justificável para o negócio. Figura 4.17 indica os produtos e processos necessários para fornecer diferentes níveis de disponibilidade e as implicações de custo.

Figura 4.17 Relação entre os níveis de disponibilidade e custos gerais

Produto base e componentes A aquisição ou desenvolvimento da tecnologia de base de produtos, e componentes deve ser com base na sua capacidade para cumprir a disponibilidade e rigoroso confiança requisitos. Estes devem ser considerados como a pedra angular do projeto disponibilidade. O investimento adicional necessário para alcançar níveis ainda mais altos de disponibilidade será desperdiçado e níveis de disponibilidade não atingida se esses produtos de base e componentes não são confiáveis e propenso a falha. Sistemas de gestão

ITIL V3 - Service Design - Página:

202 de 477

Gerenciamento de sistemas deve fornecer o monitoramento, De diagnóstico e automatizado erro recuperação para permitir rápido detecção e rápida resolução de falha de TI potencial e real. Gestão de processos de serviços Eficaz Serviço de Gestão de processos contribuem para os níveis mais altos de disponibilidade. Processos tais como Gerenciamento de Disponibilidade,Gerenciamento de Incidentes,Gerenciamento de Problemas,Gestão da Mudança,Gerenciamento da Configuração, Etc desempenhar um papel crucial papel na gestão global do serviço de TI. Alta disponibilidade desenho O projeto para alta disponibilidade tem de considerar a eliminação de SPoFs e / ou a provisão de componentes alternativos para fornecer o mínimo de interrupção para o negócio operação deve falha de um componente de TI ocorrer. O desenho também necessita de eliminar ou minimizar os efeitos da planeada tempo de inatividade para a operação comercial é normalmente necessário para acomodar operações de manutenção, a implementação de mudars para a infra-estrutura de TI ou de aplicativos de negócios. Os critérios de recuperação deve definir a rápida recuperação e reintegração de TI serviço como uma chave objetivo dentro do projeto para a fase de recuperação do design. Soluções especiais com redundância total Para abordar disponibilidade contínua na gama de 100% requer soluções caras que incorporam espelhamento completo ou redundância. Redundância é a técnica de melhorar a disponibilidade, usando componentes duplicados. Os requisitos de disponibilidade estritas a serem cumpridas, estes precisam trabalhar de forma autônoma em paralelo. Essas soluções não estão restritas apenas aos componentes de TI, mas também para os ambientes de TI, ou seja, centros de dados, fontes de alimentação, ar condicionado e de telecomunicações. Em caso de novos serviços de TI estão sendo desenvolvidos, é essencial que a istração Disponibilidade leva um projeto adiantado e participar papel na determinação dos requisitos de disponibilidade. Isto permite gerenciamento de disponibilidade para influenciar positivamente o Infra-estrutura de TI projetar para garantir que ele pode oferecer o nível de disponibilidade exigido. A importância dessa participação no início da projeto da infra-estrutura de TI não pode ser subestimada. É preciso haver um diálogo entre a TI eo negócio, para determinar o equilíbrio entre a percepção de negócios da custar de indisponibilidade eo custo exponencial de entregar os níveis mais altos de disponibilidade.

ITIL V3 - Service Design - Página:

203 de 477

Como ilustrado na Figura 4.17, existe um aumento significativo nos custos quando o requisito do negócio é maior do que o nível óptimo de disponibilidade que a infra-estrutura de TI pode entregar. Esses aumentos de custos são movidos por grande reformulação da tecnologia e da mudança de requisitos para o e de TI organização. É importante que o nível de disponibilidade concebido para o serviço é apropriada para as necessidades comerciais, a criticidade da processo de negócioes sendo apoiado e do orçamento disponível. O negócio deve ser consultado no início do Design de Serviços ciclo de vida de modo que a empresa precisa de disponibilidade de um novo ou aprimorado De serviços de TI podem ser avaliados e concordou. Isto é particularmente importante quando os requisitos de disponibilidade rigorosos pode exigir investimento adicional em Serviço de Gestão de processos, serviços de TI e Sistema de Gestão de ferramentas, alta disponibilidade de design e soluções especiais com redundância total. É provável que as actividades necessárias para a disponibilidade de TI não pode ser expressa em termos técnicos. Gerenciamento de Disponibilidade portanto, proporciona um importante papel em ser capaz de traduzir os negócios e usuário requisitos em metas quantificáveis disponibilidade e condições. Esta é uma contribuição importante para a TI Design de Serviços e fornece a base para a avaliação do capacidade do projeto de TI e e de TI organização em atender os requisitos de disponibilidade do negócio. Os requisitos de negócio para a disponibilidade de TI deve conter, pelo menos: • • • • • • • •

A definição dos VBFs ados pelo serviço de TI A definição de TI downtime do serviço, isto é, as condições em que o negócio considera o serviço de TI para estar disponível O impacto nos negócios causado pela perda de serviço, Em conjunto com a associada risco Requisitos de disponibilidade quantitativos, isto é, a medida em que a actividade de TI tolera serviço tempo de inatividade ou serviço degradado As horas de serviço necessários, ou seja, quando o serviço é prestado Um avaliação a importância relativa de diferentes tempos de trabalho Específico segurança requisitos O serviço apoio e recuperação capacidade.

Uma vez que o design de tecnologia de TI e e de TI organização são determinados, o provedor de serviços organização é, então, em posição de confirmar se os requisitos de disponibilidade podem ser cumpridas. Onde são identificados défices diálogo, com a negócio é obrigado a apresentar as opções de custo que existem para melhorar o projeto proposto para atender os requisitos de disponibilidade. Isso permite que a empresa a reavaliar se os

ITIL V3 - Service Design - Página:

204 de 477

níveis mais baixos ou mais altos de disponibilidade são necessários, e para entender o impacto apropriado e custars associados à sua decisão. Determinando os requisitos de disponibilidade é provável que seja um processo iterativo processo, Em particular quando existe uma necessidade de equilibrar a disponibilidade comercial exigência contra os custos associados. Os os necessários são os seguintes: • •

• • • • •

Determinar a actividade impacto causada pela perda de serviço A partir dos requisitos de negócios, especifique o disponibilidade, Confiabilidade e manutenção requisitos para o De serviços de TI e componentes apoiada pelo e de TI organização De serviços de TI e componentes fornecidos externamente, identificar o manutenção requisitos Estimar os custos envolvidos no atendimento a disponibilidade, confiança, Facilidade de manutenção e requisitos de utilização Determinar, com o negócio, se os custos identificados no cumprimento dos requisitos de disponibilidade são justificados Determinar, a partir do negócio, os custos que possam ser efectuadas a partir de perda ou degradação do serviço Onde estes são vistos como custo justificado, definir os requisitos de disponibilidade, confiabilidade, manutenção e manutenção em acordos e negociar em contratos.

Se os custos são vistos como proibitivo, ou: • •

Reavaliar a Infra-estrutura de TI projetar e fornecer opções para reduzir os custos e avaliar as consequências sobre a disponibilidade, ou Reavaliar o uso comercial e confiança no serviço de TI e renegociar a disponibilidade metas dentro do SLA.

O processo SLM é normalmente responsável pela comunicação com o negócio sobre a forma como os seus requisitos de disponibilidade dos serviços de TI estão a ser cumpridos e negociar o SLR / SLA para o processo de IT Service Design. Gerenciamento de Disponibilidade portanto, fornece um apoio importante e entrada para ambos os processos de SLM e design durante este período. Embora os níveis mais altos de disponibilidade muitas vezes pode ser fornecida pelo investimento em ferramentas e tecnologia, não há justificativa para a prestação de um maior nível de disponibilidade do que a necessária e proporcionada pelo negócio. A realidade é que satisfazer requisitos de disponibilidade é sempre um equilíbrio entre custo e qualidade. Este é o lugar onde Gerenciamento de Disponibilidade pode jogar uma chave papel na disponibilidade de otimização da TI Design de Serviços para atender a demanda crescente disponibilidade enquanto adiar um aumento nos custos.

ITIL V3 - Service Design - Página:

205 de 477

Projetando serviço de disponibilidade é uma chave atividade impulsionado pelo gerenciamento de disponibilidade. Isso garante que o nível de disponibilidade de um serviço de TI podem ser cumpridas. Gerenciamento de disponibilidade tem de assegurar que a atividade de design para a disponibilidade olha para a tarefa de duas relacionadas, mas distintas, perspectivas: •

•

Projetando para disponibilidade: Esta atividade relaciona-se com o projeto técnico da De serviços de TI e o alinhamento do interno e externo fornecedors necessário para atender os requisitos de disponibilidade do negócio. Ele deve abranger todos os aspectos da tecnologia, incluindo infra-estrutura, ambiente, Dados e aplicaçãos. Projetando para recuperação: Esta actividade está relacionada com os pontos de design necessários para assegurar que, no caso de um serviço de TI falha, O serviço e seu apoio componentes pode ser reintegrado para permitir normais operações comerciais para retomar o mais rapidamente possível. Este novo deve abranger todos os aspectos da tecnologia.

Além disso, a capacidade de recuperar rapidamente pode ser um factor crucial. Em termos simples, pode não ser possível ou economicamente justificados para construir um projeto que é altamente resistente a falha (s). A capacidade de atender os requisitos de disponibilidade, dentro dos parâmetros de custo pode confiar na capacidade de forma consistente para se recuperar de uma forma atempada e eficaz. Todos os aspectos da disponibilidade devem ser considerados no projeto de serviço processo e deve considerar todas as etapas dentro do ciclo de vida de serviços. A contribuição de gerenciamento de disponibilidade dentro das atividades do projeto é fornecer: • • • • • •

O especificação dos requisitos de disponibilidade de todos os componentes do serviço Os requisitos para pontos disponibilidade de medição (instrumentação) Os requisitos para novos sistemas / aumentada e Serviço de Gestão de Assistência com o Infra-estrutura de TI projeto A especificação da confiabilidade, manutenção e manutenção requisitos para componentes fornecidos pelo interno e externo fornecedors Validação do projeto final para atender os níveis mínimos de disponibilidade exigidos pela empresa para o serviço de TI.

Se os requisitos de disponibilidade não podem ser atendidas, a próxima tarefa é a re-avaliar o Design de Serviços e identificar o custo justificado projeto mudars. Melhorias no design para atender os requisitos de disponibilidade pode ser alcançada através da revisão do capacidade da tecnologia a ser implantada no projeto de TI proposto. Por exemplo:

ITIL V3 - Service Design - Página:

206 de 477

• •

• • • • • •

A exploração de tecnologia tolerante a falhas para mascarar o impacto da componente planejada ou não tempo de inatividade Duplexação, ou o próvisão de componentes alternativos de infra-estrutura para permitir que um componente para assumir o trabalho de outro componente Melhorar a componente confiança por regimes de ensaio realçando Design de software melhorado e desenvolvimento Melhoria de processos e procedimentos Sistemas de gestão de melhorias / exploração Melhorou fornecido externamente serviços, contratos ou acordos Desenvolver a capacidade de as pessoas com mais formação.

Considere documentar os requisitos de disponibilidade de design e considerações para novos serviços de TI, tornando-os disponíveis para o projeto e execução funções. Longo prazo procuram impor estes requisitos e integrar dentro da apropriadas governo mecanismos que cobrem a introdução de novos serviços de TI. Parte da atividade de projetar a disponibilidade deve garantir que todos os negócios de dados e informações segurança requisitos são incorporados no interior da Design de Serviços. O objectivo global da segurança de TI é "segurança equilibrado em profundidade", com justificável controlars implementados para assegurar que o Política de Segurança da Informação é aplicada e que continuou De serviços de TIs dentro de parâmetros de segurança (isto é, confidencialidade,integridade e disponibilidade) Continuam a operar. Durante a reunião dos requisitos de disponibilidade de novos serviços de TI, é importante que os requisitos que abrangem a segurança de TI são definidos. Estes requisitos devem ser aplicados na fase de projeto para a tecnologia de apoio. Para muitos organizaçãos, a abordagem adoptada para TI segurança é coberto por uma Política de Segurança da Informação de propriedade e mantido por Gestão de Segurança da Informação. Na execução do política de segurança,Gerenciamento de Disponibilidade desempenha um importante papel na sua operação para novos serviços de TI. Quando a operação de negócio tem uma alta dependência em TI a disponibilidade do serviço, eo custar de falha ou perda de reputação das empresas é considerada não aceitável, a empresa pode definir os requisitos de disponibilidade rigorosas. Esses fatores podem ser suficientes para o negócio para justificar os custos adicionais necessários para atender a esses níveis mais exigentes de disponibilidade. Atingir níveis acordados de disponibilidade começa com o desenvolvimento, aquisição, design e / ou de produtos de boa qualidade e componentes. No entanto, estes isolados não são susceptíveis de proporcionar os níveis sustentados de disponibilidade requeridos. Para atingir um nível consistente e sustentada de disponibilidade requer investimento e desenvolvimento de efetivo Serviço de Gestão de processos, ferramentas de

ITIL V3 - Service Design - Página:

207 de 477

gerenciamento de sistemas de alta disponibilidade e soluções de design finalmente especiais com espelhamento total ou redundância. Projetando para disponibilidade é uma chave atividade, Impulsionado pelo gerenciamento de disponibilidade, que garante que os requisitos de disponibilidade estabelecidos para um serviço de TI podem ser cumpridas. No entanto, gerenciamento de disponibilidade também deve garantir que dentro desta atividade de design não é o foco sobre os elementos necessários para assegurar que, quando os serviços de TI falham, o serviço pode ser reintegrado para permitir normais operações comerciais para retomar o mais rapidamente possível. "Projetando para recuperação"Pode, em primeiro som negativo. Projeto disponibilidade claramente bem é sobre como evitar falhas e entrega, sempre que possível, um tolerante a falhas de infra-estrutura de TI. No entanto, com este foco é colocado muita confiança na tecnologia, e tem como muita ênfase foi colocada nos aspectos de tolerância a falhas do Infra-estrutura de TI? A realidade é que as falhas ocorrerá. A forma como a organização de TI gerencia situações de falha pode ter um efeito positivo sobre a percepção do negócio, clientes e usuários dos serviços de TI. Todo fracasso é um "momento da verdade" importante - uma oportunidade para fazer ou quebrar sua reputação com o negócio. Ao fornecer o foco no "projetar para recuperação" aspectos da geral disponibilidade,projeto pode garantir que cada fracasso é uma oportunidade para manter e até mesmo melhorar negócios e usuário satisfação. Para fornecer uma efetiva 'projeto para a recuperação ", é importante reconhecer que o negócio e da organização de TI têm necessidades que precisam ser satisfeitas para permitir uma recuperação eficaz de TI falha. Estas são as necessidades informativas que o negócio exige para ajudá-los a gerenciar o impacto de falha em seus negócios ea expectativa do jogo dentro da comunidade de usuários de negócios, e sua empresa clientes. Estas são as habilidades, conhecimentos, processoes, procedimentos e ferramentas necessárias para permitir a recuperação técnica para ser concluída em um momento ótimo. Considere documentar os requisitos de recuperação de design e considerações para novos serviços de TI e torná-los disponíveis para as áreas responsáveis pela concepção e execução. A longo prazo, buscam impor estes requisitos e integrá-los dentro dos mecanismos de governação adequados que cobrem a introdução de novos serviços de TI. Um objectivo essencial é para evitar incidentes menores se tornem incidente graves, garantindo as pessoas certas estão envolvidos cedo o suficiente para evitar os erros que estão sendo feitas e para garantir o negócio apropriado e técnica recuperação procedimentos são invocados na primeira oportunidade. A instigação destas atividades é de responsabilidade do Gerenciamento de Incidentes e um processo de papel do Service Desk. Para garantir as

ITIL V3 - Service Design - Página:

208 de 477

necessidades do negócio sejam atendidas durante grande De serviços de TI falhas, e para garantir a recuperação mais ideal, o processo de Gerenciamento de Incidentes e Service Desk precisa ter definido e executar procedimentos eficazes para a avaliação e gestão de todos os incidentes. O exposto acima não são de responsabilidade do Gerenciamento de Disponibilidade. No entanto, o eficácia do processo de Gerenciamento de Incidentes e Service Desk pode influenciar fortemente o período de recuperação global. A utilização de métodos de gestão e disponibilidade de técnicas para posterior otimizar TI recuperação pode ser o estímulo para as atividades subseqüentes de melhoria contínua do processo de Gerenciamento de Incidentes e Service Desk. A fim de manter a eficácia, a manutenção de serviços de TI e componentes devem ser monitorados, e seu impacto sobre o 'ciclo de vida do incidente expandida'Entendido, geridos e melhorados. Componente Análise de Impacto falha Componente Análise de Impacto falha (CFIA) podem ser utilizados para prever e avaliar o impacto sobre o serviço de TI resultantes da falha de componentes dentro da tecnologia. A saída de um CFIA pode ser usado para identificar onde adicional resiliência devem ser consideradas para evitar ou minimizar o impacto da falha de componentes para a operação de negócio e usuários. Isto é particularmente importante durante a Design de Serviços palco, onde é necessário prever e avaliar o impacto sobre a disponibilidade do serviço de TI decorrentes de falhas de componentes dentro do Design de Serviços de TI proposta. No entanto, a técnica também pode ser aplicada aos serviços existentes e infra-estrutura. CFIA é uma técnica relativamente simples, que pode ser usada para fornecer esta informação. IBM concebeu CFIA no início de 1970, com suas origens baseadas em design de hardware e configuração. No entanto, recomenda-se que CFIA ser usado num contexto mais amplo de modo a reflectir o completo escopo da infra-estrutura de TI, ou seja, hardware, rede, software, aplicaçãos, centros de dados e pessoal de apoio. Além disso, a técnica também pode ser aplicado para identificar e dependências impacto sobre o e de TI organização habilidades e competências entre o pessoal de apoio do serviço de TI novo. Este atividade é geralmente completada em conjunto com ITSCM e possivelmente Gerenciamento da Capacidade. A saída de um CFIA fornece informações vitais para garantir que a disponibilidade e recuperação critérios de projeto para o novo serviço de TI é influenciado para evitar ou minimizar o impacto de falha para o funcionamento da empresa e os usuários. ACIA realiza esta oferecendo e indicando:

ITIL V3 - Service Design - Página:

209 de 477

• • • • • •

SPoFs que podem impactar disponibilidade O impacto da falha de um componente sobre o negócio operação e os usuários Dependências do componente e as pessoas Recuperação horários de componentes A necessidade de identificar e documentar opção de recuperaçãos A necessidade de identificar e implementar medidas de redução de risco.

A descrição acima pode também fornecer o estímulo para a entrada de ITSCM a considerar o equilíbrio entre as opções de recuperação e medidas de redução de risco, ou seja, onde o impacto potencial é alto, há uma necessidade de se concentrar em alta disponibilidade de medidas de redução de risco, ou seja, aumento da resiliência ou espera sistemas. Tendo determinado o Infra-estrutura de TI configuração a ser avaliada, a primeira etapa é criar uma grade com IC em um eixo e os serviços de TI que têm um dependência no CI por outro lado, como ilustrado na Figura 4.18. Esta informação deve estar disponível a partir do CMS, ou, alternativamente, pode ser construído usando tabelas de configuração documentados e SLAs.

Figura 4.18 Componente Análise de Impacto falha

O o seguinte consiste em realizar a CFIA e preencher a grade da seguinte forma:

ITIL V3 - Service Design - Página:

210 de 477

• • • •

Deixe um espaço em branco quando um falha do IC não tem impacto sobre o serviço de qualquer maneira Insira um 'X' quando o fracasso da CI faz com que o serviço de TI a ser inoperante Inserir um "A", quando não há um CI alternativa para fornecer o serviço Inserir um "M" quando existe um CI alternativa, mas o serviço requer a intervenção manual para ser recuperado.

Tendo construído a grade CIs, que têm um grande número de Xs são críticos para muitos serviços e pode resultar em grande impacto no caso de o CI falhar. Da mesma forma, os serviços de TI com alta contagem de Xs são complexos e são vulneráveis ao fracasso. Esta abordagem de base para CFIA pode fornecer informações valiosas a identificar rapidamente SPoFs, serviços de TI em risco de fracasso CI e que alternativas estão disponíveis devem CIs falhar. Deve também ser utilizada para avaliar a existência e validade de recuperação procedimentos para a CEI selecionado. O exemplo acima assume infra-estrutura comum de apoio múltiplos serviços de TI. A mesma abordagem pode ser utilizada por um serviço único de TI, mapeando o componente IC contra os VBFs e utilizadores ados por cada componente, Assim, compreender o impacto de uma falha de componente no negócio e usuário. A abordagem também pode ser aperfeiçoado e desenvolvido para incluir e desenvolver factores 'disponibilidade de ponderação componente que podem ser utilizados para avaliar e calcular o efeito global do componente falha sobre a disponibilidade do serviço total. Para realizar uma CFIA avançada requer a matriz CFIA a ser expandido para fornecer campos adicionais necessários para a análise mais detalhada. Isto poderia incluir campos, tais como: •

•

•

•

Ponderação disponibilidade dos componentes: Um factor de ponderação apropriado para o impacto de falha do componente na disponibilidade de serviço total. Por exemplo, se a falha de um switch pode causar 2.000 usuários de perder o serviço de um serviço total usuário base de 10.000, então o factor de ponderação deve ser de 0,2, ou 20% Probabilidade de falha: Esta pode basear-se na confiança do componente medido pela Tempo médio entre falhas (MTBF) informação disponível ou, se as tendências atuais. Isto pode ser expresso como um indicador de baixo / médio / alto, ou como uma representação numérica O tempo de recuperação: Esta é a estimativa recuperação tempo para se recuperar da IC. Isto pode ser baseado em horários de recuperação, informações recentes de recuperação a partir de testes de recuperação de desastre ou uma recuperação teste programado Procedimentos de recuperação: Este é verificar que os procedimentos de up-to-date de recuperação estão disponíveis para o CI

ITIL V3 - Service Design - Página:

211 de 477

•

•

Independência de dispositivos: Onde CIs software tem arquivos duplex para fornecer resiliência, Isto é para assegurar que os canais de arquivo foram verificados como estando na configuração de hardware de disco separados. Isto também se aplica ao fornecimento de energia - deve-se verificar que as fontes de alimentação alternativas estão conectados corretamente Dependência: Isso é para mostrar as dependências entre os ICs. Se uma falha CI, pode haver um impacto sobre outros CIs - por exemplo, se o segurança IC falhou, o sistema operacional pode impedir o processamento de fita.

Ponto Único de Análise de falha APonto único de falha (SPOF) é qualquer componente dentro da infra-estrutura de TI que não tem apoio ou failover capacidade, E tem o potencial para causar perturbações ao negócio,clientes ou usuários quando ele falhar. É importante que nenhum SPoFs não reconhecidos existir dentro da infra-estrutura ou desenho da tecnologia actual, e que eles são evitados sempre que possível. A utilização de análise ou SPOF CFIA como técnicas para identificar SPoFs é recomendada. SPOF e exercícios de análise CFIA deve ser efectuado numa base regular, e sempre que forem identificadas SPoFs, CFIA pode ser usado para identificar o cliente potencial comercial, ou usuário impactar e ajudar a determinar quais alternativas podem ou devem ser considerados para atender a essa fraqueza na projeto ou a infra-estrutura real. Contramedidas devem ser aplicadas onde quer que estejam custo justificável. O impacto e os transtornos causados pela falha potencial do SPOF deve ser usado para custar-justificam sua implantação. Análise da Árvore de Falhas Análise da Árvore de Falhas (TLC) é uma técnica que pode ser usada para determinar a cadeia de eventos que provoca uma perturbação De serviços de TIs. TLC, em conjunto com os métodos de cálculo, pode oferecer detalhada modelos de disponibilidade. Isto pode ser usado para avaliar a melhoria de disponibilidade que pode ser alcançado através de tecnologia individuais opções de concepção dos componentes. Usando FTA: • • •

A informação pode prever-se que pode ser usado para os cálculos de disponibilidade As operações podem ser executadas na árvore de falhas resultantes; estas operações corresponder com opções de concepção O nível de detalhe desejado para a análise pode ser escolhida.

TLC faz uma representação de uma cadeia de eventos usando notação booleana. Figura 4.19 apresenta um exemplo de uma árvore de falhas.

ITIL V3 - Service Design - Página:

212 de 477

Figura 4.19 Exemplo de Análise da Árvore de Falhas

Essencialmente FTA distingue os seguintes eventos: •

•

•

Acontecimentos básicos - Pontos terminais para a árvore de falhas, por exemplo, falha de energia operador, erro. Eventos básicos não são investigados em grande profundidade. Se os eventos básicos são investigados em mais profundidade, eles tornam-se automaticamente eventos resultantes. Eventos resultantes - Nós intermediários da árvore de falhas, resultantes de uma combinação de eventos. O ponto mais alto da árvore de falhas é geralmente um falha do serviço de TI. Eventos condicionais - Eventos que ocorrem apenas em determinadas condições, por exemplo, falha do equipamento de ar-condicionado só afeta o serviço de TI se a temperatura ultraa os valores equipamento reparadas.

ITIL V3 - Service Design - Página:

213 de 477

•

Os eventos de disparo - Eventos que desencadeiam outros eventos, por exemplo, falha de energia detecção equipamento pode provocar o desligamento automático da De serviços de TIs.

Estes eventos podem ser combinados usando operadores lógicos, ou seja: • • • •

E-gate - A resultante evento só ocorre quando todos os eventos de entrada ocorrer simultaneamente OR-gate - O evento resultante ocorre quando um ou mais eventos de entrada ocorre Exclusivo OR-gate - O evento resultante ocorre quando um e apenas um dos eventos de entrada ocorre Inibir portão - O evento resultante somente ocorre quando a condição de entrada não for cumprida.

Esta é a técnica básica FTA. Esta técnica pode também ser refinados, mas complexo e FTA a avaliação matemática de árvores de falhas estão fora do âmbito da presente publicação. Modelagem Para avaliar se os novos componentes dentro de um desenho pode corresponder aos requisitos pretendidos, é importante que o regime de teste garante que o instigou disponibilidade esperado pode ser entregue. Simulação, modelagem ou carregar ferramentas de teste para gerar o esperado usuário demanda para o serviço de TI novo deve ser seriamente considerado para garantir componentes continuam a operar sob volume antecipado e condições de estresse. Ferramentas de modelagem também são obrigados a previsão de disponibilidade e para avaliar a impacto de alterações no Infra-estrutura de TI. As entradas para a modelagem processo incluem dados descritivos da confiabilidade dos componentes, manutenção e manutenção. Um pacote de folha de cálculo para realizar cálculos geralmente é suficiente. Se os dados mais detalhados e precisos é necessário, uma ferramenta de modelagem mais complexos podem ter de ser desenvolvidas ou adquiridas. A falta de ferramentas de modelagem disponibilidade prontamente disponíveis no mercado pode exigir uma ferramenta a ser desenvolvida e mantida "in-house", mas esta é uma atividade muito caro e demorado, que só deve ser considerado que o investimento pode ser justificado. A menos que haja um benefício claramente percebida a partir de um tal desenvolvimento e os custos de manutenção, o uso das ferramentas existentes e planilhas devem ser suficientes. No entanto, alguns Sistema de Gestão de ferramentas não fornecem capacidade de modelagem e pode fornecer informações úteis sobre tendências e previsão das necessidades de disponibilidade.

ITIL V3 - Service Design - Página:

214 de 477

Análise e Gestão de Riscos Para avaliar o vulnerabilidade de falha no interior da configuração e capacidade do serviço de TI e e organização recomenda-se que existente ou propostas de infra-estrutura de TI, configurações de serviços, Design de Serviços e apoiar a organização (interna e externa fornecedors) estão sujeitos a análise de risco formal e exercícios de gestão. Análise de Risco e Gestão é uma técnica que pode ser usada para identificar e quantificar os riscos e contramedidas justificáveis que podem ser implementadas para proteger a disponibilidade de sistemas de TI. A identificação dos riscos e da provisão de contramedidas justificadas para reduzir ou eliminar a ameaças colocados por esses riscos podem desempenhar um importante papel em alcançar os níveis necessários de disponibilidade para um novo ou aprimorado De serviços de TI. Análise de Risco deve ser realizada durante o projeto fase para a tecnologia de TI e de serviço para identificar: • •

Riscos que podem incorrer indisponibilidade de componentes de TI dentro da tecnologia e Design de Serviços Riscos que podem incorrer confidencialidade e / ou integridade exposições no âmbito da tecnologia de TI e Design de Serviços.

A maioria avaliação de risco e metodologias de gestão de envolver o uso de uma abordagem formal ao avaliação de risco e para a mitigação do risco posterior com a implementação de posterior custo justificável contramedidas, tal como ilustrado na Figura 4.20.

Figura 4.20 Análise e Gestão de Riscos

Análise de risco envolve a identificação e avaliação do nível (medida) de riscos calculados a partir dos valores avaliados dos ativos e os níveis avaliados de ameaças a, e vulnerabilidades de, esses ativos. Risco também é determinada em certa medida pela sua aceitação. Algumas organizações e empresas podem estar mais dispostos a aceitar o risco, enquanto outros não podem.

ITIL V3 - Service Design - Página:

215 de 477

Gestão de risco envolve a identificação, selecção e adopção de medidas defensivas justificadas pelos riscos identificados para o ativo em termos de seu potencial impacto na serviços se falha ocorre, e a redução dos referidos riscos para um nível aceitável. A gestão de riscos é um atividade que está associada com muitas outras actividades, especialmente ITSCM, Gestão de Segurança e Transição de Serviço. Todos estes exercícios de avaliação de risco devem ser coordenadas em vez de serem atividades separadas. Esta abordagem, quando aplicada através de um método formal, assegura a cobertura é completa, juntamente com toda a confiança suficiente de que: • • • • •

Todos os possíveis riscos e contramedidas foram identificados Todas as vulnerabilidades foram identificadas e os seus níveis de precisão avaliada Todas as ameaças foram identificados e os seus níveis de precisão avaliada Todos os resultados são consistentes em todo o amplo espectro da tecnologia avaliação Todas as despesas de contramedidas selecionados pode ser justificada.

Métodos formais de riscos Análise e Gestão de agora são um elemento importante na geral projeto e provisão de serviços de TI. A avaliação do risco é muitas vezes baseada na probabilidade e potencial impacto de um evento ocorrendo. Contramedidas são implementadas, onde quer que sejam economicamente justificável, para reduzir o impacto de um evento ou a probabilidade de um evento ocorrer, ou ambos. Gestão de Risco (M_o_R) fornece uma estrutura alternativa genérica para a gestão de risco em todas as partes de uma organização estratégico,programa,projeto e operacional. Ele incorpora todas as atividades necessárias para identificar e controlar a exposição a qualquer tipo de risco, Positivo ou negativo, que pode ter um impacto sobre a realização de sua organização objetivo de negócios. M_o_R fornece uma estrutura que é experimentado, testado e eficaz para ajudar a eliminar - ou gerenciar - os riscos envolvidos em alcançar seus objetivos. M_o_R adota uma aplicação sistemática de princípios, abordagem e processoes para a tarefa de identificar, avaliar e depois planejamento e implementação de respostas de risco. Orientação enfatiza uma abordagem de colaboração e incide sobre os seguintes elementos fundamentais: • • •

Desenvolvimento de um quadro que é transparente, repetível e adaptável Comunicar claramente a política e seus benefícios para todos os funcionários Nomeação indivíduos-chave na gestão sénior para 'possuir' gestão de risco iniciativas e garantir que eles se mover para frente

ITIL V3 - Service Design - Página:

216 de 477

• • • • •

Garantir a cultura se envolve com e a adequadamente consideradas de risco, incluindo a inovação Incorporação de sistemas de gestão de risco na gestão e aplicá-los de forma consistente Garantir que a gestão de risco a objetivos - em vez de vice-versa Explicitamente avaliar os riscos envolvidos no trabalho com outras organizações Adopção de uma abordagem não-culpa para monitoramento e revisão de avaliação de risco atividade.

Cronograma de testes disponibilidade Uma chave entrega do Gerenciamento de Disponibilidade processo é o "teste de disponibilidade programação '. Esta é uma agenda para o teste regular de todos os mecanismos disponibilidade. Alguns mecanismos de disponibilidade, como "balanceamento de carga", "espelhamento" e "grid computing", são usados no provisão de serviço normal no dia-a-dia, outros são usados em uma base reconfiguração fail-over ou manual. É, portanto, essencial que todos os mecanismos de disponibilidade são testadas de uma maneira regular e programada para assegurar que, quando eles são realmente necessários para real eles funcionam. Este esquema tem de ser mantido e amplamente divulgada, de modo que todas as zonas estão conscientes do seu conteúdo e de modo a que todas as outras actividades propostas pode ser sincronizado com o seu conteúdo, como por exemplo: • • • • • •

O alteração de horário Planos de lançamento e os liberar programar Todos transição planos, projetos e programas Planejadas e programações de manutenção preventiva O cronograma para testar a continuidade dos serviços de TI e recuperação planos Planos de negócios e horários.

Manutenção planejada e preventiva Todos TI componentes devem ser sujeitos a uma manutenção planejada estratégia. A frequência e nível de manutenção necessária varia de componente a componente, tendo em conta as tecnologias envolvidas, criticalidade e as vantagens comerciais potenciais que podem ser introduzidas. Atividades de manutenção planejada ativar o e de TI organização para fornecer: • • •

Manutenção preventiva para evitar falhas As atualizações planejadas de software ou hardware para oferecer novas funcionalidades ou adicional capacidade Empresas solicitado mudars para o negócio aplicaçãos

ITIL V3 - Service Design - Página:

217 de 477

•

Implementação de novas tecnologias e funcionalidade para exploração pela negócio.

O requisito para tempo de inatividade planejado claramente influencia o nível de disponibilidade que pode ser entregue por um De serviços de TI, Especialmente aqueles que têm requisitos de disponibilidade rigorosas. Ao determinar os requisitos de disponibilidade para um novo ou aprimorado de serviços de TI, o tempo de inatividade ea perda resultante de renda necessária para a manutenção planejada pode não ser aceitável para o negócio. Isto está a tornarse um problema crescente na área de 24 x 7 Operação de Serviço. Nesses casos, é essencial que operação contínua é um recurso de design de núcleo para permitir a manutenção atividade a ser realizado, sem afetar a disponibilidade dos serviços de TI. Onde as horas de serviço requeridos para os serviços de TI estão a menos de 24 horas por dia e / ou sete dias por semana, é provável que a maioria da manutenção planeada pode ser acomodada sem impactar TI disponibilidade do serviço. Todavia, quando a empresa precisa de serviços de TI disponíveis numa base de 24 horas por dia e sete dias, Gerenciamento de Disponibilidade precisa determinar a abordagem mais eficaz em equilibrar os requisitos para a manutenção planejada contra a perda de serviço para o negócio. A não ser que existem mecanismos para permitir a operação contínua, o tempo de inatividade programada para manutenção planejada é essencial se altos níveis de disponibilidade devem ser alcançados e mantidos. Para todos os serviços de TI, não deve, logicamente, ser um período de "baixo impacto" para a implementação de manutenção. Uma vez que as necessidades de gestão de manutenção programada foram definidos e acordados, estes devem ser documentados, no mínimo, em: • • • • •

SLAs OLAs Subjacente contratos Gestão da Mudança horários Lançamento de Gerenciamento de Implantação horários.

Gerenciamento de Disponibilidade deve assegurar que o edifício em manutenção preventiva é uma das principais considerações de projeto para um '24 x 7 'serviço de TI. O momento mais adequado para programar o tempo de inatividade planejado é claramente quando o impacto sobre o negócio e os seus clientes é o menor. Esta informação deve ser fornecida inicialmente pela empresa ao determinar os requisitos de disponibilidade. Para um serviço de TI existente, ou uma vez que o novo serviço Foi estabelecido, monitoramento de negócios e de clientes transaçãos ajuda a estabelecer as horas em que a utilização de serviços de TI é

ITIL V3 - Service Design - Página:

218 de 477

a mais baixa. Isto deve determinar o tempo mais apropriado para o componente(S) a ser removido para manutenção planeada atividade. Para acomodar os requisitos de componentes individuais para tempo de inatividade planejado , equilibrando o De serviços de TI requisitos de disponibilidade do negócio é uma oportunidade para considerar a manutenção de programação planejada para vários componentes simultaneamente. O benefício desta abordagem é que o número de interrupções de serviço requeridos para satisfazer os requisitos de manutenção é reduzido. Embora esta abordagem tem vantagens, existem riscos potenciais que precisam ser avaliados. Por exemplo: • • •

O capacidade do e de TI organização para coordenar a execução simultânea de um elevado número de mudars A capacidade de realizar a determinação do problema eficaz em que o serviço de TI é impactado após a conclusão das modificações múltiplas O impacto de mudança dependência em vários componentes, onde backout de uma alteração não requer mudanças múltiplas a ser removido.

A gestão eficaz de tempo de inatividade planejado é uma contribuição importante para atender os níveis exigidos de disponibilidade para um serviço de TI. Onde o tempo de inatividade planejado é necessária em uma base cíclica a um componente de TI (s), o tempo que o componente não está disponível para permitir a atividade de manutenção planejada para ser realizada deve ser definido e acordado com o interno ou externo fornecedor. Isso se torna um declarado objetivo que pode ser formalizado, medidas e registadas. Toda a manutenção planejada deve ser agendada, geridos e controlados para assegurar que os objectivos individuais e os horários não são ultraados e para garantir que as atividades são coordenadas com todos os outros horários de atividade para minimizar os confrontos e conflitos (por exemplo, mudança e liberar horários, horários de testes). Além disso, eles fornecem um alerta durante a atividade de manutenção do tempo alocado para a duração da interrupção planejada que está sendo violado. Isso pode permitir que uma decisão rápida de ser feita sobre se a atividade é permitida para completar com o potencial de impacto adicional de serviço ou para abortar a atividade e instigar a volta- plano. Tempo de inatividade planejado e atuação contra os objectivos definidos para cada componente deve ser registrada e utilizada em serviço de relatório. Produção do Serviço documento Outage Projetada (PSO) Gerenciamento de Disponibilidade deve produzir e manter a PSO documento. Este documento consiste de quaisquer variações da disponibilidade do serviço acordado no SLA. Este deve ser apresentado com base na entrada de: • •

O alteração de horário Os horários de liberação

ITIL V3 - Service Design - Página:

219 de 477

• • •

Planejadas e programações de manutenção preventiva Teste de horários disponibilidade ITSCM e Gestão de Continuidade de Negócios teste de horários.

O PSO contém detalhes de todas as paradas serviço programado e planejado dentro das horas de serviço acordados para todos os serviços. Estes documentos devem ser acordados com todas as áreas apropriadas e representantes de ambas as empresas e de TI. Uma vez que o PSO foi acordado, o Service Desk deve garantir que seja comunicada a todas as partes envolvidas para que todos estejam cientes de qualquer adicional downtime do serviço, planejado. Revisão contínua e melhoria As necessidades de negócio e demanda dos clientes pode exigir os níveis de disponibilidade previsto um serviço de TI a ser revisto. Tais revisões devem fazer parte das revisões regulares do serviço com a actividade desenvolvida pela SLM. Outra entrada também devem ser considerados em uma base regular de ITSCM, particularmente a partir da atualização Análise de Impacto no Negócio e Análise de exercícios de Risco. A criticalidade de serviços, muitas vezes, mudar e é importante que o projeto ea tecnologia de apoio a esses serviços é regularmente revisto e melhorado por gerenciamento de disponibilidade para garantir que a mudança de importância no serviço é refletida dentro de um projeto de revista e tecnologia de e. Quando os níveis exigidos de disponibilidade já estão sendo entregues, pode demorar um esforço considerável e incorrem significativa custar para atingir uma melhoria incremental pequeno dentro do nível de disponibilidade. Uma chave atividade para gerenciamento de disponibilidade é continuamente a olhar para oportunidades de otimizar o disponibilidade do Infra-estrutura de TI em conjunto com Melhoria de Serviço Continuada actividades. Os benefícios desta abordagem revisão regular são de que, às vezes, melhores níveis de disponibilidade pode ser possível, mas com custos muito mais baixos. A abordagem de otimização é um o sensato primeiro a oferecer melhores valor para o dinheiro. Uma série de técnicas de gerenciamento de disponibilidade pode ser aplicada para identificar oportunidades de otimização. Recomenda-se que o escopo não deve ser limitado à tecnologia, mas também incluem um rever de ambos os processo de negócio e outros end-to-end de negócios de propriedade responsabilidades. Para ajudar a alcançar estes objectivos, gerenciamento de disponibilidade tem de ser reconhecido como um líder influência sobre o Provedor de serviços de TI organização para assegurar foco contínuo na disponibilidade e estabilidade da tecnologia. Gerenciamento de Disponibilidade pode fornecer o e de TI organização com um negócio real e usuário perspectiva sobre como as deficiências no âmbito da tecnologia e da sustentação processo e procedimento impacto no

ITIL V3 - Service Design - Página:

220 de 477

negócio operação e, finalmente, a sua clientes. O uso de Business-Driven métricos pode demonstrar esta impacto em termos reais e, mais importante, também ajudam a quantificar os benefícios de oportunidades de melhoria. Gerenciamento de Disponibilidade podem desempenhar um importante papel em ajudar o TI provedor de serviços organização reconhecer onde ela pode agregar valor através da exploração de suas habilidades técnicas e competências em contexto disponibilidade. A técnica de melhoria contínua pode ser usado pela istração Disponibilidade para aproveitar essa técnica capacidade. Isto pode ser usado tanto com pequenos grupos de pessoal técnico ou dentro de um grupo mais amplo de uma oficina ou ambiente SFA. O ímpeto para melhorar a disponibilidade vem de um ou mais dos seguintes: • • • • • •

• •

A incapacidade de novo ou existente De serviços de TIs para cumprir as metas de SLA em uma base consistente Período (s) de TI instabilidade do serviço, resultando em níveis inaceitáveis de disponibilidade Disponibilidade tendências de medição indicando uma deterioração gradual da disponibilidade De serviços de TI inaceitável recuperação e os tempos de restauração Pedidos da empresa para aumentar o nível de disponibilidade, desde Impacto crescente na negócio e seus clientes de serviços de TI falhas, como resultado do crescimento e / ou prioridades de negócio aumento ou funcionalidade Um pedido de SLM para melhorar disponibilidade como parte de um SIP geral Monitoramento de disponibilidade e de Gestão análise de tendências.

Gerenciamento de Disponibilidade deve ter uma pró-ativa papel na identificação e progredindo economicamente justificados oportunidades de melhoria dentro da disponibilidade Plano de disponibilidade. A capacidade de fazer essa confiança lugares em ter disponibilidade de medição adequada e significativa e relatórios. Para garantir melhorias Disponibilidade trazer benefícios para o negócio e usuários, é importante que a medição e relatório reflecte não apenas de TI componente disponibilidade, mas também a disponibilidade de uma operação de negócios e usuário perspectiva. Onde a empresa tem a obrigação de melhorar a disponibilidade, o processo e as técnicas para reavaliar a tecnologia e TI provedor de serviços organização capacidade para atender a essas exigências acrescidas devem ser seguidas. Uma saída deste atividade é maior disponibilidade e critérios de projeto de recuperação. Para satisfazer o requisito de negócios para aumento dos níveis de disponibilidade pode exigir investimento financeiro adicional para melhorar a tecnologia de sustentação e / ou ampliar os serviços prestados pela organização de prestação de serviços de TI. É importante que qualquer investimento adicional para melhorar os níveis de disponibilidade entregues pode ser custo-

ITIL V3 - Service Design - Página:

221 de 477

justificado. Determinar o custo de indisponibilidade, como resultado de TI falha (s) podem ajudar a apoiar qualquer decisão de investimento financeiro na melhoria da disponibilidade

4.4.6 Triggers, entradas, saídas e interfaces Muitos eventos podem desencadear Gerenciamento de Disponibilidade atividade. Estes incluem: • • • • • • • •

•

Novos ou alterados necessidades de negócios ou serviços novos ou alterados Novas metas ou alterados dentro acordos, como SLRs, SLAs, ou OLAs contratos Serviço ou componente violações, eventos e disponibilidade alertars, incluindo limiar eventos, relatório de exceçãos Atividades periódicas, tais como a revisão, revisão ou relato Revisão de previsões de disponibilidade de Gestão, relatórios e planos Revisão e revisão de negócios e de TI planos e estratégias Revisão e revisão de projetos e estratégias O reconhecimento ou a notificação de uma mudança de risco ou o impacto de um processo de negócio ou VBF, uma De serviços de TI ou componente Pedido da SLM para assistência com metas de disponibilidade e explicação de realizações.

As principais interfaces de gerenciamento de disponibilidade que tem com outros processoes são: •

• •

•

Incidente e Gerenciamento de Problemas: Na prestação de assistência com o resolução e justificação posterior e correção de incidentes e problemas de disponibilidade Gerenciamento da Capacidade: Com o provisão de resiliência e peças sobressalentes capacidade Gerenciamento da Continuidade do Serviço: Com o avaliação dos negócios impacto e risco e provisão de resiliência, failover e mecanismos de recuperação Gerenciamento de Nível de Serviço: Assistência com a determinação de metas de disponibilidade e da investigação e resolução de falhas de serviço e componentes.

4.4.6.1 Entradas

Um certo número de fontes de informação são relevantes para o Gerenciamento de Disponibilidade processo. Alguns destes são os seguintes:

ITIL V3 - Service Design - Página:

222 de 477

•

• • • •

• •

• • •

•

•

•

Informações de negócios: De negócio da organização estratégia, Os planos e os planos financeiros e informações sobre suas necessidades atuais e futuras, incluindo os requisitos de disponibilidade para novos ou aprimorados serviços de TI Informações impacto nos negócios: De preconceitos e avaliação de VBFs apoiados por serviços de TI Análise de Risco anterior e relatórios de avaliação e um registro de riscos Informações sobre o serviço: De a Portfólio de Serviços e do Catálogo de Serviço, Informações sobre o serviço: A partir do processo de SLM, com detalhes dos serviços do portfólio de serviços e do Catálogo de Serviços,meta de nível de serviços dentro de SLAs e SLRs, e, possivelmente, a partir da monitoramento de SLAs, serviço de opiniões e violações dos SLAs Informações financeiras: De Gestão Financeira, O custar de serviço profissionalvisão, O custo de recursos e componentes Alterar e liberar informação: De a Gestão da Mudança com um processo de Alterar agendamento, A agenda de divulgação de Gerenciamento de Liberação e uma necessidade de avaliar todas as mudanças para a sua impacto da disponibilidade do serviço Gerenciamento da Configuração: Contendo informações sobre a relaçãos entre a empresa, os serviços, os serviços de apoios e a tecnologia Metas de serviço: De SLAs, SLRs, e OLAs contratos Informações de componentes: No disponibilidade, Confiabilidade e manutenção requisitos para os componentes de tecnologia que sustentam De serviços de TI(S) Tecnologia da informação: A partir do CMS sobre a topologia e as relações entre os componentes ea avaliação das capacidades da nova tecnologia ado atuação: A partir de medições anteriores, as conquistas e os relatórios e as Disponibilidade do Sistema de Informação de Gestão (AMIS) Indisponibilidade e falha informação: De incidentes e problemas.

4.4.6.2 Saídas

Os resultados produzidos pelo Gerenciamento de Disponibilidade deve incluir: • • • •

A disponibilidade do sistema de Informação de Gestão (AMIS) O Plano de disponibilidade para a melhoria pró-ativo de serviços de TI e de tecnologia Disponibilidade e recuperação critérios de projeto e metas propostas para serviços novos ou alterados serviços Disponibilidade do serviço, confiança e relatórios de manutenção de conquistas contra alvos, incluindo a entrada de todos os relatórios de serviços

ITIL V3 - Service Design - Página:

223 de 477

• • •

• • • •

•

Disponibilidade de componentes, confiabilidade e facilidade de manutenção relatos de conquistas contra alvos Opiniões de risco revistas e relatórios de análise e um registro de riscos atualizados Gestão, acompanhamento e elaboração de relatórios requisitos para serviços de TI e componentes para garantir que desvios na confiabilidade, disponibilidade e facilidade de manutenção são detectados, acionadas, registo e divulgação Um Disponibilidade cronograma de testes de Gestão para testar toda a disponibilidade, resiliência e mecanismos de recuperação Os planejadas e programações de manutenção preventiva A interrupção do serviço Projetada (PSO) em conjunto com Mudança e Gerenciamento de Liberação Detalhes das técnicas disponibilidade proativas e medidas que serão implantadas para proporcionar resistência adicional para evitar ou minimizar o impacto das falhas de componentes sobre a disponibilidade de serviços de TI Ações de melhoria para a inclusão dentro da SIP.

4.4.7 Indicadores Chave de Desempenho KPIs muitos podem ser utilizados para medir a eficácia e eficiência de gerenciamento de disponibilidade, incluindo os seguintes exemplos: Gerir a disponibilidade e confiabilidade dos serviços de TI: • • • • • • • •

Redução percentual da indisponibilidade de serviços e componentes Aumento percentual na fiabilidade dos serviços e componentes Eficaz de revisão e acompanhamento de todos os SLA, OLA e subjacente contrato violações O percentual de melhoria em geral fim-de-final disponibilidade de serviço Redução percentual no número e impacto das quebras de serviço Melhoria no MTBF (Tempo médio entre falhas) Melhoria da TMEIS (Tempo Médio Entre Incidentes Sistemas) Redução dos MTRS (Tempo médio para restaurar o serviço).

Satisfazer as necessidades de negócios para o o aos serviços de TI: • • •

•

Percentagem de redução a indisponibilidade de serviços Percentagem de redução do custar de horas extras de negócios devido à indisponibilidade de TI Redução percentual em falhas de tempo críticos, por exemplo, pico de negócio e as necessidades de disponibilidade prioritárias estão previstas para O percentual de melhoria nos negócios e usuários satisfeito com o serviço (por resultados CSS).

ITIL V3 - Service Design - Página:

224 de 477

Disponibilidade de infraestrutura de TI realizados a custos ótimos: • • • • • • • • • •

Percentagem de redução do custo de indisponibilidade O percentual de melhoria nos custos de entrega de serviços Conclusão oportuna de Análise de Risco regular e sistema rever Conclusão oportuna de análise custo-benefício regularmente estabelecida para infra-estrutura Componente Análise de Impacto falha (CFIA) Percentagem de redução falhas de terceiros atuação em MTRS / MTBF contra alvos de contrato Redução do tempo necessário para completar (ou atualização) a Análise de Risco Redução do tempo necessário para avaliar a resiliência do sistema Redução do tempo necessário para completar um Plano de disponibilidade Produção atempada de relatórios de gestão Percentagem de redução da incidência de operacional opiniões descobrindo segurança e confiança exposições em projetos de aplicação.

4.4.8 Gestão da Informação O Gerenciamento de Disponibilidade processo deve manter uma AMIS que contém todas as medidas e as informações necessárias para concluir o gerenciamento de disponibilidade processo e fornecer a informação adequada à negócio sobre o nível de serviço prestado TI. Esta informação, que abrange serviços, componentes e serviços de apoios, fornece a base para regular, ad hoc e relatórios de exceção disponibilidade e identificação de tendências nos dados para a instigação de atividades de melhoria. Essas atividades e as informações contidas nas AMIS fornecem a base para o desenvolvimento do conteúdo do Plano de Disponibilidade. A fim de proporcionar estrutura e foco para uma ampla gama de iniciativas que podem ter de ser tomadas para melhorar disponibilidade, Um plano de disponibilidade devem ser formuladas e mantida. O Plano de Disponibilidade deve ter objectivos, objetivos e entregas e deve considerar as questões mais amplas de pessoas, processos, ferramentas e técnicas, bem como ter um foco de tecnologia. Nas fases iniciais, pode ser alinhada com uma implementação plano para gerenciamento de disponibilidade, mas os dois são diferentes e não devem ser confundidas. Como o processo de Gerenciamento de Disponibilidade amadurece, o plano deve evoluir para cobrir o seguinte: •

•

Níveis reais de disponibilidade contra concordaram níveis de disponibilidade para a chave De serviços de TIs. Medições de disponibilidade deve ser sempre de negócios e foco no cliente e disponibilidade relatório vivida pela empresa e usuários. Atividades que estão sendo progrediu para solucionar as carências de disponibilidade para os actuais serviços de TI. Onde as decisões de

ITIL V3 - Service Design - Página:

225 de 477

•

•

• •

•

investimento são necessários, opções com associados custars e os benefícios devem ser incluídos. Informações sobre como alterar os requisitos de disponibilidade para os serviços de TI existentes. O plano deve documentar as opções disponíveis para atender a esses requisitos alterados. Onde as decisões de investimento são necessários, os custos associados de cada opção deve ser incluído. Detalhes dos requisitos de disponibilidade para futuros novos serviços de TI. O plano deve documentar as opções disponíveis para atender a essas novas exigências. Onde as decisões de investimento são necessários, os custos associados de cada opção deve ser incluído. Uma programação voltada para o futuro para as atribuições SFA planejadas. Revisões regulares de atribuições SFA devem ser cumpridos para garantir que a disponibilidade de tecnologia está sendo melhorada de forma proativa em conjunto com a SIP. Uma tecnologia seção futuros para fornecer uma indicação dos potenciais benefícios e oportunidades de exploração que existem para atualizações tecnológicas planejadas. Benefícios de disponibilidade antecipados devem ser detalhados, sempre que possível com base em medidas de negócios focados, em conjunto com Gerenciamento da Capacidade. O esforço necessário para obter esses benefícios sempre que possível também devem ser quantificados.

Durante a produção do Plano de disponibilidade, Recomenda-se que a ligação com todos os domínios funcionais, técnicas e processo é realizado. O Plano de Disponibilidade deve cobrir um período de um a dois anos, com uma visão mais detalhada e informações para os primeiros seis meses. O plano deve ser revista regularmente, com re menorvisãos cada trimestre e re maiorvisãos cada semestre. Em que a tecnologia só é submetida a um baixo nível de alteração, isto pode ser estendido, conforme apropriado. Recomenda-se que o plano de Disponibilidade é considerada complementar à Plano de capacidade e Plano Financeiro, e que a publicação está alinhada com a capacidade e de negócios orçamentação ciclo. Se um pedido for previsto para elevados níveis de disponibilidade que não podem ser satisfeitas devido às limitações do actual Infra-estrutura de TI ou orçamento, Então relatório de exceçãos podem ser necessários para a atenção tanto de TI sênior e gestão de negócios. A fim de facilitar a produção do Plano de disponibilidade, Gerenciamento de Disponibilidade pode querer considerar ter seu repositório próprio banco de dados. Os AMIS pode ser utilizado para gravar e armazenar dados selecionados e informações necessárias para apoiar as atividades-chave, como a geração de relatórios, análise estatística e previsão de disponibilidade e planejamento. Os AMIS deve ser o repositório principal para a gravação de TI disponibilidade

ITIL V3 - Service Design - Página:

226 de 477

métricos, medidas, metas e documentos, incluindo o Plano de Disponibilidade, medições de disponibilidade, relatórios de realização, relatórios de atribuição SFA, critérios de projeto, planos de ação e horários de ensaio. Ser pragmático, definir os requisitos das ferramentas iniciais e identificar o que já está implantado, que pode ser usado e compartilhado para começar o mais rápido possível. Quando as ferramentas básicas não estão já disponíveis, trabalhar com o outro De serviços de TI e gerenciamento de sistemas processoes para identificar as necessidades comuns com o objetivo de selecionar ferramentas compartilhadas e minimizando custars. Os AMIS deve abordar as necessidades de relatórios específicos de Gerenciamento de Disponibilidade não assegurada por repositórios existentes e integrar com eles e seus conteúdos.

4.4.9 Desafios, Fatores Críticos de Sucesso e riscos Gerenciamento de Disponibilidade enfrenta muitos desafios, mas, provavelmente, o principal desafio é, na verdade, atender as expectativas do clientes, o negócio e gerência sênior. Estas expectativas são de que os serviços estarão sempre disponíveis e não apenas durante a sua concordou serviço horas, mas que todos os serviços estarão disponíveis 24 horas por dia, base de 365 dias. Quando não são, supõe-se que sejam recuperados em poucos minutos. Este é o caso apenas quando o nível apropriado de investimento e design tem sido aplicadas para o serviço, e isso só deve ser feita quando o negócio impacto justifica que o nível de investimento. No entanto, a mensagem precisa ser divulgado para todos os clientes e áreas de negócio, de modo que, quando os serviços falham têm o nível certo de expectativa sobre a sua recuperação. Isso também significa que Gerenciamento de Disponibilidade deve ter o a um nível adequado de informação de qualidade sobre a necessidade do negócio atual para os serviços de TI e seus planos para o futuro. Este é outro desafio enfrentado por muitos processos de Gerenciamento de Disponibilidade. Outro desafio de gerenciamento de disponibilidade é a integração de todos os dados de disponibilidade em um conjunto integrado de informações (AMIS) que pode ser analisado de uma forma consistente para fornecer informações sobre a disponibilidade de todos os serviços e componentes. Isto é particularmente desafiador quando as informações das diferentes tecnologias é geralmente fornecida por diferentes ferramentas em diferentes formatos. No entanto, outro desafio de gerenciamento de disponibilidade é convencer o negócio e gerência sênior do investimento necessário em medidas proativas disponibilidade. Investimento é sempre reconhecido uma vez falhas ter ocorrido, mas aí já é realmente tarde demais. Persuadir empresas e clientes a investir em resiliência para evitar a possibilidade de falhas que podem acontecer é um desafio difícil. Gerenciamento de Disponibilidade deve trabalhar em estreita

ITIL V3 - Service Design - Página:

227 de 477

colaboração com Gestão da Continuidade do Serviço,Gestão de Segurança e Gestão de capacidade em produzir as justificativas necessárias para assegurar o investimento necessário. Os QCA principais para o processo de gerenciamento de disponibilidade são: • • •

Gerir disponibilidade e confiança de serviço de TI Satisfazer as necessidades de negócios para o o ao De serviços de TIs Disponibilidade de Infra-estrutura de TI, Como documentado em SLAs, desde a custos otimizados.

Alguns dos principais riscos associados Gerenciamento de Disponibilidade incluem: • • • • • •

A falta de compromisso do negócio para o processo de Gerenciamento de Disponibilidade A falta de compromisso do negócio e uma falta de informação adequada sobre os planos e estratégias futuras A falta de compromisso da alta istração ou a falta de recursos e / ou orçamento para o Gerenciamento de Disponibilidade processo Os processos de comunicação tornam-se muito de trabalho intensivo Os processos se concentrar demais na tecnologia e não o suficiente sobre os serviços e as necessidades do negócio A informação de gerenciamento de disponibilidade (AMIS) é mantido em isolamento e não é compartilhada ou consistente com outras áreas de processo, especialmente ITSCM, Gestão de Segurança e Gerenciamento da Capacidade. Este investimento é particularmente importante quando se considera o serviço necessário e componente apoio e ferramentas de recuperação, tecnologia e processos para atender as necessidades acordadas.

ITIL V3 - Service Design - Página:

228 de 477

4,5 Gerenciamento de Continuidade do Serviço 4.5.1 Finalidade objetivo / / objetivo 'O objectivo da ITSCM consiste em apoiar o conjunto Gestão de Continuidade de Negócios processo, garantindo que as instalações de TI necessários técnicos e de serviços (incluindo sistemas de computadores, redes, aplicaçãos, repositórios de dados, telecomunicações, ambiente,e técnico e Service Desk) pode ser retomado dentro necessário e acordado, prazos de negócio. "

Como a tecnologia é um núcleo componente mais de processo de negócioes, continuado ou alta disponibilidade de TI é crítica para a sobrevivência do negócio como um todo. Isto é conseguido através da introdução de medidas de redução de risco e opção de recuperaçãos. Como todos os elementos de ITSM, a implementação bem sucedida de ITSCM só pode ser alcançada com o compromisso da alta istração e ao apoio de todos os membros da organização. Manutenção contínua da recuperação capacidade é essencial para que possa manter a sua eficácia. O objetivo do GCSTI é manter a capacidade de recuperação necessário em curso no âmbito dos serviços de TI e de seus componentes de apoio. O objetivos de ITSCM são os seguintes: •

•

•

• •

• •

•

Manter um conjunto de TI Plano de Continuidade do Serviços de TI e planos de recuperação que am o geral Plano de Continuidade de Negócioss (PCN) da organização Completa regulares Análise de Impacto no Negócio (BIA) exerce a assegurar que todos os planos de continuidade são mantidos em conformidade com os impactos de mudança da empresa e os requisitos Realizar Análise de Risco regular e exercícios de gestão, particularmente em conjunto com a empresa eo Gerenciamento de Disponibilidade e Gestão de Segurança processos, que gerenciar serviços de TI dentro de um nível acordado de negócios risco Prestar assessoria e orientação para todas as outras áreas de negócio e de TI em todas as questões de continuidade e recuperação relacionados Certifique-se que a continuidade adequada e mecanismos de recuperação são postas em prática para atender ou exceder as metas de continuidade de negócios acordados Avaliar a impacto de todos mudars sobre os Planos de Continuidade de Serviço de TI e planos de recuperação de TI Assegurar que as medidas pró-ativas para melhorar a disponibilidade de serviços são implementados onde quer que seja de custo justificável para fazê-lo Negociar e acordar o necessário contratos com fornecedors para o provisão da recuperação necessário capacidade para ar todos os planos de continuidade em conjunto com o Gestão de Fornecedores processo.

ITIL V3 - Service Design - Página:

229 de 477

4.5.2 Âmbito ITSCM incide sobre os eventos que o negócio considera significativo o suficiente para ser considerado um desastre. Eventos menos importantes serão tratados como parte da Gerenciamento de Incidentes processo. O que constitui um desastre varia de organização para organização. O impacto de uma perda de um processo de negócio, tais como perdas financeiras, danos à reputação ou violação de regulamentação, é medida através de um exercício BIA, que determina os requisitos mínimos críticos. O técnico de TI específicas e necessidades de serviço são ados por GCSTI. O escopo do GCSTI dentro de uma organização é determinada pela estrutura organizacional, cultura e estratégico direção (de negócios e tecnologia) em termos dos serviços prestados e como eles se desenvolvem e mudam ao longo do tempo. ITSCM principalmente considera a TI ativoss e configurações que am o processo de negócioes. Se (após um desastre) é necessário se mudar para um local alternativo de trabalho, provisão também será necessária para itens como escritório e alojamento de pessoal, cópias de papel crítico registros, de courier serviços e instalações de telefone para se comunicar com clientes e terceiros. O escopo terá de ter em conta o número ea localização dos escritórios da organização e os serviços realizados em cada um. ITSCM não costuma diretamente cobrir os riscos de longo prazo, como os de mudanças na direção dos negócios, diversificação, reestruturação, grande concorrente falha, E assim por diante. Enquanto esses riscos podem ter um impacto significativo sobre os elementos de serviços de TI e os mecanismos de continuidade, geralmente há tempo para identificar e avaliar o risco e incluir mitigação de riscos por meio de alterações ou mudanças nos negócios e estratégias de TI, tornando-se assim parte do negócio global e TI Gestão da Mudança programa. Da mesma forma, ITSCM geral, não cobrem pequenas falhas técnicas (por exemplo, falha do disco não crítico), a menos que haja uma possibilidade de que o impacto pode ter um grande impacto sobre o negócio. Estes riscos seria de esperar para ser coberto principalmente por meio da Central de Serviços e do processo de Gerenciamento de Incidentes, ou resolvidos através do planejamento associado ao processoes de Gerenciamento de Disponibilidade,Gerenciamento de Problemas, Gestão da Mudança, Gerenciamento da Configuração e 'business as usual' operacional gestão. O processo ITSCM inclui: • •

O acordo do escopo do processo ITSCM e as políticas adotadas. Business Impact Analysis (BIA) para quantificar a impacto perda de serviços de TI teria sobre o negócio.

ITIL V3 - Service Design - Página:

230 de 477

•

•

• • •

Análise de Risco (RA) - a identificação de riscos e avaliação de risco para identificar possíveis ameaças à continuidade e à probabilidade de as ameaças se tornem realidade. Isto também inclui a tomada de medidas para gerir o identificado ameaças onde isso pode ser custo-justificado. Produção de um total ITSCM estratégia que deve ser integrado na estratégia de BCM. Este pode ser produzido seguindo os dois os acima identificados, e é provável que incluem elementos de redução de risco, bem como seleção de opções de recuperação adequadas e abrangentes. Produção de um plano de ITSCM, que novamente deve ser integrado com os planos de BCM geral. Teste dos planos. Contínuo operação e manutenção dos planos.

4.5.3 Valor para o negócio ITSCM fornece uma valiosa papel no apoio ao processo de negócio Planejamento da Continuidade. Em muitas organizações, ITSCM é usado para aumentar a consciência da continuidade e recuperação requisitos e é muitas vezes usado para justificar e implementar um processo de Planejamento de Negócios e Continuidade Plano de Continuidade de Negócioss. O ITSCM deve ser impulsionada por negócios risco como identificado pelo Planejamento de Continuidade de Negócios, e assegura que o regime de recuperação para De serviços de TIs estão alinhados aos impactos, riscos de negócio identificados e necessidades.

4.5.4 Políticas / princípios / conceitos básicos Uma abordagem de ciclo de vida devem ser adotados para a criação e operação de um processo GCSTI. Figura 4.21 apresenta o ciclo de vida do GCSTI, desde a iniciação até a garantia contínua que a proteção oferecida pelo plano é atual e reflete tudo mudars para os serviços e nível de serviços. ITSCM é um processo cíclico através do ciclo de vida de garantir que, uma vez serviço planos de continuidade e recuperação foram desenvolvidos são mantidos alinhados com Planos de Continuidade de Negócios (PCN) e as prioridades de negócios. Figura 4.21 também mostra a papel jogado dentro do processo ITSCM do BCM.

ITIL V3 - Service Design - Página:

231 de 477

Figura 4.21 Ciclo de Vida da Gestão da Continuidade do Serviço

Etapas de iniciação e os requisitos são atividades principalmente BCM. ITSCM só deve ser envolvida nestes estágios para apoiar as atividades de GCN e compreender a relação entre os processos de negócios e os impactos causados sobre eles pela perda de serviços de TI. Como resultado destes BIA inicial e atividades de análise de risco, BCM deve produzir uma Estratégia de Continuidade de Negócios, ea tarefa ITSCM primeira real é produzir uma estratégia ITSCM que sustenta o BCM estratégia e suas necessidades. A Estratégia de Continuidade de Negócio deve focar principalmente processo de negócioes e problemas associados (por exemplo, a continuidade de processos de negócios, a continuidade do pessoal, a continuidade edifícios). Uma vez que a Estratégia de Continuidade de Negócios tem sido produzido, ea papel que os serviços de TI tem de fornecer dentro da estratégia foi determinada, uma ITSCM estratégia pode ser produzido que apoia e permite a Estratégia de Continuidade de Negócios. Isso garante que as decisões de custo-benefício pode ser feita, considerando todos os "recursos" para entregar um processo de negócio. Não fazer isso tende a encorajar opções ITSCM que são mais rápidos, mais elaborado e caro do que são realmente necessários. As actividades a serem tidos em conta durante a iniciação depende da extensão em que as instalações de continuidade foram aplicadas dentro do organização. Algumas partes do negócio podem ter estabelecido indivíduo Plano de Continuidade de Negócioss em torno de manuais soluções alternativas, e ele pode ter desenvolvido planos de continuidade para sistemas que são vistos como críticos. Isto é bom para a entrada processo. No entanto, ITSCM eficaz depende de apoio funções críticas de negócios. A única maneira de implementar ITSCM eficaz é através da identificação de processos críticos de negócios ea análise e coordenação da tecnologia necessária e apoiar serviços de TI.

ITIL V3 - Service Design - Página:

232 de 477

Esta situação pode ser ainda mais complicada em terceirização situações em que um processo dentro de uma ITSCM prestador de serviços externo contratante ou organização tem que atender as necessidades não só do processo de BCM cliente e estratégia, mas também do processo o contratante do BCM próprio e estratégia. Estas necessidades podem estar em conflito um com o outro, ou pode entrar em conflito com as necessidades do BCM de uma da outra terceirização organização clientes. No entanto, em muitas organizações BCM está ausente ou tem um foco muito pequeno, e muitas vezes ITSCM é necessário para cumprir muitos dos requisitos e atividades do BCM. O restante desta seção assumiu que ITSCM teve que realizar muitas das atividades exigidas pelo BCM. Se um processo de BCM é estabelecida com Estratégias e Planos de Continuidade de Negócios no lugar, esses documentos devem fornecer o foco e unidade para estabelecer GCSTI.

4.5.5 as atividades de processo, métodos e técnicas As seções a seguir contêm detalhes de cada uma das fases do ciclo de vida dentro GCSTI. 4.5.5.1 Fase 1 - Iniciação

O processo de iniciação abrange toda a organização e é composto das seguintes atividades: •

•

•

Definição de política - Este deve ser criado e comunicado o mais breve possível de modo a que todos os membros da organização envolvido, ou afectados por problemas de continuidade de negócios estão cientes de suas responsabilidades para cumprir e apoiar GCSTI. No mínimo, a política deve definir a intenção da istração e objetivos. Especificar termos de referência e âmbito - o que inclui a definição do escopo e as responsabilidades de todos os funcionários na organização. Ela abrange tarefas como realizar uma Análise de Risco e Análise de Impacto no Negócio e determinação da estrutura de comando e controle necessários para ar uma interrupção de negócios. Há também uma necessidade de ter em conta questões como pontos de auditoria pendentes, regulamentares ou cliente exigências e determinações da organização de seguros e observância com normas como a ISO 27001, a Padrão em Gestão de Segurança da Informação, Que também trata dos requisitos de continuidade de serviço. Distribuir recursos - O estabelecimento de um efetivo de Continuidade de Negócios ambiente requer recursos consideráveis em termos de dinheiro e mão de obra. Dependendo da maturidade da organização, no que diz respeito ao GCSTI, pode haver uma exigência para familiarizar e / ou o pessoal de bordo para realizar a Fase 2 tarefas. Em alternativa, a

ITIL V3 - Service Design - Página:

233 de 477

•

•

utilização de consultores externos experientes podem ajudar na conclusão da análise mais rapidamente. No entanto, é importante que o organização pode então manter o processo vai para a frente sem a necessidade de confiar totalmente em apoio externo. Definir a organização do projeto e estrutura de controle - ITSCM e BCM projetos são potencialmente complexa e precisa ser bem organizado e controlado. É altamente aconselhável a utilização de um reconhecido padrão de metodologia de planejamento de projeto, tais como projetos em um ambiente controlado (PRINCE2®) ou Projeto Management Body Of Knowledge (PMBOK®). Concordo planos de projeto e de qualidade - Os planos de permitir que o projeto a ser controlado e variaçãos abordadas. Planos de qualidade garantir que o entregas são alcançados e para um nível aceitável de qualidade. Eles também fornecem um mecanismo para comunicar os requisitos do projeto de recursos e resultados, obtendo assim "buy-in" de todas as partes necessárias.

4.5.5.2 Fase 2 - Requisitos e estratégia

Determinar os requisitos de negócio para De serviços de TI continuidade é um componente crítico para determinar o quão bem uma organização irá sobreviver a uma interrupção de negócios ou desastre eo custars que serão incorridas. Se a análise de requisitos é incorreta, ou informações chave foi perdida, isso pode ter conseqüências graves sobre a eficácia de mecanismos GCSTI. Esta fase pode efetivamente ser dividido em duas seções: • •

Requisitos - Executar Análise de Impacto no Negócio e avaliação de risco Estratégia - Após a análise de requisitos, a estratégia deve documentar as medidas de redução de risco e necessários opção de recuperaçãos para ar o negócio.

Requisitos - Business Impact Analysis

O objetivo de uma Análise de Impacto nos Negócios (BIA) é quantificar o impacto ao negócio que a perda de serviço teria. Esse impacto pode ser um impacto "duro" que podem ser identificados com precisão - como perda financeira - ou impacto "suave" - tais como relações públicas, saúde, moral e segurança ou perda de vantagem competitiva. A BIA vai identificar os serviços mais importantes para a organização e, portanto, ser um contributo essencial para a estratégia. A BIA identifica: •

A forma que o dano ou a perda pode tomar - por exemplo: • Renda perdida

ITIL V3 - Service Design - Página:

234 de 477

• • • • • • • • •

•

•

• • •

Os custos adicionais Reputação danificada Perda de boa vontade Perda de vantagem competitiva Violação da lei de saúde e segurança Risco para a segurança pessoal Perda imediata e de longo prazo de quota de mercado Embaraço político, empresarial ou pessoal Perda de operacional capacidade - Por exemplo, em um comando e controle ambiente Como o grau de dano ou a perda é provável escalar após um serviço interrupção, e os momentos do dia, semana, mês ou ano, quando a interrupção será mais severo O pessoal, habilidades, instalações e serviços (incluindo os serviços de TI) necessários para permitir crítica e essencial processo de negócioes de continuar operando em um nível mínimo aceitável O tempo em que os níveis mínimos de pessoal, instalações e serviços devem ser recuperados O tempo em que todos os processos de negócios necessários e pessoal de apoio, instalações e serviços devem ser totalmente recuperada A recuperação de empresas em relação prioridade para cada um dos De serviços de TIs.

Um dos principais resultados de um exercício de BIA é um gráfico da actividade impacto esperado causado pela perda de um processo comercial, ou a perda de um serviço de TI ao longo do tempo, tal como ilustrado na Figura 4.22.

Figura 4.22 Representação gráfica de impactos nos negócios

ITIL V3 - Service Design - Página:

235 de 477

Este gráfico pode então ser usada para impulsionar os negócios e as estratégias de TI e planos de continuidade. Medidas mais preventivas precisam ser adotadas com relação àqueles processoes e serviços com impactos anteriores e superiores, enquanto que maior ênfase deve ser colocada na continuidade e medidas de recuperação para aqueles onde o impacto é menor e leva mais tempo para se desenvolver. Uma abordagem equilibrada de ambas as medidas devem ser adotadas para aqueles no meio. Esses itens fornecem os drivers para o nível dos mecanismos de ITSCM que precisam ser considerados ou implantado. Uma vez apresentadas as seguintes opções, o negócio pode decidir que os níveis mais baixos de serviço ou atrasos maiores são mais aceitáveis, com base numa análise custo-benefício, Ou talvez que medidas gerais de prevenção de desastres terão de ser implementadas. Estes avaliaçãos permitir o mapeamento de crítica de serviços de aplicação e tecnologia componentes a crítica processo de negócioes, ajudando a identificar os elementos ITSCM que precisam ser fornecidos. Os requisitos de negócio são classificados e os elementos associados ITSCM confirmado e priorizados em termos de redução de riscos e recuperação planejamento. Os resultados da BIA, discutido anteriormente, são de entrada de valor inestimável para diversas áreas do desenho do processo, incluindo Gerenciamento de Nível de Serviço para compreender o requerido nível de serviços. Impactos devem ser medidos contra cenários específicos para cada processo de negócio, tais como a incapacidade de liquidação de operações no mercado monetário de um processo de negociar, ou à impossibilidade de nota fiscal por um período de dias. Um exemplo é um ambiente de mercado monetário lidar onde a perda de informações de dados de mercado poderia significar que a organização começa a perder dinheiro imediatamente como o comércio não pode continuar. Além disso, clientes pode ir para outra organização, o que significaria a perda de potencial de negócio. Perda do sistema de liquidação não impede comércio de acontecer, mas se ofícios já realizadas não pode ser resolvido dentro de um determinado período de tempo, a organização pode estar em violação das regras de regulação ou períodos de liquidação e sofrer multas e reputação danificada. Isto pode realmente ser a mais significativa impacto do que a incapacidade para o comércio devido a uma incapacidade de satisfazer as expectativas dos clientes. Também é importante compreender como os impactos podem mudar ao longo do tempo. Por exemplo, pode ser possível para uma empresa para funcionar sem uma especial processo por um período de tempo curto. Em um cenário equilibrado, os impactos para o negócio irá ocorrer e se tornar maior com o tempo. No entanto, nem todos organizaçãos são afectados deste modo. Em algumas organizações, os impactos não são aparentes imediatamente. Em algum ponto, no entanto, para qualquer organização, os impactos serão acumulados para um nível tal que a empresa não pode mais operar. ITSCM

ITIL V3 - Service Design - Página:

236 de 477

garante que as opções de contingência são identificados de forma que a medida adequada pode ser aplicado no momento adequado para manter os impactos de negócios de interrupção do serviço para um nível mínimo. Ao conduzir uma BIA, é importante que os pontos de vista representantes seniores superfícies »são procurados na perda de impacto seguinte de serviço. É igualmente importante que os pontos de vista dos quadros e pessoal mais júnior são procurados para garantir que todos os aspectos do impacto após a perda de serviço são apuradas. Muitas vezes, os diferentes níveis de pessoal terão diferentes pontos de vista sobre o impacto, e todos têm de ser tidas em conta quando se produz a global estratégia. Em muitas organizações, será impossível, ou não vai ser custo-justificável, para recuperar o total do serviço em um prazo muito curto. Em muitos casos, os processos de negócios pode ser re-estabelecida sem um complemento total de pessoal, sistemas e outras instalações, e ainda manter um nível aceitável de serviço para clientes e clientes. A recuperação de empresas objetivos deve ser definida em termos de: • •

O tempo em que uma equipe pré-definido de núcleo de pessoal e instalações mínimas indicadas devem ser recuperados O calendário para a recuperação do restante pessoal e instalações.

Ela pode não ser sempre possível fornecer os requisitos de recuperação para um nível mais detalhado. Há uma necessidade para equilibrar o potencial impacto contra o custar de recuperação para assegurar que os custos são aceitáveis. Os objetivos de recuperação que, no entanto, fornecer um ponto de partida para a recuperação de negócio diferente e opções ITSCM pode ser avaliada. Requisitos - Análise de Risco

O segundo motorista na determinação dos requisitos ITSCM é a probabilidade de que um desastre ou interrupção do serviço outro grave irá ocorrer. Trata-se de um avaliação do nível de ameaça e a medida em que uma organização que é vulnerável a ameaça. Análise de risco pode também ser utilizado na avaliação e reduzindo a probabilidade de incidentes operacionais normais e é uma técnica utilizada pela Gerenciamento de Disponibilidade para garantir a disponibilidade necessária e confiança níveis pode ser mantida. Análise de Risco é também um aspecto fundamental do Gestão de Segurança da Informação. Um diagrama de Análise e Gestão de Riscos (Figura 4.20) está contido dentro do processo de gerenciamento de disponibilidade na secção 4.4. Um número de Análise de Risco e métodos de gestão estão disponíveis para ambos os setores comerciais e governamentais. Análise de Risco é a avaliação dos riscos que podem dar origem a interrupção do serviço ou segurança violação. Gestão de risco está preocupado com a identificação de respostas de ITIL V3 - Service Design - Página:

237 de 477

risco adequada relação custo-justificáveis contramedidapara combater esses riscos. Uma metodologia padrão, tal como o Gestão de Risco (M_o_R), deve ser usado para avaliar e gerir os riscos dentro de uma organização. O quadro M_o_R é ilustrado na Figura 4.23.

Figura 4.23 Gestão de Risco

A abordagem M_o_R é baseado em torno do quadro acima, que consiste no seguinte: •

•

Princípios M_o_R: Estes princípios são essenciais para o desenvolvimento de boas gestão de risco prática e são derivados a partir de empresas governo princípios. Abordagem M_o_R: An organizaçãoA abordagem a estes princípios precisa ser acordado e definido dentro dos seguintes documentos vivos: • Gestão de Risco Política • Guia de processo • Planos • risco registra

ITIL V3 - Service Design - Página:

238 de 477

•

•

•

•

Logs questão. Processos M_o_R: Os quatro os seguintes descrevem os principais insumos, produtos e atividades que garantam que os riscos são controlados: • Identificar: O ameaças e oportunidades dentro de uma atividade que poderiam afetar a capacidade de atingir o seu objetivo • Avaliar: A compreensão do efeito líquido das ameaças identificadas e oportunidades associadas com uma atividade quando agregadas • Plano: Preparar uma resposta específica de gestão que irá reduzir as ameaças e maximizar as oportunidades • Executar: A planeada gestão de risco acções, acompanhar a sua eficácia e tomar ações corretivas em que as respostas não correspondem às expectativas. Incorporação e revisão M_o_R: Ter colocado os princípios da abordagem, e processoes no lugar, eles precisam ser continuamente revistos e melhorados para garantir que eles permanecem eficazes. Comunicação: Ter as atividades de comunicação adequada para garantir que todos estejam manter-se atualizado com as mudanças na ameaças, oportunidades e quaisquer outros aspectos gestão de risco.

Este método M_o_R requer a avaliação de riscos ea desenvolvimento de um perfil de risco, tal como no exemplo da Figura 4.24.

ITIL V3 - Service Design - Página:

239 de 477

Figura 4.24 Exemplo perfil de risco resumo

Figura 4.24 apresenta um perfil de risco exemplo, contendo muitos riscos que estão fora do nível definido de "aceitável risco'. Após a análise de risco é possível determinar as respostas adequadas de risco ou medidas de redução de risco (mecanismos ITSCM) para gerenciar os riscos, ou seja, reduzir o risco a um nível aceitável ou mitigar o risco. Sempre que possível, as respostas de risco adequados devem ser implementados para reduzir tanto o impacto ou a probabilidade, ou de ambos, desses riscos de se manifestarem. No contexto da ITSCM, há um certo número de riscos que precisam de ser tomadas em consideração. O seguinte não é uma lista exaustiva, mas dá alguns exemplos de riscos e ameaças que precisam ser abordadas pelo ITSCM processo.

ITIL V3 - Service Design - Página:

240 de 477

Risco

Ameaça

Perda de sistemas internos de TI / redes, PABX, DACs, etc

Fogo Falha de energia Arson e vandalismo Inundação Impacto do avião Danos do tempo, por exemplo, furacão Desastre ambiental Ataque terrorista Sabotar Falha catastrófica Danos elétricos, por exemplo, relâmpago Danos acidentais Má qualidade de software

Perda de externas sistemas de TI / redes, por exemplo, e-commerce servidors, sistemas criptográficos

Todo o acima Excesso de demanda por serviços Ataque de negação de serviço, por exemplo, contra um firewall de Internet Tecnologia falha, E.g. sistema criptográfico

Perda de dados

Falha de tecnologia Humano erro Vírus, software malicioso, por exemplo applets ataque

Perda de serviços de rede

Danos ou recusa de o às instalações de rede do provedor de serviços Perda de provedor de serviços de TI de sistemas / redes Perda de dados prestador de serviços A falha do provedor de serviços

Indisponibilidade de pessoal técnico e de apoio fundamental

Ação industrial Recusa de o às instalações Renúncia Doença / lesão Dificuldades de transporte

Falha de prestadores de serviços, por exemplo, terceirizados de TI

Fracasso comercial, por exemplo, insolvência Recusa de o às instalações Indisponibilidade de pessoal prestador de serviços O não cumprimento contratual nível de serviços

Tabela 4.1 Exemplos de riscos e ameaças

ITIL V3 - Service Design - Página:

241 de 477

Estratégia de TI da Continuidade do Serviço

Os resultados da Análise de Impacto no Negócio e da Análise de Risco permitirá Negócios apropriado e estratégias de TI de continuidade de serviços a serem produzidos em linha com as necessidades do negócio. O estratégia será um equilíbrio ideal de redução de riscos e recuperação ou opções de continuidade. Isso inclui a consideração da relação serviço prioridades de recuperação e as mudanças na prioridade de serviço relativa para a hora do dia, dia da semana, e as variações mensal e anual. Esses serviços que foram identificados como grandes impactos no curto prazo dentro da BIA vai querer concentrar esforços na redução métodos de prevenção de risco - por exemplo, através da plena resiliência e culpa tolerância - enquanto um organização que tem baixos impactos de curto prazo seria melhor se adequa às opções de recuperação global, conforme descrito nas seções seguintes. Aconselhamento e orientação semelhante pode ser encontrada no BCI a Continuidade de Negócios Instituto Guia de Boas Práticas. Resposta medidas de risco

A maioria das organizações terão que adotar uma abordagem equilibrada em que a redução de riscos e de recuperação são complementares e ambas são necessárias. Isto implica a redução, na medida do possível, os riscos para o pro continuadavisão do serviço de TI e é geralmente obtida através de Gerenciamento de Disponibilidade. No entanto bem planejado, é impossível eliminar completamente todos os riscos - por exemplo, um incêndio em um edifício próximo, provavelmente, resultar em danos, ou pelo menos a negação de o, como resultado da implementação de um cordão de isolamento. Como regra geral, a chamada de uma recuperação capacidade só deve ser tomado como um último recurso. Idealmente, uma organização deve avaliar todos os riscos para reduzir a necessidade potencial para recuperar o negócio, o que é provável que incluem os serviços de TI. As medidas de redução de risco precisam ser implementadas e deve ser instigado em conjunto com gerenciamento de disponibilidade, como muitos destes reduzir a probabilidade de falha afectando o disponibilidade de serviço. Medidas de redução de risco típicas incluem: • •

•

Instalação de no-break e de energia de backup para o computador Sistemas tolerantes a falhas de crítica aplicaçãos, onde mesmo que mínima tempo de inatividade É inaceitável - por exemplo, um sistema bancário Arrays RAID e espelhamento de disco para LAN servidors para evitar a perda de dados e garantir disponibilidade contínua de dados

ITIL V3 - Service Design - Página:

242 de 477

•

• • • • • •

Poupar equipamento /componentes para ser utilizado em caso de falha de equipamento ou componente - por exemplo, uma LAN de reposição servidor já configurado com a configuração padrão e disponível para substituir um servidor com defeito mínimo construir e configuração tempo A eliminação de SpoFs, como pontos de o único de rede ou fonte de alimentação em um único edifício Resilientes sistemas de TI e de redes Terceirização serviços para mais de um provedor Maior física e baseada em TI segurança controlars Melhores controles para detectar interrupções de serviço, tais como incêndio detecção sistemas, juntamente com sistemas de supressão Uma ampla apoio e recuperação estratégia, Inclusive fora do local de armazenamento.

As medidas acima não vai necessariamente resolver um problema ITSCM e remover o risco totalmente, mas a totalidade ou uma combinação dos dois, pode reduzir significativamente os riscos associados com a maneira pela qual os serviços são prestados ao negócio. Armazenamento off-site

Um método de resposta ao risco é o de garantir que todos os dados vitais são copiados e armazenados fora do local. Uma vez que o recuperação estratégia tem sido definido, uma estratégia de backup apropriada devem ser adoptadas e implementadas para apoiá-lo. O backup estratégia deve incluir a remoção (provavelmente dia) regular de dados (incluindo o CMS para facilitar a recuperação) dos centros de dados principais para um local de armazenamento adequado fora do local. Isto irá assegurar a recuperação de dados seguinte relativamente menor operacional falha bem como desastres total e completa. Bem como os dados eletrônicos, todas as outras informações importantes e documentos devem ser guardados fora do local, com o principal dos quais os planos GCSTI. Opções de recuperação ITSCM

Estratégia de uma organização ITSCM é um equilíbrio entre a custar de medidas de redução de riscos e opção de recuperaçãos para apoiar a recuperação da crítica processo de negócioes dentro de prazos acordados. A seguir, uma lista das opções de TI potencial de recuperação que precisam ser considerados no desenvolvimento da estratégia. Manual de soluções alternativas Para certos tipos de serviços, manuais de trabalho-around pode ser uma medida eficaz interino por um período de tempo limitado, até o De serviços de TI é retomada. Por exemplo, uma Service Desk o registro de chamadas de serviço

ITIL V3 - Service Design - Página:

243 de 477

poderia sobreviver por um tempo limitado usando formulários de papel ligados a um computador portátil com uma planilha. Acordos de reciprocidade No ado, acordo de reciprocidades medidas de contingência foram típicos onde acordos foram postas em prática com outro organização utilizando uma tecnologia semelhante. Isto já não é eficaz ou possível para a maioria dos tipos de sistemas de TI, mas ainda pode ser usado em casos específicos - por exemplo, a criação de um acordo para compartilhar instalações de alta velocidade de impressão. Reciprocidade pode também ser usado para o armazenamento para fora do local de apoios e outras informações críticas. Recuperação gradual Esta opção (por vezes referido como 'espera frio') Inclui o provisão de alojamento vazio, totalmente equipada com o poder, controles ambientais e de infra-estrutura de cabeamento de rede local, ligações de telecomunicações, e disponível em uma situação de desastre para uma organização para instalar o seu equipamento próprio computador. Não inclui o equipamento de computação actual, portanto, não é aplicável para serviços que requerem rápida recuperação, Como configurar-tempo é necessário para a recuperação de serviços pode começar. Esta opção de recuperação é recomendado apenas para serviços que podem ar um atraso de tempo de recuperação em dias ou semanas, não horas. Qualquer serviço não-crítica que pode ar este tipo de atraso deve levar em conta o custo desta opção versus o benefício para o negócio antes de determinar se um recuperação gradual opção deve ser incluído nas opções ITSCM para a organização. O alojamento pode ser fornecido comercialmente por terceiro, Para uma taxa, ou pode ser privado, (estabelecido pela própria organização) e, desde como um serviço fixo ou portátil. Ainstalação portátil é tipicamente um edifício pré-fabricado fornecido por um terceiro, e localiza-se, quando necessário, num local pré-determinado acordado com a organização. Isto pode estar em outro local a alguma distância a partir do local de origem, talvez um outro edifício propriedade. O equipamento informático substituição terá de ser planejada, mas fornecedors de equipamentos de computação nem sempre garantem equipamento de substituição dentro de um prazo fixo, embora eles normalmente fazê-lo sob seus melhores esforços. Recuperação intermediária Esta opção (por vezes referido como 'espera iva') É selecionada por organizações que precisam recuperar instalações de TI dentro de um tempo pré-

ITIL V3 - Service Design - Página:

244 de 477

determinado para evitar impactos ao meio processo de negócio. O tempo predeterminado terá sido acordado com o negócio durante o BIA. O mais comum é a utilização de instalações comerciais, que são oferecidos por organizações de terceiros de recuperação para um número de s, espalhando o custo através daqueles s. Instalações comerciais incluem frequentemente operação,sistema de gestão e e técnico. O custo varia de acordo com os serviços solicitados, tais como processadores, periféricos, comunicações, e quão rapidamente os serviços devem ser restaurard. A vantagem disto é que o serviço cliente pode ter o praticamente instantâneo a um site, abrigado em um edifício seguro, em caso de um desastre. Deve ser entendido, contudo, que o restauração do serviços no local pode levar algum tempo, como atrasos podem ser encontrados enquanto o site é reconfigurado para o organização que invoca o serviço, e da organização aplicaçãos e os dados precisam ser restaurados a partir de backups. Uma desvantagem importante é a potencialmente segurança implicações da execução de serviços de TI em um terceiroO centro de dados. Isso deve ser levado em conta no planejamento de usar este tipo de facilidade. Para algumas organizações, o externo recuperação intermediária opção pode não ser apropriado para isso. Se o local for invocado, existe frequentemente uma taxa diária de utilização do serviço em caso de emergência, embora isso possa ser compensado com adicional custar de seguro de trabalho. Serviços de recuperação de comerciais podem ser apresentadas de forma autosuficiente, portátil ou móvel, onde um sistema acordado é entregue no local de um cliente, dentro de um prazo acordado. Recuperação rápida Esta opção (por vezes referido como "hot standby"), prevê recuperação rápida e restauração de serviços e às vezes é fornecida como uma extensão para o recuperação intermediária fornecida por um provedor de recuperação de terceiros. Algumas organizações irá fornecer suas próprias instalações dentro da organização, mas não em um local alternativo ao utilizado para as operações normais. Outros aplicar seus próprios internos locais segundo em um local alternativo para fornecer mais resistente recuperação. Onde existe uma necessidade de um rápido restabelecimento de um serviço, é possível "alugar" espaço no local de recuperação e instalar servidors ou sistemas com sistemas de aplicativos e as comunicações já disponíveis e dados espelhado dos servidores operacionais. No caso de uma falha do sistema, os

ITIL V3 - Service Design - Página:

245 de 477

clientes podem, então, recuperar e ar para o apoio facilidade com pouca perda de serviço. Isso geralmente envolve o restabelecimento dos sistemas e serviços críticos dentro de um período de 24 horas. Recuperação imediata Esta opção (também muitas vezes referida como "hot standby", "espelhamento", "balanceamento de carga" ou "local split '), prevê a imediata restauração dos serviços, sem prejuízo do serviço. Para serviços críticos de negócios, as organizações requerem operação contínua irá fornecer suas próprias instalações dentro da organização, mas não no mesmo local das operações normais. Equipamentos de TI será suficiente "dual localizado" em qualquer local de uma propriedade ou hospedado para executar o serviço de competir a partir de qualquer localização em caso de perda de uma unidade, sem perda de serviço para o cliente. O segundo local pode então ser recuperado, enquanto o serviço é fornecido a partir do único local operável. Esta é uma opção cara, mas pode ser justificada por crítico processo de negócioes ou VBFs onde não disponibilidade de um curto período pode resultar numa significativa impacto, Ou em que não seria adequado para ser executado De serviços de TIs numa terceiro'S premissas para segurança ou outras razões. A instalação precisa ser localizado separadamente e longe o suficiente do local de casa que não será afectado por uma catástrofe que afeta esse local. No entanto, estes espelhado servidors opções e sites devem ser implementadas em estreita ligação com Gerenciamento de Disponibilidade como eles am serviços com elevados níveis de disponibilidade. O estratégia é provável que inclua uma combinação de medidas de resposta a riscos e uma combinação do acima opção de recuperaçãos, tal como ilustrado na Figura 4.25.

Figura 4.25 Exemplo conjunto de opções de recuperação

Figura 4.25 mostra que um número de opções pode ser utilizada para proporcionar a continuidade do serviço. Um exemplo da Figura 4.25 mostra que,

ITIL V3 - Service Design - Página:

246 de 477

inicialmente, a continuidade do Service Desk é fornecido usando manual processoes tais como um conjunto de formas, e talvez uma planilha operacional de um computador portátil, enquanto os planos de recuperação para o serviço são concluídas em uma "alternativarecuperação rápida'Site. Uma vez que o sítio tornou-se alternativa operacional, O Service Desk pode voltar a usar o serviço de TI. No entanto, o uso de local alternativo externo "rápida recuperação" é, provavelmente, limitado no tempo, por isso durante a execução temporariamente a partir deste site, o 'site intermediário "pode ser feita operacional e operações de longo prazo pode ser transferido para lá. Diferentes serviços dentro de uma organização exigem diferentes embutido resiliência e opções de recuperação diferentes. Seja qual for a opção escolhida, a solução terá de ser custo-justificado. Como regra geral, quanto mais longo for o negócio pode sobreviver sem um serviço, a solução mais barata será. Por exemplo, um sistema de saúde crítico que requer operação contínua será muito dispendiosa, como a perda de potencial de serviço terão de ser eliminados por meio da utilização de recuperação imediata, Enquanto um serviço cuja ausência não afetar gravemente o negócio para uma semana ou assim poderia ser apoiada por uma solução muito mais barata, como recuperação intermediária. Bem como a recuperação do equipamento de computação, o planejamento deve incluir os recuperação de alojamento e infra-estrutura para a TI e usuário pessoal. Outras áreas a serem levados em conta são os serviços essenciais, como energia, telecomunicações, água, correios, correio, papel registros e o material de referência. É importante lembrar que a recuperação é baseada em torno de uma série de acordos stand-by, incluindo alojamento, procedimentos e as pessoas, bem como sistemas e telecomunicações. Certas ações são necessárias para implementar os acordos stand-by. Por exemplo: • • •

Negociação para instalações de terceiros de recuperação e de entrar em um acordo contratual Preparar e equipar o alojamento stand-by Aquisição e instalação de stand-by sistemas de computador.

4.5.5.3 Estágio 3 - Implementação

Uma vez que o estratégia foi aprovado, o TI Plano de Continuidade do Serviços têm de ser produzidas em conformidade com a Plano de Continuidade de Negócioss. ITSCM planos precisam ser desenvolvidas para que as informações necessárias para sistemas críticos, serviços e instalações, quer continuar a ser prestado ou a ser reintegrado dentro de um período aceitável para o negócio. Uma recuperação ITSCM exemplo plano está contida no Apêndice K. Geralmente os

ITIL V3 - Service Design - Página:

247 de 477

Planos de Continuidade de Negócios contar com a disponibilidade de De serviços de TIs, instalações e recursos. Como conseqüência disso, os planos ITSCM necessidade de abordar todas as atividades para garantir que os serviços necessários, instalações e recursos são entregues em um estado aceitável operacional e são 'apto para o efeito"Quando aceito pela empresa. Isto implica não só a restauração do serviços e instalações, mas também o conhecimento das dependências entre eles, o teste necessária antes da entrega (atuação, Funcional, operacional e de testes de aceitação) e do validação de dados integridade e consistência. Note-se que os planos de continuidade são mais do que apenas a planos de recuperação, e deve incluir a documentação das medidas de resiliência e as medidas que têm sido postas em prática para permitir a recuperação, juntamente com explicações do porquê de uma abordagem particular foi tomada (isso facilita decisões devem invocação determinar que a situação particular requer uma modificação no plano). No entanto, o formato do plano deve permitir o o rápido às informações de recuperação em si, talvez como um apêndice que pode ser ado diretamente. Todo o pessoal-chave devem ter o a cópias de toda a documentação necessária recuperação. Gestão da distribuição das plantas é importante para garantir que as cópias são disponíveis para o pessoal chave em todas as vezes. Os planos devem ser documentos controlados (com documentos formalizados mantido sob Gestão da Mudança e Gerenciamento da Configuração controlo), para garantir que apenas a última versãos estão em circulação e cada beneficiário deve garantir que uma cópia pessoal é mantida fora do local. O plano deve garantir que todos os detalhes sobre a recuperação dos serviços de TI após um desastre são totalmente documentados. Deve ter detalhes suficientes para permitir que um técnico familiarizado com os sistemas a ser capaz de seguir os procedimentos. O recuperação planos incluem detalhes importantes, tais como o ponto de recuperação de dados, uma lista de sistemas dependentes, a natureza do dependência e seus pontos de recuperação de dados, hardware e sistema de requisitos de software, detalhes de configuração e referências a informações relevantes ou essenciais outro sobre o serviço e sistemas. É uma boa idéia de incluir uma lista que abrange acções específicas necessárias durante todas as fases de recuperação para o serviço e do sistema. Por exemplo, depois que o sistema foi restaurado para um estado operacional, cheques, cheques de conectividade funcionalidade ou consistência de dados e verificações de integridade devem ser realizadas antes de entregar o serviço para o negócio. Há uma série de planos de técnicas que podem existir dentro de um organização, Documentando os procedimentos de recuperação de uma normal

ITIL V3 - Service Design - Página:

248 de 477

operacional falha. O desenvolvimento e manutenção desses planos será de responsabilidade das equipes especializadas, mas será coordenado pela equipe de Gestão de Continuidade de Negócios. Estes serão adições úteis ou apêndices para a página principal plano. Além disso, os planos que precisam ser integrados com o B principal são: • • • •

•

• • • •

•

Plano de Emergência: A interface para todos os serviços de emergência e as atividades Plano de Avaliação de Danos: Contendo detalhes de danos avaliação contatos, processos e planos Plano de Salvamento: Contendo informações sobre contatos de salvamento, atividades e processoes Plano Vital Records: Detalhes de todas vital registros e de informação, em conjunto com a sua localização, que são críticas para a continuação operação do negócio Plano de Gerenciamento de Crises e Relações Públicas: Os planos no comando e controlar de diferentes situações de crise e gestão dos meios de comunicação e relações públicas Plano de alojamento e serviços: Detalhando a gestão de alojamento, instalações e os serviços necessários para o seu funcionamento contínuo Plano de Segurança: Mostrando como todos os aspectos da segurança será gerida em todos os sites de casa e locais de recuperação Pessoal Plano: Contendo detalhes de como todas as questões de pessoal será gerida durante um incidente grave Plano de Comunicação: Mostrando como todos os aspectos da comunicação serão tratados e gerenciados com todas as áreas relevantes e partes envolvidas durante um incidente grave Plano de Finanças e istração: Contendo detalhes dos métodos e processos alternativos para a obtenção de autorização de emergência eo o aos fundos essenciais durante um incidente grave.

Por fim, cada área de negócio crítico é responsável pelo desenvolvimento de um plano detalhando os indivíduos que estarão nas equipes de resgate e as tarefas a serem realizadas na invocação de disposições relativas à recuperação. O Plano ITSCM deve conter todas as informações necessárias para recuperar os sistemas de TI, redes e telecomunicações em uma situação de desastre, uma vez a decisão de invocar foi feito, e então para gerir o negócio voltar ao normal operação uma vez que a interrupção do serviço foi resolvido. Uma das entradas mais importantes para o desenvolvimento do plano é o resultado de o Análise de Impacto no Negócio. Adicionalmente outras áreas terão de ser analisada, tal como Acordo de Nível de Serviços (SLA), segurança requisitos, instruções operacionais e procedimentos e externa contratos. É provável que um separado SLA com alvos alternativos terão sido acordado se funcionando em um local de recuperação após um desastre.

ITIL V3 - Service Design - Página:

249 de 477

Outras áreas que precisam ser implementadas após a aprovação do estratégia são os seguintes: Planejamento, organização

Durante a recuperação de desastres processo, A estrutura organizacional será inevitavelmente diferente da operação normal e é baseado em torno de: •

•

•

Executivo - Incluindo a alta istração / diretoria, com autoridade total e controlo na organização e responsável pela gestão de crises e ligação com outros departamentos, divisões, organizações, meios de comunicação, reguladores, serviços de emergência, etc Coordenação - Normalmente um nível abaixo do grupo executivo e responsável pela coordenação do esforço de recuperação global dentro da organização Recuperação - Uma série de negócios e equipes de recuperação de serviços, representando as funções críticas de negócios e os serviços que devem ser estabelecidos para ar essas funções. Cada equipe é responsável por executar os planos dentro de suas áreas próprias e de ligação com a equipe, clientes e terceiros. Dentro dele as equipes de recuperação devem ser agrupados por De serviços de TI e aplicação. Por exemplo, a equipe de infra-estrutura pode ter uma ou mais pessoas responsáveis para a recuperação de conexões externas, serviços de voz, redes locais, etc, e as equipes de apoio pode ser dividido por plataforma, sistema operacional ou aplicativo. Além disso, as prioridades de recuperação para o serviço de aplicação, ou a sua componentes identificados durante a Análise de Impacto no Negócio devem ser documentadas dentro dos planos de recuperação e aplicados durante a sua execução.

Teste

A experiência tem mostrado que os planos de recuperação que não tenham sido totalmente testados não funcionar conforme pretendido, se de todo. O teste é, por conseguinte, uma parte essencial do processo de GCSTI global e a única maneira de assegurar que o selecionado estratégia,espera arranjos, logística, planos de negócios e procedimentos de recuperação vai realmente trabalhar em prática. O Provedor de serviços de TI é responsável por assegurar que os serviços de TI podem ser recuperados nos prazos necessários com a funcionalidade necessária e exigida atuação após a catástrofe. Existem quatro tipos básicos de testes que podem ser realizados:

ITIL V3 - Service Design - Página:

250 de 477

•

•

•

•

Walk-através de testes pode ser realizado quando o plano foi produzido simplesmente fazendo com que as pessoas relevantes em conjunto para ver se o plano (s) de trabalho, pelo menos de forma simulada. Testes completos deve ser realizado o mais rapidamente possível após a produção de planta e em intervalos regulares de, pelo menos, anualmente. Elas devem envolver o unidade de negócioss para auxiliar a provar a capacidade para recuperar os serviços adequadamente. Eles devem, na medida do possível, replicar uma invocação real de todos os acordos stand-by e deve envolver partes externas se eles estão planejados para serem envolvidos em uma invocação real. Os testes devem não só provar recuperação dos serviços de TI, mas também a recuperação da processo de negócioes. Recomenda-se que um observador independente registra todas as atividades dos testes e os horários da serviço recuperação. Documentação do observador dos testes será de entrada vital para o post mortem posterior rever. Os testes completos podem ser anunciados ou sem aviso prévio. O primeiro teste do plano é susceptível de ser anunciado e cuidadosamente planejada, mas os testes subsequentes podem ser 'saltado' em jogadores-chave sem aviso. É também essencial que muitas pessoas diferentes se envolver, incluindo aqueles não muito familiarizados com o serviço de TI e sistemas, como as pessoas com mais conhecimento podem não estar disponíveis quando um desastre ocorre realmente. Testes parciais também pode ser realizada em que a recuperação de alguns elementos do conjunto plano é testada, como serviços individuais ou servidors. Estes tipos de ensaios deve ser em adição ao ensaio completo não, em vez da totalidade do teste. O teste completo é a melhor maneira de testar todos os serviços que podem ser recuperados em prazos necessários e pode ser executado em conjunto sobre os sistemas de recuperação. Testes de cenários pode ser usado para reações de testes e planos para condições específicas, eventos e cenários. Eles podem incluir testes que Bs e TI Plano de Continuidade do ServiçoA interface com o outro, assim como a interface com todos os outros planos envolvidos no manuseamento e istração de um incidente grave.

Todos os testes devem ser realizados contra cenários de teste definidos, que são descritos de forma tão realista quanto possível. Deve notar-se, contudo, que mesmo a mais abrangente teste não cobre tudo. Por exemplo, em uma interrupção do serviço onde houve lesão ou até mesmo a morte de colegas, a reação do pessoal a uma crise não pode ser testada e os planos precisam fazer a permissão para isso. Além disso, os testes devem ter claramente definido objetivos e Fator Crítico de Sucessos, que vai ser utilizado para determinar o grau de sucesso do exercício. 4.5.5.4 Fase 4 - Operação Contínua

Esta etapa consiste no seguinte: ITIL V3 - Service Design - Página:

251 de 477

•

• •

•

Sensibilização, educação e formação - Esta deve cobrir o organização e, em particular, a organização de TI, para a continuidade de serviços específicos de itens. Isso garante que todos os funcionários estão cientes das implicações de continuidade de negócios e de continuidade de serviço e considerá-las como parte de seu trabalho normal, e que todos os envolvidos no plano foi treinado em como implementar suas ações. Comente - Revisão periódica de todos os entregas a partir do ITSCM processo precisa ser realizado para garantir que eles permanecem atuais. Teste - Após o teste inicial, é necessário estabelecer um programa de testes regulares para assegurar que o crítico componentes da estratégia são testadas, preferencialmente, pelo menos uma vez por ano, apesar de testar TI Plano de Continuidade do Serviços devem ser organizados em conformidade com as necessidades de negócio e as necessidades do SBDC. Todos os planos também devem ser testados após cada grande negócio mudar. É importante que qualquer alteração à tecnologia de TI estão também incluídos no estratégia, Executadas de uma forma adequada e testados para assegurar que funcionam corretamente dentro do pró globalvisão de TI após um desastre. O apoio e recuperação de De serviços de TI também devem ser monitorizados e testados para assegurar que, quando são necessários durante um incidente principal, eles vão operar conforme a necessidade. Este aspecto é coberto com mais detalhes no Operação de Serviço publicação Gestão da Mudança - O processo de Gerenciamento de Mudança deve garantir que todas as alterações são avaliados quanto ao seu potencial impacto sobre os planos GCSTI. Se o planeado mudar invalidará os planos, então o plano deve ser atualizado antes de a mudança é implementada, e deve ser testado como parte do teste de mudança. Os planos próprios devem estar sob Gestão da Mudança muito rigoroso e Gerenciamento da Configuração controlar. Planos imprecisas e capacidades de recuperação inadequado pode resultar na falha do SBDC. Além disso, em uma base contínua, sempre que houver novos serviços ou quando os serviços têm grandes mudanças, é essencial que a BIA e avaliação de risco é realizado no serviço novo ou alterado eo estratégia e planeja actualizado em conformidade.

Invocação

Invocação é o último teste da Continuidade de Negócios e Planos GCSTI. Se todo o trabalho preparatório foi concluída com êxito, e planeja desenvolvido e testado, em seguida, uma invocação do Plano de Continuidade de Negócioss, deve ser um processo simples, mas, se os planos não foram testados, as falhas podem ser esperados. É importante que a devida consideração é dada ao projeto de todos os processos de chamada, para assegurar que eles são apto para o efeito e interface com todos os outros processos de invocação relevantes. Invocação é um componente-chave dos planos, que devem incluir o processo de invocação e orientação. Deve ser lembrado que a decisão de invocar, ITIL V3 - Service Design - Página:

252 de 477

especialmente se uma instalação de recuperação de terceiros é para ser usado, não deve ser tomada de ânimo leve. Custars estará envolvido e o processo envolverá a interrupção para o negócio. Esta decisão é normalmente feita por um 'gestão de crises«Equipa de Informação, compreendendo os gerentes seniores das áreas de negócio e e (incluindo TI), usando recolhidas através de danos avaliação e de outras fontes. A perturbação pode ocorrer em qualquer momento do dia ou da noite, de modo que é essencial que o processo de orientação sobre a chamada está prontamente disponível. Os planos devem estar disponíveis para o pessoalchave no escritório e fora do escritório. A decisão de invocar deve ser feito rapidamente, pois pode haver uma vantagem de tempo envolvido no estabelecimento de instalações de um local de recuperação. No caso de um incêndio do edifício grave, a decisão pode ser relativamente fácil de fazer. No entanto, no caso de falha de energia ou de hardware culpa, Onde um resolução é esperado dentro de um curto período, o prazo deve ser definido pelo qual tempo se o incidente não foi resolvido, invocação terá lugar. Se usar provedores de serviços externos, eles devem ser avisados imediatamente se há uma chance de que a invocação poderá ter lugar. A decisão de invocar precisa de ter em conta o: • • •

Extensão do dano e escopo da invocação potencial Duração provável do rompimento e indisponibilidade de instalações e / ou serviços Hora do dia / mês / ano eo impacto potencial de negócios. No final do ano, a necessidade de invocar pode ser mais urgente, para garantir que o processamento de fim de ano está concluído a tempo.

Por isso o design da invocação processo deve fornecer orientações sobre como todas essas áreas e circunstâncias devem ser avaliadas para ajudar a pessoa de invocar a continuidade plano. O Plano ITSCM deve incluir detalhes sobre as atividades que precisam ser realizadas, incluindo: • • • •

Recuperação de apoio fitas ou uso de dados vaulting para recuperar dados Recuperação de documentação essencial, procedimentoimagens s, estações de trabalho, etc armazenados fora do local Mobilização do pessoal técnicos adequados para ir ao recuperação local para iniciar a recuperação dos sistemas e serviços necessários ar e colocando em telecomunicações alerta fornecedors apoio, serviços, aplicação fornecedores, etc, que podem ser necessários para realizar ações ou prestar assistência no processo de recuperação.

ITIL V3 - Service Design - Página:

253 de 477

A invocação e recuperação inicial é provável que seja um momento de alta atividade, que envolve longas horas para muitos indivíduos. Isso deve ser reconhecido e gerenciado pelos líderes da equipe de recuperação para garantir que as pausas são fornecidos e evitar o "burn-out". Planejamento para deslocars e handovers devem ser realizados para garantir que o melhor é feito uso de instalações disponíveis. Também é extremamente importante para assegurar que a actividade normal e tecnologia controlars permanecer no local durante a recuperação de invocação, e voltar ao normal para garantir que as informações segurança é mantida no nível correto e que a protecção de dados é preservada. Uma vez que a recuperação foi completa, a empresa deve ser capaz de operar a partir do local de recuperação no nível determinado e acordado no estratégia e relevantes SLA. O objetivo, No entanto, será a de construir o negócio para níveis normais, manter operação a partir do local de recuperação no curto prazo e desocupar o local de recuperação no menor tempo possível. Detalhes de todas essas atividades precisam ser contido dentro dos planos. Se usar serviços externos, haverá um período finito contratual para usar as instalações. Independentemente do período, um retorno ao normal deve ser cuidadosamente planejada e realizada de forma controlada. Normalmente, esse será mais um fim de semana e pode incluir alguns necessário tempo de inatividade em horário comercial. É importante que isso seja bem gerido e que todos os envolvidos estão cientes de suas responsabilidades para garantir uma transição suave.

4.5.6 Triggers, entradas, saídas e interfaces Muitos eventos podem desencadear atividade GCSTI. Estes incluem: • • • •

• • • •

•

Novos ou alterados necessidades de negócios ou serviços novos ou alterados Novas metas ou alterados dentro acordos, como SLRs, SLAs, ou OLAs contratos A ocorrência de um incidente grave que requer avaliação para invocação potencial de negócios ou de Planos de Continuidade de TI Atividades periódicas, como a BIA ou atividades de análise de risco, a manutenção de planos de continuidade ou de outra revisão, revisão ou relatar atividades Avaliação das mudanças e à participação em Alterar Conselho Consultivo reuniões Comente e revisão de negócios e de TI planos e estratégias Revisão e revisão de projetos e estratégias O reconhecimento ou a notificação de uma mudança de risco ou impacto de um processo de negócio ou VBF, uma De serviços de TI ou componente Início de testes de continuidade e planos de recuperação.

ITIL V3 - Service Design - Página:

254 de 477

Integração e interfaces de existir a partir de ITSCM a todos os outros processos. Exemplos importantes são os seguintes: •

•

•

•

•

•

•

Gestão da Mudança - Todas as alterações precisam ser considerados para o seu impacto sobre os planos de continuidade, e se são necessárias alterações ao plano, atualizações para o plano precisa ser parte da mudança. O plano em si deve estar sob controle de Gerenciamento de Mudanças. Incidente e Gerenciamento de Problemas - Incidentes podem evoluir facilmente para grandes incidentes ou desastres. Critérios claros precisam ser acordadas e documentadas em para a invocação dos planos GCSTI. Gerenciamento de Disponibilidade - Realização de Análise de Risco e implementação de respostas de risco devem ser estreitamente coordenada com a disponibilidade processo para otimizar de mitigação de risco. Gerenciamento de Nível de Serviço - recuperação requisitos serão acordados e documentados no SLAs. Diferente nível de serviços pode ser acordado e documentado que poderia ser aceitável em uma situação de desastre. Gerenciamento da Capacidade - Assegurar que há suficiente recursos para permitir a recuperação nos computadores de substituição após a catástrofe. Gerenciamento da Configuração - Os documentos do CMS os componentes que formam a infra-estrutura ea relação entre os componentes. Esta informação é valiosa para todas as fases do ITSCM ciclo de vida, A manutenção de planos e instalações de recuperação. Gestão de Segurança da Informação - Uma relação muito íntima entre ITSCM e Gestão de Segurança da Informação. A grande falha de segurança pode ser considerado um desastre, por isso, quando a realização de Análise de Risco e BIA, segurança será uma consideração muito importante.

4.5.6.1 Entradas

Existem muitas fontes de entrada exigidos pelo processo ITSCM: •

• • •

Informações de negócios: a partir do organizaçãoEstratégia do negócio, planos e planos financeiros, e informações sobre suas necessidades atuais e futuras Informações de TI: a partir da TI estratégia planos e atuais orçamentos A Estratégia de Continuidade de Negócios e um conjunto de Plano de Continuidade de Negócioss: a partir de todas as áreas do negócio Informações sobre o serviço: a partir do processo de SLM, com detalhes dos serviços da Portfólio de Serviços e a Catálogo de Serviços e meta de nível de serviços dentro de SLAs e SLRs

ITIL V3 - Service Design - Página:

255 de 477

• •

• • •

Informação financeira: a partir de Gestão Financeira, O custar de serviço profissionalvisão, O custo de recursos e componentes Alterar informação: desde o processo de Gerenciamento de Mudança, com um programa de troca e uma necessidade de avaliar todas as alterações para o seu impacto em todos os planos ITSCM CMS: que contém informações sobre as relações entre a empresa, a serviços, o serviços de apoios e a tecnologia Gestão de Continuidade de Negócios e Gerenciamento de Disponibilidade programações de testes TI Plano de Continuidade do Serviços e relatórios de ensaio de fornecedor e parceiros, se for o caso.

4.5.6.2 Saídas

As saídas do ITSCM processo incluem: • •

• • • • •

A revista ITSCM política e estratégia Um conjunto de planos ITSCM, incluindo todos os Planos de gestão de crises, planos de emergência e planos de recuperação de desastres, juntamente com um conjunto de planos de apoio e contratos com recuperação prestadores de serviços Análise de Impacto no Negócio exercícios e relatórios, em conjunto com o BCM e os negócios Análise de Risco e Gestão de opiniões e relatórios, em conjunto com a empresa, gerenciamento de disponibilidade e Gestão de Segurança Um cronograma de testes ITSCM ITSCM teste cenários Relatórios de ensaios e resenhas. ITSCM

Previsões e relatórios de previsão são utilizados por todas as áreas para analisar, prever e prever negócio e de TI cenários e suas possíveis soluções.

4.5.7 Indicadores Chave de Desempenho De serviços de TIs são entregues e podem ser recuperadas para satisfazer objetivo de negócios: •

• • • •

Regular auditars do ITSCM Planos para garantir que, em todos os momentos, os requisitos de recuperação acordados do negócio pode ser conseguida Todos os objectivos de valorização de serviços estão acordadas e documentadas em SLAs e são realizáveis dentro dos Planos ITSCM Teste regular e abrangente de Planos ITSCM Revisões periódicas são realizadas, pelo menos anualmente, dos negócios e planos de continuidade de TI com as áreas de negócio Negociar e gerenciar todos os contratos necessários com ITSCM terceiro

ITIL V3 - Service Design - Página:

256 de 477

•

Redução global da risco e impacto de possível falha de serviços de TI.

Consciência ao longo das organizações dos planos: • • •

Garantir a sensibilização de impacto nos negócios, necessidades e requisitos ao longo de TI Garantir que todas as áreas de serviços de TI e funcionários estão preparados e capazes de responder a uma invocação dos Planos ITSCM Comunicação regular dos objectivos ITSCM e responsabilidades dentro da empresa apropriado e áreas de serviços de TI.

4.5.8 Gestão da Informação ITSCM precisa registrar todas as informações necessárias para manter um conjunto abrangente de planos GCSTI. Esta base de informações deve incluir: • • • • • • •

•

Informações da versão mais recente do BIA A informação completa sobre o risco de dentro de um registro de riscos, incluindo as respostas de avaliação de risco e de risco A versão mais recente do BCM estratégia e Bs Detalhes relativos a todos os testes concluídos e um cronograma de todos os testes planejados Detalhes de todos os Planos ITSCM e seus conteúdos Detalhes de todos os outros planos associado a planos de ITSCM Detalhes de toda a recuperação recuperação das instalações existentes, fornecedors e parceiros, acordos de recuperação e contratos, e equipamento de reposição alternativa Detalhes de todos apoio e recuperação processoes, horários, sistemas e meios de comunicação e seus respectivos locais.

Todas as informações acima precisa ser integrado e alinhado com todas as informações BCM e todas as outras informações exigidas pela GCSTI. As interfaces com muitos outros processos são necessárias para garantir que este alinhamento seja mantido.

4.5.9 Desafios, Fatores Críticos de Sucesso e riscos Um dos grandes desafios ITSCM é fornecer planos adequados, quando não há processo de BCM. Se não houver um processo de BCM, então é provável que faça suposições incorretas sobre importância do negócio de processo de negócioes e, portanto, adotar as estratégias de continuidade e opções erradas. Sem BCM, soluções ITSCM caros e planos será inútil pela ausência dos respectivos planos e arranjos dentro do negócio. Além disso, se o BCM está ausente, então a empresa pode deixar de identificar barato não-soluções de TI e dinheiro resíduos no ineficazes e caros soluções de TI.

ITIL V3 - Service Design - Página:

257 de 477

Em alguns organizaçãos, a percepção do negócio é que a continuidade é uma responsabilidade de TI, e, portanto, a empresa assume que a TI será responsável por desastre recuperação e que De serviços de TIs continuará a funcionar sob quaisquer circunstâncias. Isto é especialmente verdade em algumas situações terceirizados onde o negócio pode ser relutante em compartilhar suas informações com um BCM prestador de serviços externo. Se existe um processo BCM estabelecida, então o desafio se torna um dos alinhamento e integração. ITSCM deve assegurar que informações precisas é obtido a partir do processo de BCM nas necessidades, impacto e prioridades do negócio, e que as informações ITSCM e os planos estão alinhadas e integradas com as da empresa. Tendo alcançado esse alinhamento, o desafio torna-se um de mantê-los alinhados pela istração e controlar de negócios e de TI mudar. É essencial, portanto, que todos os documentos e planos são mantidos sob estrito Gestão da Mudança e Gerenciamento da Configuração controlar. Os CSFs principais para o processo ITSCM são: • •

TI serviços são fornecidos e podem ser recuperadas para satisfazer objetivo de negócios Conscientização de toda a organização do negócio e TI Plano de Continuidade do Serviços.

Alguns dos principais riscos associados com ITSCM incluem: • • • •

• •

Falta de compromisso do negócio para os processos e ITSCM procedimentos Falta de compromisso do negócio e falta de informação adequada sobre os planos e estratégias futuras A falta de compromisso da alta istração ou a falta de recursos e / ou orçamento para o processo ITSCM Os processos se concentrar muito nas questões de tecnologia e não o suficiente sobre o De serviços de TIs e as necessidades e prioridades da empresa Análise de Risco e Gestão são realizadas isoladamente e não em conjunto com Gerenciamento de Disponibilidade e Gestão de Segurança Planos ITSCM e informações tornam-se desatualizados e perder o alinhamento com as informações e os planos da empresa e BCM.

ITIL V3 - Service Design - Página:

258 de 477

4.6 Gestão de Segurança da Informação 4.6.1 Finalidade objetivo / / objetivo "O objetivo do processo de ISM é alinhar a segurança de TI com os negócios segurança e garantir que a segurança da informação é gerido de forma eficaz em todos serviço e Serviço de Gestão de atividades.

ISM precisa ser considerado dentro da corporativa geral governo quadro. A governança corporativa é o conjunto de responsabilidades e práticas exercido pela diretoria e gerência executiva com o objetivo de fornecer estratégico direção, garantindo a objetivos são alcançados, verificando os riscos estão a ser geridos adequadamente e verificar que os recursos da empresa são utilizados de forma eficaz. A segurança da informação é uma gestão atividade dentro da estrutura de governança corporativa, que fornece a direção estratégica para atividades de segurança e garante que os objetivos sejam alcançados. Ele ainda garante que os riscos de segurança da informação são adequadamente gerenciados e que os recursos de informação da empresa são usados de forma responsável. O objectivo do ISM é fornecer um foco para todos os aspectos da TI segurança e gerenciar todas as atividades de segurança de TI. "Informação", o termo é usado como um termo geral e inclui armazenamentos de dados, bancos de dados e metadados. O objetivo da informação segurança é proteger os interesses dos que se basear em informações, e os sistemas e comunicações que forneçam as informações, a partir de dano resultante do falhas de disponibilidade, confidencialidade e integridade. Para a maioria das organizações, o objetivo da segurança é cumprida quando: •

• • •

A informação está disponível e utilizável quando necessário, e os sistemas que fornecem adequadamente pode resistir a ataques e recuperar ou prevenir falhas (disponibilidade) A informação é observada por ou divulgadas somente para aqueles que têm o direito de saber (confidencialidade) A informação é completa, precisa e protegidos contra modificações não autorizadas (integridade) Negócio transaçãos, bem como o intercâmbio de informação entre empresas, ou com parceiros, pode ser confiável (autenticidade e nãorepúdio).

Priorização de confidencialidade, integridade e disponibilidade deve ser considerado no contexto dos negócios e processo de negócioes. O principal guia para definir o que deve ser protegida e do nível de protecção tem que vir do negócio. Para ser eficaz, segurança deve abordar todo processo de negócioes de ponta a ponta e cobrir os aspectos físicos e técnicos. Apenas dentro do

ITIL V3 - Service Design - Página:

259 de 477

contexto das necessidades do negócio e os riscos a istração pode definir a segurança.

4.6.2 Âmbito O ISM processo deve ser o ponto focal para todas as questões de segurança de TI, e deve assegurar que um Política de Segurança da Informação é produzido, mantido e imposto que cobre o uso e abuso de todos os sistemas e serviços de TI. ISM precisa entender o total de TI e ambiente de segurança de negócios, incluindo a: • • • • • •

Política de Negócios e planos de segurança Negócio atual operação e os seus segurança requisitos Futuros planos de negócio e requisitos Requisitos legais Obrigações e responsabilidades em matéria de segurança contidos SLAs O negócio e riscos de TI e sua gestão.

Compreender tudo isto permitirá ISM para assegurar que todos os actuais e futuros aspectos de segurança e os riscos do negócio são custo-benefício gerenciado. O processo de ISM deve incluir: • • •

• • • • •

A produção, manutenção, distribuição e aplicação de uma Política de Segurança da Informação e as políticas de segurança de apoio Compreender os requisitos acordados de segurança atuais e futuras do negócio e da política de segurança existente e planos de negócio Implementação de um conjunto de controlos de segurança que am o Política de Segurança da Informação e gerenciar os riscos associados ao o a serviços, informações e sistemas Documentação de todos os segurança controles, em conjunto com a operação e manutenção dos controles e seus riscos associados Gestão de fornecedors e contratos sobre o o a sistemas e serviços, em conjunto com Gestão de Fornecedores Gestão de todas as violações de segurança e incidentes associados a todos os sistemas e serviços A melhoria proativa de controles de segurança e gestão de risco de segurança e redução de riscos de segurança Integração de aspectos de segurança em todos os outros processos de TI SM.

Para conseguir informação eficaz segurança governança, a gestão deve estabelecer e manter um Sistema de Gestão da Segurança (SGSI) para orientar a desenvolvimento e gestão de um programa abrangente de segurança da informação que a o objetivo de negócios.

ITIL V3 - Service Design - Página:

260 de 477

4.6.3 Valor para o negócio ISM garante que uma Política de Segurança da Informação é mantida e aplicada que atende às necessidades da Política de Segurança de Negócios e as exigências da empresa governo. ISM aumenta a consciência da necessidade de segurança dentro de todos os serviços de TI e ativoss ao longo do organização, Assegurando que o política é apropriada para as necessidades da organização. ISM gerencia todos os aspectos de TI e segurança da informação em todas as áreas de TI e Serviço de Gestão de atividade. ISM oferece garantia de processo de negócioes impondo controles de segurança apropriados em todas as áreas de TI e de gestão de TI risco em linha com os negócios e corporativo gestão de risco processos e orientações.

4.6.4 Políticas / princípios / conceitos básicos Empresarial prudente práticas exigem que os processos de TI e iniciativas alinhadas com os processos de negócios e objetivos. Isso é fundamental quando se trata de segurança de informações, que devem ser estreitamente alinhados com a segurança de negócios e necessidades de negócio. Além disso todos os processos dentro da organização de TI deve incluir segurança considerações. Gestão executiva é responsável pela organizaçãoInformação 's e é encarregado de responder a questões que afetam sua proteção. Além disso, os conselhos de istração são esperados para fazer a segurança da informação uma parte integrante da governança corporativa. Todos Provedor de serviços de TI organizações de produtores devem garantir que eles têm uma política abrangente ISM (s) e os controles de segurança necessários para acompanhar e fazer cumprir as políticas. 4.6.4.1 estrutura de segurança

O Gestão de Segurança da Informação processo e um quadro geralmente consistem em: • •

• • • •

Um Política de Segurança da Informação e políticas específicas de segurança que tratam cada aspecto do estratégia, Controles e regulação Um Sistema de Gestão da Segurança (SGSI), contendo os padrões de gestão, procedimentos e diretrizes de apoio às políticas de segurança da informação A estratégia de segurança abrangente, intimamente ligada aos objectivos do negócio, estratégias e planos Uma estrutura de segurança organizacional eficaz Um conjunto de controles de segurança para apoiar a política A gestão de riscos de segurança

ITIL V3 - Service Design - Página:

261 de 477

• • •

Processos de monitoramento para garantir observância e fornecer sobre eficácia Estratégia de comunicação e um plano para a segurança Formação e sensibilização estratégia e plano.

4.6.4.2 A Política de Segurança da Informação

Informações Gestão de Segurança atividades devem ser focado e dirigido por uma informação geral Política de Segurança e um conjunto de reforçar as políticas de segurança específicas. O ITP deve ter o total apoio do executivo de topo de gestão de TI e, idealmente, o apoio e compromisso da gestão de topo executivo de negócios. O política deve cobrir todas as áreas de segurança, Ser o caso, satisfazer as necessidades do negócio e deve incluir: • • • • • • • • • • • •

Um total Política de Segurança da Informação Usar e abusar de política de TI ativos Uma política de controle de o Uma política de controle de senha Uma política de e-mail Uma política de internet Uma política anti-vírus Uma informação classificação política Adocumento política de classificação A política de o remoto A política em matéria de fornecedor o de De serviços de TI, Informação e componentes Um ativos disposição política.

Essas políticas devem estar amplamente disponível a todos clientes e usuários, e suas observância deve ser referido em todas as SLRs, SLAs, contratos e acordos. As políticas devem ser autorizados pela gerência executiva de topo dentro do negócio e de TI, e de conformidade com eles deve ser aprovado em uma base regular. Todos segurança políticas devem ser revistas - e, se necessário, revisto - em pelo menos uma vez por ano. 4.6.4.3 O Sistema de Gestão da Segurança (SGSI)

A estrutura ou o ISMS sua vez, fornece uma base para o desenvolvimento de um programa de segurança de baixo custo de informação que a o objetivo de negócios. Que irá envolver os Quatro Ps de pessoas, processos, produtos e tecnologia, bem como parceiros e fornecedors para garantir altos níveis de segurança estão no lugar. A ISO 27001 é o formal padrão contra a qual as organizações podem procurar independente certificado do seu SGSI (ou seja, suas estruturas para projetar, implementar, gerenciar, manter e reforçar os processos de segurança da informação e controlars sistemática e consistente ao longo das organizações). O ITIL V3 - Service Design - Página:

262 de 477

SGSI mostrado na Figura 4.26 mostra uma abordagem que é amplamente utilizado e é baseada no aconselhamento e orientação descrita em muitas fontes, incluindo ISO 27001.

Figura 4.26-Quadro para o gerenciamento de segurança de TI

Os cinco elementos dentro deste quadro são os seguintes: Controlar O objetivos de um elemento de controle da ISMS são os seguintes: • • • •

Estabelecer um quadro de gestão para iniciar e gerenciar informações segurança no organização Estabelecer uma estrutura de organização para elaborar, aprovar e implementar o Política de Segurança da Informação Atribuir responsabilidades Estabelecer e controlar a documentação.

Plano O objetivo do plano elemento do SGSI é conceber e recomendar as medidas de segurança apropriadas, baseadas em um entendimento das exigências da organização. Os requisitos serão recolhidas a partir de fontes como a negócios e serviços risco, Planos e estratégias, SLAs e OLAs e as responsabilidades legais, morais e éticos para informações segurança. Outros fatores, como a quantidade de recursos disponíveis e da organização prevalecente cultura e atitudes em relação à segurança, deve ser considerada.

ITIL V3 - Service Design - Página:

263 de 477

A Política de Segurança da Informação define a atitude da organização e postura em matéria de segurança. Este deve ser um documento de toda a organização, não apenas aplicável ao Provedor de serviços de TI. A responsabilidade pela manutenção do documento cabe ao Gerente de Segurança da Informação. Executar O objectivo da implementação do ISMS é assegurar que apropriado procedimentos, ferramentas e controlars estão no local para apoiar o Política de Segurança da Informação. Entre as medidas estão: • •

Prestação de contas para ativos - Gerenciamento da Configuração eo CMS são inestimáveis aqui Informações classificação - Informação e repositórios devem ser classificados de acordo com a sensibilidade ea impacto de divulgação.

O sucesso da implementação dos controles de segurança e das medidas depende de uma série de fatores: • • • •

A determinação de uma política clara e consensual, integrado com as necessidades do negócio Segurança procedimentos que são justificadas, adequadas e apoiado pela alta istração O marketing eficaz e educação em requisitos de segurança Um mecanismo para a melhoria.

Avaliação O objetivos da avaliação elemento do ISMS são os seguintes: • • •

Supervisionar e verificar observância com a política de segurança e requisitos de segurança em SLAs e OLAs Realizar regularmente auditars de segurança técnica dos sistemas de TI Fornecer informações aos auditores externos e reguladores, se necessário.

Manter Os objectivos do presente elemento de manter o ISMS são os seguintes: • •

Melhorar acordos de segurança tal como especificado, por exemplo, SLA e OLAs Melhorar a implementação de segurança medidas e controles.

ITIL V3 - Service Design - Página:

264 de 477

Isto deve ser conseguido utilizando uma PDCA (Plan-Do-Check-Act) Ciclo, que é uma abordagem formal sugerido pela ISO 27001 para o estabelecimento da Sistema de Gestão da Segurança (SGSI) ou quadro. Este ciclo é descrito em mais detalhe na publicação de Melhoria de Serviço Continuada. A governação da segurança Governança de segurança da informação, quando devidamente implementado, deve fornecer seis básica resultados: •

•

•

•

•

•

Alinhamento estratégico: • Os requisitos de segurança deve ser impulsionada por exigências corporativas • Soluções de segurança precisam se encaixar processos empresariais • Investimento em informação segurança devem estar alinhados com a empresa estratégia e acordada no perfil de risco. Entrega de valor: • Um conjunto padrão de práticas de segurança, ou seja, os requisitos de segurança de linha de base melhores práticass • Devidamente priorizadas e distribuídas esforço para áreas com maior impacto e benefício do negócio • Soluções institucionalizadas e comoditizado • Soluções completas organização, cobertura e processo, bem como a tecnologia • Uma cultura de melhoria contínua. Gestão de riscos: • Consensual no perfil de risco • Compreensão de exposição ao risco • Consciência de gestão de risco prioridades • Mitigação de riscos • Aceitação de riscos / deferência. Gestão de desempenho: • Conjunto definido, concordou e significativa de métricos • Processo de medição que vai ajudar a identificar deficiências e fornecer sobre os progressos realizados questões resolver • Garantia independente. Gestão de recursos: • Conhecimento é capturado e disponível • Documentado segurança processos e práticas • Arquitetura de segurança desenvolvido (s) para utilizar eficientemente os recursos de infra-estrutura. Garantia de processo de negócio.

ITIL V3 - Service Design - Página:

265 de 477

4.6.5 as atividades de processo, métodos e técnicas A finalidade do processo de ISM é assegurar que o segurança no que diz respeito aos aspectos serviços e tudo Serviço de Gestão de atividades são adequadamente geridos e controlados de acordo com as necessidades do negócio e riscos: As principais atividades dentro do processo ISM são: • • • • • • •

Produção, rever e revisão de uma estratégia global Política de Segurança da Informação e um conjunto de políticas de apoio específicas Implementação, comunicação e execução do segurança políticas Avaliação e classificação de todas as informações ativoss e documentação Implementação, revisão, revisão e melhoramento de um conjunto de segurança controlars e avaliação de risco e respostas Monitoramento e gestão de todos segurança violações e incidentes de segurança importantes Relatórios, análise e redução dos volumes e impacto de violações de segurança e incidentes Programação e realização de revisões de segurança, auditars e os testes de penetração.

As interacções entre estas actividades essenciais são ilustradas na Figura 4.27.

ITIL V3 - Service Design - Página:

266 de 477

Figura 4.27 TI processo de Gestão de Segurança

Desenvolvidos Gestão de Segurança da Informação processos, juntamente com os métodos, ferramentas e técnicas, constituem o segurança estratégia. O gerente de segurança deve garantir que tecnologias, produtos e serviços estão no local e que o total política é desenvolvida e bem publicados. O gerente de segurança também é responsável pela arquitetura de segurança, autenticação, autorização e istração recuperação. A estratégia de segurança também precisa considerar como ele vai se implantar boas práticas de segurança em todas as áreas do negócio. Treinamento e conscientização são vitais na geral estratégia, Conforme segurança muitas vezes é o mais fraco na fase usuário final. É aqui, também, que há uma necessidade de desenvolver métodos e processos que permitem que as políticas e normas para ser mais fácil de ser seguido e implementado. Recursos precisam ser atribuídos para acompanhar a evolução destas tecnologias e os produtos que eles am. Por exemplo, a privacidade continua a ser importante e, cada vez mais, o foco da regulamentação do governo, fazendo privacidade observância tecnologia tecnologias um importante facilitador. 4.6.5.1 Os controles de segurança

O Gerente de Segurança da Informação deve entender que a segurança não é um o na ciclo de vida de serviços e sistemas de segurança e que não pode ser resolvido através da tecnologia. Em vez disso, a segurança da informação deve ser parte integrante de todos os serviços e sistemas e é um curso processo que tem de ser gerida de forma contínua através de um conjunto de comandos de segurança, como mostrado na Figura 4.28.

ITIL V3 - Service Design - Página:

267 de 477

Figura 4,28 controles de segurança para ameaças e incidentes

O conjunto de controles de segurança deve ser projetado para apoiar e reforçar o Política de Segurança da Informação e para minimizar a todas as ameaças reconhecidos e identificados. Os controles serão consideravelmente mais custoefetiva se incluído no projeto de todos os serviços. Isto irá assegurar a proteção contínua de todos os serviços existentes e que os novos serviços eo o a eles estão em linha com a política. As medidas de segurança podem ser utilizados numa fase específica na prevenção e tratamento de incidentes de segurança, conforme ilustrado na Figura 4.28. Segurança incidentes são causados não apenas por ameaças técnicas - as estatísticas mostram que, por exemplo, a haste grande maioria de erros humanos (intencional ou não) ou erros processuais, e muitas vezes têm implicações em outras áreas, tais como segurança, legais ou de saúde. As etapas que se seguem podem ser identificados. No início, há um risco de que uma ameaça se materializar. Uma ameaça pode ser qualquer coisa que perturba o processo de negócio ou tem impacto negativo sobre o negócio. Quando um ameaça materializa, falamos de uma segurança incidente. Este incidente de segurança pode resultar em danos (para informações ou para bens) que tem de ITIL V3 - Service Design - Página:

268 de 477

ser reparado ou corrigido. Medidas adequadas podem ser seleccionadas para cada uma destas fases. A escolha das medidas dependerá da importância atribuída à informação. •

•

•

•

•

Preventivo:segurança medidas são utilizadas para prevenir um incidente ocorra. O exemplo mais conhecido de medidas preventivas é a atribuição de o direitos a um grupo limitado de pessoas autorizadas. Os requerimentos adicionais associados com esta medida incluem o controle de direitos de o (concessão, manutenção e retirada de direitos), autorização (identificação de quem é permitido o o a que informações e usar as ferramentas), identificação e autenticação (confirmando que está buscando o) e controle de o (garantir que somente pessoas autorizadas podem ter o). Redutiva: Novas medidas podem ser tomadas com antecedência, para minimizar possíveis danos que possam ocorrer. Estes são "reducionistas" medidas. Conhecer exemplos de medidas de redução estão fazendo regularmente apoios e a desenvolvimento, Testes e manutenção de planos de contingência. Detetive: Se um incidente ocorre, é importante descobrir o mais rapidamente possível - detecção. Um exemplo familiar desta está monitorando, ligado a um procedimento de alerta. Outro exemplo é um programa antivírus. Repressivo: Medidas são então usados para neutralizar qualquer continuação ou a repetição do incidente de segurança. Por exemplo, um endereço de conta ou rede está temporariamente bloqueada após inúmeras tentativas fracassadas de logon ou a retenção de um cartão quando várias tentativas são feitas com um número PIN errado. Corretivo: O dano é reparado, tanto quanto possível, utilizando as medidas correctivas. Por exemplo, medidas corretivas incluem a restauração do backup, ou regressar a uma situação estável anterior (rollback, back-out). Fallback também podem ser vistos como uma medida corretiva.

A documentação de todos os controles devem ser mantidos para refletir com precisão a sua operação, A manutenção e o seu método de operação. 4.6.5.2 Gestão de violações de segurança e incidentes

Em caso de violações graves de segurança ou incidentes, um avaliação é necessário no devido tempo, para determinar o que deu errado, o que causou isso e como ela pode ser prevenida no futuro. No entanto, este processo não deve ser limitada a casos graves de segurança. Todas as violações de incidentes de segurança e de segurança precisam ser estudados a fim de obter um quadro completo da eficácia do segurança medidas como um todo. Um relatório procedimento para incidentes de segurança é necessário para ser capaz de avaliar a eficácia e eficiência da segurança presente mede com base

ITIL V3 - Service Design - Página:

269 de 477

em uma visão de todos os incidentes de segurança. Isto é facilitado por meio da manutenção de ficheiros de registo e de controlo, e, é claro, o registro de incidentes da Service Desk função. A análise destas estatísticas sobre questões de segurança deve levar a ações de melhoria voltadas para a redução da impacto e volume de todas as violações e incidentes de segurança, em conjunto com Gerenciamento de Problemas.

4.6.6 Triggers, entradas, saídas e interfaces ISM de atividade pode ser desencadeada por vários eventos. Estes incluem: • • • • • • • • • •

•

Novos ou alterados corporativa governo diretrizs Nova política de segurança ou alterados Negócios Novos ou alterados corporativa gestão de risco processoes e as diretrizes Novos ou alterados necessidades de negócios ou serviços novos ou alterados Requisitos novos ou alterados dentro de acordos, como SLRs, ou SLAs, Olas contratos Comente e revisão de negócios e de TI planos e estratégias Revisão e revisão de projetos e estratégias Serviço ou componente segurança violações ou avisos, eventos e alertars, incluindo limiar eventos, relatório de exceçãos Atividades periódicas, tais como a revisão, revisão ou relatórios, incluindo a revisão e revisão ISM de políticas, relatórios e planos O reconhecimento ou a notificação de uma mudança de risco ou o impacto de um processo de negócio ou VBF, uma De serviços de TI ou componente Pedidos de outras áreas, particularmente SLM para a assistência com questões de segurança.

A implementação eficaz e eficiente de um Política de Segurança da Informação dentro de um organização irá, em grande medida, dependente bom Serviço de Gestão de processos. Na verdade, a implementação efetiva de alguns processos pode ser visto como um pré-requisito para o controle de segurança eficaz. As interfaces de chave que tem ISM com outros processos são os seguintes: •

•

Incidentes e Gerenciamento de Problemas: na prestação de assistência com o resolução e justificação posterior e correção de segurança incidentes e problemas. O Gerenciamento de Incidentes processo deve incluir a capacidade de identificar e lidar com incidentes de segurança. Service Desk e Operação de Serviçopessoal s deve "reconhecer" um incidente de segurança. ITSCM: com a avaliação de impacto nos negócios e de risco, e os próvisão de resiliência, Fail-over e recuperação mecanismos. A segurança é uma questão importante quando os planos de continuidade

ITIL V3 - Service Design - Página:

270 de 477

•

•

• •

•

•

• •

são testados ou invocado. A ITSCM trabalhando plano é um obrigatória exigência para a ISO 27001. SLM: assistência com a determinação de requisitos de segurança e de responsabilidades ea sua inclusão dentro de SLRs e SLAs, juntamente com a investigação e resolução de serviço e componente segurança violações. Gestão da Mudança: ISM deve ajudar com a avaliação de cada mudança para impacto em controles de segurança e de segurança. Também ISM podem fornecer informações sobre alterações não autorizadas. Questões legais e de RH devem ser consideradas na investigação segurança questões. Gerenciamento da Configuração dará a capacidade de fornecer informações precisas ativos informações para ajudar com as classificações de segurança. Ter um CMS precisa é, portanto, extremamente útil entrada ISM. A segurança é muitas vezes visto como um elemento de Gerenciamento de Disponibilidade, Com integridade, confidencialidade e disponibilidade (CIA), sendo a essência de Disponibilidade e ISM. Além disso, o ISM deve trabalhar tanto com gerenciamento de disponibilidade e ITSCM para realizar análise de risco integrada e exercícios de gestão. Gerenciamento da Capacidade deve considerar implicações de segurança, quando a seleção e introdução de novas tecnologias. A segurança é uma consideração importante quando da aquisição de qualquer nova tecnologia ou software. Gestão Financeira deve fornecer fundos suficientes para financiar os requisitos de segurança. Gestão de Fornecedores deve ajudar com a gestão conjunta de fornecedores e seu o a serviços e sistemas, bem como os termos e condições a serem incluídos no contratos sobre fornecedor responsabilidades.

4.6.6.1 Entradas

Gestão de Segurança da Informação terá que obter a entrada de muitas áreas, incluindo: •

• • •

Informações de negócios: de negócio da organização estratégia, Os planos e os planos financeiros e informações sobre suas necessidades atuais e futuras. Governança corporativa e de negócios segurança políticas e diretrizs, planos de segurança, Análise de Risco e respostas Informações de TI: da estratégia de TI, planos e atual orçamentos Informações sobre o serviço: a partir do SLM processo com detalhes dos serviços da Portfólio de Serviços e a Catálogo de Serviços e meta de nível de serviços dentro de SLAs e SLRs, e, possivelmente, a partir da monitoramento de SLAs, serviço de opiniões e violações dos SLAs

ITIL V3 - Service Design - Página:

271 de 477

• •

•

• •

Risco de processos e relatórios de análise: a partir de ISM, Gerenciamento de Disponibilidade e ITSCM Detalhes de todos os eventos de segurança e violações: de todas as áreas de TI e de SM, especialmente Gerenciamento de Incidentes e Gerenciamento de Problemas Alterar as informações: a partir do Gestão da Mudança com um processo de Alterar agendamento e uma necessidade de avaliar todas as alterações para o seu impacto em todos os segurança políticas, planos e controlars CMS: que contém informações sobre o relaçãos entre o negócio, Os serviços, serviços de apoios e a tecnologia Detalhes do parceiro e fornecedor o: a partir de Gestão de Fornecedores e gerenciamento de disponibilidade no o externo ao serviços e sistemas.

4.6.6.2 Saídas

Os resultados produzidos pelo Informação Gestão de Segurança processo são utilizados em todas as áreas e incluir: • •

Um total Gestão de Segurança da Informação Política, juntamente com um conjunto de políticas de segurança específicas A Segurança do Sistema de Informação de Gestão (SIGE), contendo todas as informações relativas ao ISM

Avaliação de risco de segurança revisto processoes e os relatórios • • • • • •

Um conjunto de segurança controles, juntamente com detalhes do operação e manutenção e os riscos associados Auditorias de segurança e relatórios de auditoria Segurança horários de testes e planos, incluindo testes de segurança e testes de penetração de segurança e outros relatórios Um conjunto de classificações de segurança e de um conjunto de informação classificada ativoss Comentários e relatórios de violações de segurança e incidente graves Políticas, processos e procedimentos para sócios-gerentes e fornecedors e seu o a serviços e informações.

4.6.7 Indicadores Chave de Desempenho Muitos KPIs e métricos pode ser usada para avaliar a eficácia e eficiência do processo de ISM e actividades. Estas métricas precisam ser desenvolvidos a partir do serviço, cliente e perspectiva de negócios tais como: •

Empresas protegido contra violações de segurança:

ITIL V3 - Service Design - Página:

272 de 477

•

•

•

•

•

•

Diminuição do percentual de violações de segurança relatados ao Service Desk • Diminuição percentual no impacto de violações de segurança e incidentes • Aumento percentual em conformidade com SLA segurança cláusulas. A determinação de uma clara e consensual política, Integrado com as necessidades do negócio: diminuição do número de não-conformidades do processo ISM com a política de segurança de negócios e processos. Procedimentos de segurança que são justificadas, adequadas e apoiado pela alta istração: • Aumento do aceitação e conformidade dos procedimentos de segurança • Aumento do apoio e comprometimento da alta istração. Um mecanismo para melhoria: • O número de melhorias sugeridas para segurança procedimentos e controlars • Diminuição do número de segurança não-conformidade detectada durante exames e testes de segurança. A segurança da informação é uma parte integrante de todos os De serviços de TIs e tudo ITSM processoES: aumento do número de serviços e conformant processos com os procedimentos de segurança e controles. O marketing eficaz e educação em requisitos de segurança, a sensibilização do pessoal de TI da tecnologia de e dos serviços: • Uma maior sensibilização da política de segurança e de seu conteúdo, em todo o organização • Aumento percentual de completude do técnico Catálogo de Serviços contra componentes de TI apoiando os serviços • Service Desk apoio a todos os serviços.

4.6.8 Gestão da Informação Todas as informações necessárias pelo ISM deve ser contido dentro dos SIGE. Isto deve incluir todos segurança controles, riscos, violações, processos e relatórios necessários para apoiar e manter a Política de Segurança da Informação e o ISMS. Esta informação deverá abranger todos os serviços de TI e componentes e precisa ser integrado e mantido em alinhamento com todos os outros sistemas de TI de gestão da informação, em especial o Portfólio de Serviços e do. CMS Os SIGE também irá fornecer a entrada para auditorias de segurança e revisões e para as atividades de melhoria contínua tão importante para todos ISMSs. Os SIGE também irá fornecer valiosa contribuição para o projeto de novos sistemas e serviços.

ITIL V3 - Service Design - Página:

273 de 477

4.6.9 Desafios, Fatores Críticos de Sucesso e riscos ISM enfrenta muitos desafios no estabelecimento de uma política de segurança adequada informação com um processo efetivo de apoio e controles. Um dos maiores desafios é garantir que haja um apoio adequado da negócio, Segurança empresarial e de gestão sênior. Se estes não estiverem disponíveis, será impossível estabelecer um processo ISM eficaz. Se não houver apoio da gerência sênior de TI, mas não há e do negócio, a TI segurança controlos e avaliação de risco será severamente limitado no que eles podem alcançar por causa desta falta de apoio da empresa. É inútil execução de políticas de segurança, procedimentos e controles em TI se estes não podem ser aplicadas em toda a empresa. O maior uso de serviços de TI e ativoss está fora da TI, e por isso são a maioria das ameaças e riscos de segurança. Em algumas organizações a percepção do negócio é que a segurança é uma responsabilidade de TI, e, portanto, a empresa assume que a TI será responsável por todos os aspectos de segurança de TI e que os serviços de TI serão devidamente protegidos. No entanto, sem o apoio e empenho do pessoal de negócios e de negócios, o dinheiro investido nos controlos de segurança caros e procedimentos serão amplamente desperdiçado e que a maioria irá ser ineficaz. Se houver um negócio segurança processo estabelecido, o desafio torna-se um de alinhamento e integração. ISM deve assegurar que informações precisas é obtido a partir do processo de segurança de negócios com as necessidades, os riscos, impacto e prioridades do negócio e que as políticas ISM, informações e planos estão alinhadas e integradas com as da empresa. Tendo alcançado esse alinhamento, o desafio torna-se um de mantê-los alinhados pelo gerenciamento e controle dos negócios e de TI mudar usando estrita Gestão da Mudança e Gerenciamento da Configuração controlar. Mais uma vez, isto requer o apoio e compromisso da empresa e gerência sênior. Os CSFs principais para o processo de ISM são: • • • • • • •

Empresas protegidos contra segurança violações A determinação de uma clara e consensual política, Integrado com as necessidades do negócio Procedimentos de segurança que são justificadas, adequadas e apoiado pela alta istração O marketing eficaz e educação em requisitos de segurança Um mecanismo para a melhoria A segurança da informação é uma parte integral de todos os serviços de TI e todos os processos de ITSM O disponibilidade de serviços não seja comprometida por incidentes de segurança

ITIL V3 - Service Design - Página:

274 de 477

•

Propriedade clara e conscientização das políticas de segurança entre a comunidade de clientes.

Sistemas de informação pode gerar muitos benefícios diretos e indiretos, e como muitos riscos diretos e indiretos. Estes riscos têm levado a uma lacuna entre a necessidade de proteger os sistemas e serviços eo grau de proteção aplicado. A diferença é causada por fatores internos e externos, incluindo o uso generalizado da tecnologia, a crescente dependência do negócio em TI, a crescente complexidade e da interconexão dos sistemas, o desaparecimento das fronteiras tradicionais de organização e cada vez mais onerosas exigências regulatórias. Isto significa que não são novas áreas de risco que podem ter um significativo impacto em operações críticas de negócios, tais como: • • •

Crescentes exigências de disponibilidade e robustez Crescente potencial de utilização indevida e abusiva de sistemas de informação que afeta os valores de privacidade e ética Perigos externos de hackers, levando a ataques de negação de serviço e ataques de vírus, espionagem, extorsão industrial e vazamento de informações organizacionais ou dados particulares.

Porque a nova tecnologia oferece o potencial para negócios dramaticamente melhorada atuação, Melhores informações e demonstraram segurança podem agregar valor real para o organização contribuindo para a interação com parceiros comerciais, mais perto cliente relações, vantagem competitiva e melhor reputação protegida. Ele também pode permitir novas formas e mais fácil de processar electrónico transaçãos e confiança generate. Na competitiva economia global de hoje, se uma organização quer fazer negócios, pode muito bem ser solicitado a apresentar detalhes de sua postura de segurança e os resultados de seu desempenho ado em termos de testes realizados para garantir a segurança de suas informações recursos. Outras áreas de grandes riscos associados ISM incluem: • • • •

•

A falta de compromisso do negócio para os processos e ISM procedimentos Falta de compromisso do negócio e falta de informação adequada sobre os planos e estratégias futuras A falta de compromisso da alta istração ou a falta de recursos e / ou orçamento para o processo ISM O processoes concentrar muito nas questões de tecnologia e não o suficiente sobre o De serviços de TIs e as necessidades e prioridades da empresa Avaliação de risco e gestão é realizada de forma isolada e não em conjunto com Gerenciamento de Disponibilidade e ITSCM

ITIL V3 - Service Design - Página:

275 de 477

•

ISM políticas, planos, riscos e de informação se tornam desatualizados e perder o alinhamento com a informação relevante e os planos de negócios e de negócios segurança.

ITIL V3 - Service Design - Página:

276 de 477

4,7 Gestão de Fornecedores 4.7.1 Finalidade objetivo / / objetivo "A meta da Gestão de Fornecedores processo é istrar fornecedors e os serviços que eles fornecem, para oferecer perfeita qualidade de serviço de TI ao negócio, garantindo valor para o dinheiro é obtida. '

O processo de Gerenciamento de Fornecedor garante que os fornecedores e os serviços eles fornecem são gerenciados de TI para apoiar metas de serviço e as expectativas de negócios. O objetivo desta seção é aumentar a consciência do contexto do negócio de trabalhar com parceiros e fornecedores, e como este trabalho pode ser melhor direcionado para perceber o benefício do negócio para a organização. É essencial que os processos de Gestão de Fornecedores e planejamento estão envolvidos em todas as fases do ciclo de vida de serviço, a partir de estratégia e projeto, Através transição e operação, Para a melhoria. As demandas de negócios complexos exigem a amplitude completa de habilidades e capacidade para apoiar provisão de um conjunto abrangente de serviços de TI de uma empresa, portanto, o uso de rede de valors e os fornecedores e os serviços que prestam são parte integrante de qualquer solução end-to-end. Fornecedores e gestão de fornecedores e parceiros são essenciais para a provisão de qualidade de serviços de TI. A finalidade do Gestão de Fornecedores processo é a obtenção valor para o dinheiro de fornecedors e para assegurar que os fornecedores de realizar os objectivos previstos nos respectivos contratos e acordos, enquanto que em conformidade com todos os termos e condições. O principal objetivos do processo de Gestão de Fornecedores são: • •

• • • •

Obter valor para o dinheiro do fornecedor e contratos Certifique-se que subjacente contratos e acordos com fornecedores estão alinhados às necessidades do negócio, e apoiar e alinhar com as metas acordadas em SLRs e SLAs, em conjunto com SLM Gerenciar o relacionamento com fornecedores Gerenciar o desempenho do fornecedor Negociar e acordar contratos com fornecedores e gerenciá-los através de sua ciclo de vida Manter um fornecedor política e um apoio Fornecedor e Banco de Dados Contrato (SCD).

4.7.2 Âmbito O Gestão de Fornecedores processo deve incluir a gestão de todos os fornecedores e contratos necessários para ar o provisão de De serviços

ITIL V3 - Service Design - Página:

277 de 477

de TIs para o negócio. Cada provedor de serviços devem ter processos formais para a gestão de todos os fornecedores e contratos. No entanto, os processos devem se adaptar para atender a importância do fornecedor e / ou do contrato e o potencial de negócios impacto no provisão de serviços. Muitos fornecedores oferecem serviços de apoio e produtos que têm um menor de forma independente relativamente, e bastante indireta, papel na geração de valor, mas coletivamente fazer uma contribuição direta e importante para a geração de valor e implementação do negócio global estratégia. A maior contribuição que o fornecedor faz ao valor de negócios, mais esforço o prestador de serviços deve colocar na gestão do fornecedor e do mais que fornecedor devem ser envolvidos na desenvolvimento e realização do negócio estratégia. A contribuição menor valor do fornecedor, o mais provável é que o relação será gerido principalmente em um operacional nível, com interação limitada com o negócio. Pode ser adequado em alguns organizaçãos, especialmente as maiores, para gerenciar equipes internas e fornecedores, onde diferentes unidade de negócioss pode fornecer apoio de elementos-chave. O processo de Gerenciamento de Fornecedor deve incluir: • • • • • • • • • • •

Implementação e execução da política de fornecedor Manutenção de um Fornecedor e Banco de Dados Contrato (SCD) Fornecedor e contrato de categorização e avaliação de risco Fornecedor e contrato avaliação e selecção Negociação, desenvolvimento e acordo de contratos Revisão de contrato, renovação e rescisão Gestão de fornecedores e desempenho do fornecedor Acordo e implementação de planos de melhoria de serviços e fornecedor Manutenção de contratos-tipo, termos e condições Gestão de resolução de litígios contratuais Gestão de sub-contratados fornecedores.

TI Gestão de Fornecedores muitas vezes tem de cumprir as normas organizacionais ou corporativo, diretrizs e requisitos, especialmente aqueles de finanças corporativas, jurídica e de compras, como ilustrado na figura 4.29.

ITIL V3 - Service Design - Página:

278 de 477

Figura 4.29 Gestão de Fornecedores - papéis e interfaces

A fim de assegurar que os fornecedores fornecem valor para o dinheiro e cumprir as metas de serviço, a relação entre cada fornecedor deve ser propriedade de um indivíduo dentro da provedor de serviços organização. No entanto, um único indivíduo pode possuir a relação de um ou de muitos fornecedores, como ilustrado na Figura 4.29. Para garantir que relaçãos são desenvolvidos de uma forma consistente e desempenho que os fornecedores está devidamente revisado e gerenciado, papels precisam ser estabelecidas para uma Gestão de Fornecedores proprietário do processo e Gerente de Contratos. Em menor organizaçãos, estes separado papels podem ser combinadas em uma única responsabilidade.

4.7.3 Valor para o negócio O principal objetivos da Gestão de Fornecedores processo são proporcionar valor para o dinheiro de fornecedores e contratos e para garantir que todos os alvos em contratos com fornecedores e acordos subjacentes estão alinhadas às necessidades de negócio e metas acordados dentro de SLAs. Isso é para garantir a entrega ao negócio de ponta a ponta, de qualidade, sem costura serviços de TI que estão alinhados às expectativas do negócio. O processo de Gestão de Fornecedores devem se alinhar com todos os requisitos corporativos e as exigências de todos os outros processos de TI SM, particularmente ISM e GCSTI. Isso garante que o valor de actividade obtém apoio fornecedor serviços e que eles estão alinhados com as necessidades do negócio.

4.7.4 Políticas / princípios / conceitos básicos O Gestão de Fornecedores tentativas processo para garantir que os fornecedores cumpram os termos, condições e metas do seu contratos e

ITIL V3 - Service Design - Página:

279 de 477

acordos, enquanto tentava aumentar o valor para o dinheiro obtido de fornecedores e os serviços que prestam. Todo o processo de Gestão de Fornecedores atividade deve ser conduzido por um fornecedor estratégia e da política de Estratégia de Serviço. A fim de se obter consistência e eficácia na implementação da política, um banco de dados de fornecedores e contratos (SCD) deve ser estabelecido, como ilustrado na Figura 4.30, juntamente com claramente definidos papels e responsabilidades.

Figura 4.30 processo de Gestão de Fornecedores

Idealmente, o SCD deve constituir um elemento integrante de um CMS completo ou SKMS, registrando todos os detalhes de fornecedores e contrato, juntamente com detalhes do tipo de serviço(S) ou produto (s) fornecidos por cada fornecedor, E todas as outras informações e as relações com o CIS associada outro. Os serviços prestados pelos fornecedores também constituem uma parte essencial da Portfólio de Serviços e a Catálogo de Serviços. A relação entre o serviços de apoios e de TI e serviço de negócios eles am são fundamentais para fornecer qualidade de serviços de TI. Esta informação dentro do SCD irá fornecer um conjunto completo de informações de referência para todos Gestão de Fornecedores procedimentos e atividades:

ITIL V3 - Service Design - Página:

280 de 477

• • • • •

Fornecedor categorização e manutenção do banco de dados de fornecedores e contratos (SCD) Avaliação e set-up de novos fornecedores e contratos Estabelecimento de novos fornecedores Fornecedor e Gestão de Contratos e atuação Renovação de contrato e rescisão.

Os dois primeiros elementos da lista acima são cobertas pela Design de Serviços fase. O terceiro elemento é parte de Transição de Serviço, E os dois últimos são parte da Operação de Serviço encenar e são abordados com mais detalhes nessas publicações.

4.7.5 as atividades de processo, métodos e técnicas Esta seção fornece mais detalhes sobre a Gestão de Fornecedores processo, seus sub-processos e atividades, bem como a gestão do contrato ciclo de vida. Ao lidar com a externa fornecedors, é altamente recomendado que um formal contrato com claramente definidos, acordados e documentados responsabilidades e metas é criado e gerido através dos estágios de seu ciclo de vida, desde a identificação da necessidade de negócio para a operação e da cessação do contrato: •

•

•

•

Identificação das necessidades do negócio e preparação da caso de negócio: • Produzir uma Declaração de Necessidade (SOR) e / ou concurso (ITT) • Assegurar a conformidade com estratégia/política • Preparar o caso de negócio inicial, incluindo opções (interna e externa), custars, prazos, metas, benefícios, avaliação de risco. Avaliação e aquisição de novos contratos e fornecedores: • Identificar o método de compra ou contratação • Estabelecer critérios de avaliação - por exemplo, de serviços, capacidade (Ambos pessoal e organização), qualidade e custo • Avaliar opções alternativas • Selecionar • Negociar contratos, metas e os termos e condições, incluindo responsabilidades, fecho, Renovação, prorrogação, disputa de transferência, • Concordar e adjudicar o contrato. Estabelecer novos fornecedores e contratos: • Configure o fornecedor serviço e do contrato, dentro do SCD e quaisquer outros associados sistemas corporativos • Transição de serviço • Estabelecer contatos e relacionamentos. Categorização de fornecedores e contratos:

ITIL V3 - Service Design - Página:

281 de 477

• • • • •

•

•

Avaliação ou reavaliação do fornecedor e contrato Assegurar mudanças progrediram através Transição de Serviço Categorização do fornecedor Atualização do SCD Manutenção contínua da SCD. Gerenciar o fornecedor e contrato desempenho: • Gestão e controlar da operação e entrega de um serviço / produtos • Monitor e relatório (serviço, Qualidade e custos) • Rever e melhorar (qualidade, serviço e custars) • Gestão do fornecedor e a relação (Comunicação, riscos, mudanças, falhas, melhorias, contatos, interfaces) • Revisão, pelo menos anualmente, serviço escopo contra a necessidade de negócios, metas e acordos • Plano para possível fecho/ Renovação / extensão. Fim do prazo: • Review (determinar os benefícios entregues, em andamento exigência) • Renegociar e renovar ou cancelar e / ou transferência.

O negócio, TI, finanças, compras e contratos precisam trabalhar juntos para garantir que todas as fases do contrato ciclo de vida são geridos de forma eficaz. Todas as áreas precisam ser conjuntamente envolvidas na escolha da solução e gestão do curso atuação do fornecedor, Com cada área assumir a responsabilidade para os interesses de sua própria área, embora seja consciente das implicações sobre o organização como um todo. Os processos envolvidos nas fases do ciclo de vida do contrato são explicados em detalhes nas seções seguintes. 4.7.5.1 Avaliação de novos fornecedores e contratos

As atividades associadas com a identificação de necessidades de negócio e das subsequentes avaliação de novos fornecedores e contratos fazem parte do Design de Serviços processo. As saídas desta área fornecem entradas para todas as outras fases do ciclo de vida do contrato. É vital para o sucesso contínuo do contrato e da relação que o negócio está intimamente envolvido em todos os aspectos dessas atividades. Toda organização deve ter modelos e um método formal para a produção de caso de negócios e sua aprovação e sign-off. O detalhamento das necessidades do negócio e os conteúdos do plano de negócios deve ser acordado, aprovado e assinado por ambas as empresas e de TI. Ao selecionar um novo fornecedor ou contrato, uma série de fatores precisam ser levados em consideração, incluindo histórico, capacidade, Referências rating de crédito, e tamanho em relação ao negócio que está sendo colocado. Além disso, dependendo do tipo de fornecedor relação, pode haver questões pessoais

ITIL V3 - Service Design - Página:

282 de 477

que necessitam de ser consideradas. Cada organização deve ter processoes e procedimentos para o estabelecimento de novos fornecedores e contratos. Embora se reconheça que os fatores que podem existir influência a decisão sobre o tipo de relacionamento ou escolha do fornecedor (por exemplo, a política dentro da organização, relacionamentos existentes), é essencial que, nesses casos, o raciocínio é identificado e avaliado o impacto total para garantir caro erros sejam evitados. Os serviços podem ser provenientes de um único fornecedor ou múltiplos fornecedores. Os serviços são mais provável de ser obtida a partir de dois ou mais fornecedores concorrentes onde a exigência é para os serviços de padrão ou de produtos que estão disponíveis 'off-the-shelf ". Multi-fonte é mais provável de ser usado onde o custo é a determinante principal, e os requisitos para o desenvolvimento de variantes do serviços são baixos, mas pode também ser realizada para distribuir o risco. Fornecedores em uma lista de múltiplas fontes pode ser designado com o estatuto de "Fornecedor preferencial" dentro da organização, Limitar ou eliminar escopo para o uso de outros fornecedores. Parceria relaçãos são estabelecidos a nível executivo e são dependentes de uma vontade de troca estratégico informações para alinhar estratégias de negócios. Muitos relacionamentos com fornecedores estrategicamente importantes estão agora posicionados como parceria relacionamentos. Isso reflete um movimento longe de relações hierárquicas, nas quais tradicionalmente o fornecedor atos subordinadamente à cliente organização, que é caracterizado por: • • •

• • •

•

Alinhamento estratégico: Bom alinhamento cultura, Valores e objetivos, que conduz a um alinhamento das estratégias comerciais Integração: A integração final dos processos de ambos os organismos O fluxo de informação: Boa comunicação e troca de informações em todos os níveis, especialmente no estratégico nível, levando a fechar entendimento A confiança mútua: Uma relação baseada na confiança mútua entre as organizações e seus indivíduos Abertura: Ao informar sobre o desempenho do serviço, custarAnálise de Risco e Responsabilidade coletiva: Articulação parceria equipas que responsabilidade coletiva para a corrente atuação e desenvolvimento futuro da relação Compartilhado risco e recompensa: Por exemplo concordando custos como investimento e resultantes eficiência benefícios são compartilhados, ou como os riscos e recompensas de flutuações nos custos de materiais são compartilhadas.

ITIL V3 - Service Design - Página:

283 de 477

Ambas as partes obtêm benefícios da parceria. Uma organização deriva valor progressivamente mais de um fornecedor relacionamento como a compreensão do fornecedor da organização como um todo aumenta, a partir de seu inventário de TI arquiteturas até à sua cultura corporativa, valores e objetivo de negócios. Com o tempo, o fornecedor é capaz de responder mais rapidamente e de forma mais adequada às necessidades da organização. Os benefícios de fornecedor de um compromisso de longo prazo da organização, dando-lhe maior estabilidade financeira, e que lhe permite financiar investimentos de longo prazo, que beneficiam a sua clientes. A parceria torna possível para as partes a alinhar a sua Infra-estrutura de TIs. Arquitetura conjunta e acordos de controle de risco permitir que os parceiros para implementar um conjunto de soluções compatíveis a partir de segurança, Rede, dados / intercâmbio de informações, para o fluxo de trabalho e sistemas de processamento de aplicações. Esta integração pode proporcionar melhorias de serviços e custos reduzidos. Tais movimentos também reduzir os riscos e custos associados com one-off tático soluções, posto em prática para superar um fornecedor de TI com o da organização. A chave para uma relação bem sucedida parceria está sendo absolutamente clara sobre os benefícios e os custos de tal relacionamento vai entregar antes de entrar nela. Ambas as partes, então sabe o que é esperado deles desde o início. O sucesso da parceria pode envolver um acordo sobre a transferência de pessoal para o parceiro ou terceirização organização como parte do acordo e de relacionamento. Provedor de serviços organizações devem ter documentado e processos formais para avaliação e seleção de fornecedores com base em: • • •

Importância e impacto: A importância do serviço para o negócio, fornecida pela fornecedor Risco: os riscos associados com o uso do serviço Custos: o custo do serviço e sua próvisão.

Áreas muitas vezes outros da organização de prestação de serviços, tais como Finanças, Jurídico e Compras, vai se envolver com este aspecto do processo. Organizações prestadoras de serviços devem ter processos, abrangendo: • • • •

Produção de caso de negócio documentos Produção de Sor e convites para apresentação de propostas ou documentos proposta Formal avaliação e seleção de fornecedores e contratos A inclusão de cláusulas, termos e condições em contratos, inclusive rescisão antecipada, aferição, Saída ou transferência de contratos, resolução de conflitos, gestão de rescisão sub-contratados fornecedores e normal

ITIL V3 - Service Design - Página:

284 de 477

•

Transição de novos contratos e fornecedores.

Estes processos podem, e deve ser, diferente, com base no tipo, tamanho e categoria do fornecedor e do contrato. A natureza e extensão de um acordo depende do tipo e um relacionamento avaliação dos riscos envolvidos. Uma análise de risco pré-acordo é uma etapa vital em estabelecer qualquer acordo com o fornecedor externo. Para cada festa, ele expõe os riscos que precisam ser abordados e precisa ser tão abrangente quanto possível, cobrindo uma grande variedade de riscos, incluindo reputação do negócio financeiro, operacional, Regulamentares e legais. Um acordo global minimiza o risco de litígios resultantes de uma diferença de expectativas. Um acordo flexível, que atende de forma adequada para sua adaptação em todo o período de vigência do acordo, é de fácil manutenção e a a mudança com uma quantidade mínima de renegociação. O conteúdo de uma base subjacente contrato ou contrato de serviço são as seguintes: • •

•

• •

Condições básicas: O termo (duração) do contrato, as partes, os locais, escopo, Definições e base comercial. Descrição do serviço e extensão: a funcionalidade do serviçoestá sendo prestado e sua extensão, juntamente com restrições no fornecimento de serviços, tais como desempenho, disponibilidade,capacidade, Interface técnico e segurança. Funcionalidade do serviço pode ser explicitamente definido, ou, no caso de serviços bem estabelecidos, incluído por referência a outros documentos estabelecidos, tal como o Portfólio de Serviços e a Catálogo de Serviços. Padrões de serviço: As medidas de serviço e os níveis mínimos que constituem aceitável atuação e qualidade, E.g. Ele pode ter um requisito de desempenho para responder a um pedido de um novo sistema de mesa em 24 horas, com serviço aceitável considerada como tendo ocorrido quando esta condição for satisfeita desempenho em 95% dos casos. Nível de serviços devem ser realistas, mensuráveis e alinhados à organizaçãoAs prioridades de negócio e apoiar as metas acordadas dentro de SLRs e SLAs. Workload gamas: As faixas de volume dentro do qual se aplicam normas de serviço, ou para que determinado preços regimes aplicáveis. Gestão da informação (MI): Os dados que devem ser comunicados pelo fornecedor sobre o desempenho operacional - tomar cuidado para garantir que MI é focada em medidas mais importantes ou título de relatórios em que o relação serão avaliados. Key Performance Indicators (KPIs) e Balanced Scorecards (BSC) podem formar o núcleo de dados de desempenho relatados.

ITIL V3 - Service Design - Página:

285 de 477

•

Responsabilidades e dependências: Descrição das obrigações da organização (no apoio ao fornecedor nos esforços de prestação de serviços) e do fornecedor (na sua próvisão do serviço), incluindo a comunicação, contatos e escalada.

Um contrato de serviço extensivo também pode conter: • •

Débito serviço e regime de crédito (incentivos e sanções) Adicional atuação critérios.

A seguir dá uma pequena amostra dos temas jurídicos e comerciais normalmente cobertos por um serviço ou acordo contratual: • • • • • • • • • • • • • •

Escopo de serviços a serem prestados Requisitos de desempenho de serviços Divisão de responsabilidades e de acordo Pontos de o, comunicação e relatórios de freqüência e conteúdo Revisão de contrato e os processos de resolução de litígios Estrutura de preços As condições de pagamento Compromissos com mudar e investimento Processo de mudança acordo Confidencialidade e os anúncios Propriedade intelectual direitos e os direitos autorais Limitações de responsabilidade Direitos de rescisão de cada partido Obrigações de rescisão e além.

A forma final de um acordo, e parte da terminologia, pode ser ditada pelas opiniões e preferências do concurso e departamentos jurídicos, ou por empresas especializadas legais. Procurar aconselhamento jurídico ao formalizar contratos de fornecimento externo. Contratos formais Formal contratos são adequados para regime de abastecimento externas que fazem uma contribuição significativa para a entrega e desenvolvimento da negócio. Contratos prevêem compromissos vinculativos legais entre cliente e fornecedor, E cobrir as obrigações de cada organização tem para o outro a partir do primeiro dia do contrato, frequentemente se estende para além do seu termo. Um contrato é usado como a base para acordos com fornecedores externos, onde um compromisso obrigatório é exigido. De alto valor e / ou estratégico relacionamentos são sustentados por um contrato formal. A natureza formalidade e ligação de um contrato não estão em desacordo com o cultura de

ITIL V3 - Service Design - Página:

286 de 477

um acordo de parceria, mas sim formar a base sobre a qual a confiança no relacionamento pode ser fundada. Um contrato é susceptível de ser estruturada com um corpo principal contendo as cláusulas comerciais e legais, e com os elementos de um contrato de serviço, conforme descrito anteriormente, que figura como horários. Os contratos podem também incluir um certo número de outros documentos relacionados como agendas, por exemplo: • • • • •

Segurança requisitos Continuidade de requisitos de negócios Mandatado técnico padrãos Planos de migração (acordado agendada mudar) Acordos de confidencialidade.

Maioria das grandes organizações têm contratos e departamentos jurídicos especializados em contratos de sourcing. Empresas especializadas legais podem ser utilizados para financiar a aquisição interna e jurídica função ao estabelecer importantes contratos formais. Acordos subjacentes Em ITIL um SLA é definido como um «acordo escrito entre um provedor de serviços e o cliente (s) que os documentos acordados nível de serviços para um 'serviço. Os prestadores de serviços devem estar cientes de que os SLAs são amplamente utilizados para formalizar baseadas em serviços, relacionamentos, tanto interna como externamente, e que, embora em conformidade com a definição acima, estes acordos variam consideravelmente no detalhe coberto. Os pontos de vista de algumas organizações, como o Instituto Chartered de Compra e Abastecimento (CIPS) e vários advogados especializados, são que os SLAs não deve ser usado para gerenciar as relações externas, a menos que eles fazem parte de um contrato subjacente. O Guia Completo para preparação e execução de Contratos de Nível de Serviço (2001) enfatiza que um SLA autônomo pode não ser legalmente aplicável, mas sim "representa a boa vontade ea fé das partes signatárias". Por isso, é do interesse de prestadores de serviços e fornecedores, para garantir que os SLAs sejam incorporados em um quadro adequado contratual que se encontra com o ITIL objetivo que os SLAs são acordos vinculativos. SLAs, acordos subjacentes e os contratos devem ser revistos em uma base regular para garantir atuação está de acordo com a nível de serviços que foram acordados. A organização é susceptível de ser dependente do seu próprio interno grupo de apoios, em certa medida. Para ser capaz de atingir as metas de SLA, é

ITIL V3 - Service Design - Página:

287 de 477

aconselhável ter acordos formais no lugar com estes grupos. Acordo de Nível Operacionals (ANO) assegurar que os serviços que sustentam ar o negócio / TI metas de SLA. OLAs foco no operacional os requisitos que a serviços precisam conhecer. Este é um não-contratual, orientada a serviços documento descrevendo serviços e atendimento padrãos, com responsabilidades e obrigações quando apropriado. Tal como aconteceu com SLA, é importante que OLAs são monitorados para destacar os potenciais problemas. O Gerente de Nível de Serviço tem a responsabilidade geral para avaliar o desempenho em relação às metas para que as medidas podem ser tomadas para remediar, e prevenir a recorrência de futuro, quaisquer violações OLA. Dependendo do tamanho da organização e da variedade de serviços, por exemplo, SLAs e OLAS, um Gerente de Nível de Serviço deve assumir a responsabilidade por seu serviço ou conjunto de serviços. 4.7.5.2 categorização Fornecedor e manutenção do banco de dados de fornecedores e contratos (SCD)

O Gestão de Fornecedores processo deve ser adaptável e gastar mais tempo e esforço chave gestão fornecedors que menos importante fornecedors. Isto significa que algum tipo de processo de categorização deve existir dentro do processo de Gestão de Fornecedores para categorizar o fornecedor e sua importância para a provedor de serviços e os serviços prestados à negócio. Fornecedores podem ser categorizados de muitas maneiras, mas um dos melhores métodos para categorizar os fornecedores é baseado na avaliação da risco e impacto associados com o uso do fornecedor, devendo o valor ea importância do fornecedor e os seus serviços para a empresa, como ilustrado na figura 4.31.

ITIL V3 - Service Design - Página:

288 de 477

Figura 4,31 categorização Fornecedor

A quantidade de tempo e esforço gasto no gerenciamento do fornecedor e a relação, em seguida, pode ser adequado para a sua classificação: •

•

Estratégico: Para significativas 'parceria' relações que envolvem dirigentes compartilham informações confidenciais estratégica para facilitar planos de longo prazo. Estas relações, normalmente, seria de propriedade e em nível gerencial sênior dentro da provedor de serviços organização, E envolveria um o regular e frequente e atuação opiniões. Estas relações provavelmente exigiria o envolvimento de Estratégia de Serviço e Design de Serviços recursos, e que incluem o melhoramento específico contínuo programas (por exemplo, um provedor de serviço de rede, fornecimento de serviços de redes de todo o mundo e seu apoio). Tático: Para as relações que envolvem comercial significativo atividade e de negócios interação. Estas relações, normalmente, ser gerido pela istração central e que envolveria um o regular e avaliações de desempenho, muitas vezes incluindo programas de melhoria contínua (por exemplo, uma empresa de manutenção de hardware fornecendo resolução de servidor ferragens falhas).

ITIL V3 - Service Design - Página:

289 de 477

•

•

Operacional: Para os fornecedores de produtos ou serviços operacionais. Estas relações, normalmente, seria gerido por gestão operacional júnior e envolveria pouco contato, mas regulares e avaliações de desempenho (por exemplo, de hospedagem provedor de serviços, Fornecendo espaço de hospedagem para uma baixa utilização, o site de baixo impacto ou internamente usado De serviços de TI). Mercadoria: Para os fornecedores que oferecem baixo valor e / ou produtos facilmente disponíveis e serviços, o que poderia ser alternativamente obtida com relativa facilidade (por exemplo, papel ou fornecedores de cartuchos de impressora).

Relacionamento com fornecedores estrategicamente importantes são dadas a maior atenção. É nestes casos que os gestores Fornecedor tem que garantir que a cultura da organização de prestação de serviços é estendida para o domínio fornecedor, de modo que a relação funciona além do inicial contrato. O aumento da popularidade do externa de abastecimento, E o aumento do escopo ea complexidade de alguns arranjos de terceirização, resultou em uma diversificação dos tipos de relacionamento com fornecedores. Numa estratégico nível, é importante compreender as opções disponíveis, de modo que o tipo mais adequado de fornecedor relação pode ser estabelecida para ganhar o máximo benefício e evolui de acordo com as necessidades do negócio. Para conseguir selecionar o tipo mais adequado de relacionamento com o fornecedor, é preciso que haja uma compreensão clara do objetivo de negócios que estão a ser alcançados. Um certo número de factores, da natureza do serviço para o global custar, Determinar a importância de um fornecedor de um perspectiva de negócios. Como mostrado mais tarde, a maior importância do negócio de um relacionamento com o fornecedor, mais o negócio precisa ser envolvido na gestão e no desenvolvimento de uma relação. Uma abordagem de categorização formal pode ajudar a estabelecer essa importância. O valor do negócio, medido como a contribuição para o negócio cadeia de valor, Proporciona uma mais negócios alinhados avaliação que o preço de contrato puro. Além disso, o padrão mais os serviços que estão sendo adquiridos, menor a dependência do que a organização tem em relação ao fornecedor, e mais prontamente o fornecedor pode ser substituída (se necessário). Serviços padronizados apoiar o negócio através do tempo mínimo para o mercado ao implantar novos ou alterados serviço de negócios, e na busca de estratégias de redução de custos. Mais informações sobre este assunto podem ser encontradas no Estratégia de Serviço publicação. O mais personalizada esses serviços são, maior a dificuldade em se mudar para uma alternativa fornecedor. Personalização pode beneficiar o negócio,

ITIL V3 - Service Design - Página:

290 de 477

contribuindo para a vantagem competitiva por meio de atendimento diferenciado, ou pode ser o resultado de operacional evolução. Serviços personalizados aumentar a dependência do fornecedor, aumentam o risco e pode resultar em custos aumentados. A partir de um fornecedor perspectiva, serviços sob medida pode diminuir a sua capacidade de alcançar economias de escala através de operações comuns, resultando em margens estreitas, e capital reduzido disponível para futuros investimentos. Produtos padronizados e serviços são a abordagem preferida, a menos que uma vantagem de negócio claro existe, caso em que um fornecedor estratégico oferece o serviço personalizado. Relacionamentos de alto valor ou dependência de alta envolvem riscos maiores para a organização. Estes relacionamentos precisam contratos abrangentes e ativos relação gestão. Tendo estabelecido o tipo de fornecedor, A relação, então, precisa ser formalizado. Na discussão a seguir, "acordo", o termo é utilizado genericamente para se referir a qualquer formalização de um relacionamento entre cliente e fornecedor de organizações, e podem ir desde o informal para abrangentes contratos juridicamente vinculativos. Simples e de baixo valor relacionamentos podem ser cobertos por termos padrão de um fornecedor e as condições, e ser gerido totalmente pela TI. Uma relação de estratégico importância para o negócio, por outro lado, exige um contrato abrangente, que assegura que o fornecedor a a evolução das necessidades comerciais ao longo da vida do contrato. O contrato precisa ser gerenciado e desenvolvido em conjunto com a aquisição e os departamentos jurídicos e de negócios das partes interessadass. O acordo é a base para o relacionamento. O mais adequado e completo o acordo, o mais provável é que a relação vai entregar o benefício do negócio para ambas as partes. A qualidade da relação entre o provedor de serviços e seus fornecedor(S) é muitas vezes dependente dos indivíduos envolvidos de ambos os lados. Portanto, é vital que os indivíduos com os atributos, habilidades, competências e personalidades são selecionadas para serem envolvidos nessas relações. Aserviço de negócio pode depender de um certo número de fornecedores internos e / ou externos para a sua entrega. Estes podem incluir uma mistura de fornecedores estratégicos e fornecedores de commodities. Alguns fornecedores de fornecer diretamente à organização, outros são fornecedores indiretos ou sub-contratada de trabalho através de outro fornecedor. Fornecedores diretos são geridas directamente pelo prestador de serviço; fornecedores indiretos ou sub-contratada são gerenciados pelo fornecedor líder. Nenhum fornecedor pode

ITIL V3 - Service Design - Página:

291 de 477

oferecer produtos ou serviços utilizados para apoiar uma série de serviços de negócios diferentes. Cadeia de suprimentos A análise mostra o mapeamento entre os serviços de negócios e fornecedor serviços. Análise de processo de negócioes irá revelar os fornecedores envolvidos em cada processo e os pontos de hand-off entre eles. Gestão do cadeia de suprimentos assegura que os limites funcionais e atuação requisitos são claramente estabelecidas para cada fornecedor para garantir que o negócio global nível de serviços sejam alcançados. Serviços de negócios são mais propensos a cumprir as suas metas de forma consistente, onde há um pequeno número de fornecedores na cadeia de abastecimento, e onde as interfaces entre os fornecedores na cadeia são limitadas, simples e bem definido. Reduzir o número de fornecedores diretos reduz o número de relacionamentos que precisam ser gerenciados, o número de questões de peer-to-peer fornecedor que precisam ser resolvidos, e reduz a complexidade das atividades gestão de fornecedores. Algumas organizações podem conseguir reduzir ou fechar toda a cadeia em torno de um único provedor de serviços, Muitas vezes referido como um 'prime' fornecedor. Gestão de instalações muitas vezes é terceirizada para um parceiro único especialista ou fornecedor, que, por sua vez serviços de subcontratação de restaurante, manutenção de máquinas de venda automática e limpeza. Terceirização serviços de negócios inteiros a «fornecedor prime 'um único pode correr riscos adicionais. Por estas razões, organizaçãos precisa considerar com cuidado o seu cadeia de suprimentos estratégias à frente da terceirização grande atividade. O escopo de serviços terceirizados deve ser considerada para reduzir o número de fornecedores, garantindo ao mesmo tempo que risco é gerido e ele se encaixa com competências típicas do mercado de fornecimento. O SCD é um banco de dados contendo detalhes de fornecedores da organização, juntamente com detalhes dos produtos e serviços que eles fornecem para a negócio (Por exemplo, serviço de correio electrónico, fornecimento e instalação de PC Service Desk), juntamente com os detalhes do contratos. O SCD contém fornecedor detalhes, um resumo de cada produto / serviço (incluindo mecanismos de apoio), informações sobre o processo de pedido e, se for caso disso, detalhes de contrato. Idealmente, o SCD deve ser contido dentro do CMS global. SCDs são benéficas porque podem ser usados para promover os fornecedores preferidos e para evitar compras de artigos não aprovados ou incompatível. Ao coordenar e controlar a compra atividade, A organização é mais provável que seja capaz de negociar tarifas preferenciais. 4.7.5.3 Estabelecimento de novos fornecedores e contratos

ITIL V3 - Service Design - Página:

292 de 477

Adicionando novos fornecedores ou contratos para o SCD precisa ser tratada através da Gestão da Mudança processo, para assegurar que qualquer impacto é avaliado e compreendido. Na maioria das organizações, o SCD é de propriedade do Gestão de Fornecedores processo ou o departamento de compras ou de compras. O SCD proporciona um único conjunto de foco central de informações para a gestão de todos os fornecedores e contratos. Gestão de risco, Trabalhando com fornecedores, centros de avaliação de vulnerabilidades em cada fornecedor arranjo ou contrato que representam ameaças para qualquer aspecto do negócio, incluindo o impacto nos negócios, probabilidade, a satisfação do cliente, imagem de marca, participação de mercado, rentabilidade, preço da ação ou impactos regulatórios ou multas (em algumas indústrias). A natureza da relação afeta o grau de risco para o negócio. Riscos associados com um fornecedor terceirizado ou estratégica tendem a ser em maior número, e mais complexo de gerir, do que com o abastecimento interno. Raramente é possível "terceirizar" risco, embora, por vezes, alguns dos riscos podem ser transferidos para a terceirização organização. Culpar um fornecedor não impressiona clientes ou interna usuários afetada por uma segurança incidente ou um sistema de longa falha. Novos riscos decorrentes da relação precisam ser identificados e istrados, com a comunicação e escalada , conforme apropriado. Um substancial avaliação de risco deveria ter sido realizado pré-contrato, mas isso precisa ser mantido em função da evolução das necessidades do negócio, alterações no contrato escopoOu mudanças no operacional ambiente. O provedor de serviços organização e o fornecedor deve considerar o ameaças colocados pela relação para a sua própria ativoss, e têm o seu próprio perfil de risco. Cada um deve identificar seus donos de risco. Em uma relação que funcione bem, é possível que grande parte ou todo o avaliação a ser abertamente compartilhado com a outra parte. Ao envolver especialistas fornecedores em avaliações de risco, especialmente nas avaliações de risco operacional (ORAs), a organização pode obter insights valiosos sobre a melhor forma de mitigar os riscos, bem como melhorar a cobertura da avaliação. Ao avaliar os riscos de ruptura de serviço de negócios ou funções, a empresa pode ter diferentes prioridades para o serviço /função restauração. Análise de Impacto no Negócio (BIA) é um método utilizado para avaliar os impactos em diferentes áreas da empresa, resultante de uma perda de serviço. Atividades de avaliação de risco e BIA relativos a fornecedores e contratos devem ser realizados em estreita colaboração com Gestão da Continuidade do Serviço,Gerenciamento de Disponibilidade e Gestão de Segurança da Informação, Com o objectivo de reduzir o impacto e probabilidade de falha de serviço como resultado da falha do serviço ou fornecedor do fornecedor.

ITIL V3 - Service Design - Página:

293 de 477

Uma vez que essas atividades foram concluídas e as informações do fornecedor e do contrato tenha sido introduzido no DF, incluindo os indivíduos nomeados responsáveis pela gestão do novo fornecedor e / ou contratos, a frequência de serviço /fornecedor reuniões de avaliação e reuniões de revisão contratual precisa ser estabelecido, com pontos de quebra apropriados, automatizado limiars e avisos no local. A introdução de novos fornecedores e contratos devem ser tratadas como grande mudars através transição e em operação. Isto irá assegurar que os os apropriados e pontos de comunicação são estabelecidas. 4.7.5.4 Gerenciamento de Fornecedor e Contrato e desempenho

Ao nível operacional, processos integrados precisam estar no local entre uma organização e seus fornecedores para assegurar o funcionamento do dia-a-dia eficiente práticas. Por exemplo: • • •

É o fornecedor deverá estar de acordo com a gestão da organização de Mudança processo ou quaisquer outros processos? Como é que o Service Desk notificar o fornecedor de incidentes? Como as informações são atualizadas quando CMS mudança CIs como resultado das ações de fornecedor? Quem é o responsável?

Pode haver um conflito de interesses entre o provedor de serviços organização e os seus fornecedores, especialmente no que diz respeito à Gestão da Mudança,Gerenciamento de Incidentes,Gerenciamento de Problemas e Gerenciamento da Configuração processos. O fornecedor pode querer usar seus processos e sistemas, enquanto que o provedor de serviços organização vai querer usar seus próprios processos e sistemas. Se este for o caso, responsabilidades claras e interfaces terão de ser definidos e acordados. Estas e muitas outras áreas precisam ser abordadas para assegurar o funcionamento regular e eficaz a nível operacional. Para fazer isso, todos os pontos de o e os os têm de ser identificados e procedimentoé posto no lugar para que todos compreendam o seu papels e responsabilidades. Isso deve incluir a identificação do indivíduo, único nomeado responsável para a posse de cada fornecedor e contrato. No entanto, uma organização deve tomar cuidado para não impor automaticamente seus próprios processos, mas de aproveitar a oportunidade de aprender com seus fornecedores. Um contrato foi adjudicado por um sistema personalizado Lojas de controle para que a organização do departamento de TI tinha desenvolvido processoes para apoiar o viver serviço, uma vez que foi instalado. Estes procedimentos incluídos para gravar e documentar o trabalho feito no serviço por engenheiros de campo (por exemplo, mudanças, reparars, valorização e reconfigurações). Em uma reunião do progresso do projeto, o fornecedor confirmou que tinha olhado para os procedimentos e poderia segui-los, se necessário. No entanto, tendo sido

ITIL V3 - Service Design - Página:

294 de 477

nesta situação muitas vezes antes, eles já haviam desenvolvido um conjunto de procedimentos para lidar com tais eventos. Estes procedimentos foram consideravelmente mais elegante, eficiente e mais fácil de seguir do que os desenvolvidos e propostos pelo organização. Além da interface de processo, é essencial identificar como questões são tratadas numa operacional nível. Rotas de escalonamento por terem claramente definidos e comunicados, questões são susceptíveis de ser identificados e resolvidos anteriormente, minimizando o impacto. Tanto a organização eo benefício fornecedor da captação precoce e resolução de problemas. Ambos os lados devem se esforçar para estabelecer relações de boa comunicação. O fornecedor aprende mais sobre o negócio da organização, seus requisitos e os seus planos, ajudando o fornecedor para entender e atender as necessidades da organização. Por sua vez, os benefícios da organização de um fornecedor mais sensível que está ciente dos drivers de negócio e quaisquer questões, e é, portanto, mais capaz de fornecer soluções adequadas. Fechar dia-a-dia as ligações podem ajudar cada partido para estar ciente do do outro cultura e formas de trabalhar, o que resulta em menor número de enganos e que conduz a uma relação mais bem sucedidas e de longa duração. Dois níveis de educação formal rever precisam ocorrer ao longo do contrato ciclo de vida para minimizar risco e assegurar o negócio percebe benefício máximo do contrato: •

•

Serviço /comentários de desempenho do fornecedor: relatórios sobre o desempenho deve ser produzido em uma base regular, com base no categoria de fornecedor, e deve formar a base de reuniões de avaliação de serviços. O mais importante fornecedor, o mais frequente e extensa de relatórios e revisões devem ser Comentários Serviço de escopo de serviço e contrato: Estes também devem ser realizados em uma base regular, pelo menos anualmente para todos os principais fornecedores. O objetivo destes deve ser a revisão do serviço, Em geral o desempenho do serviço, escopo e metas e do contrato, juntamente com quaisquer acordos associados. Isto deve ser comparado com as necessidades de negócios originais e os negócios atual precisa garantir que fornecedor e contratos permanecem alinhados às necessidades do negócio e continuar a oferecer valor para o dinheiro.

Reuniões de avaliação formais de desempenho deve ser realizada em uma base regular para analisar o desempenho do fornecedor contra nível de serviços, a um nível operacional detalhada. Estes encontros proporcionam uma oportunidade para verificar se o serviço em andamento gestão de desempenho continua focada em atender as necessidades de negócio. Temas típicos incluem:

ITIL V3 - Service Design - Página:

295 de 477

• • • •

•

•

Desempenho do serviço contra alvos Incidente e problema revisões, incluindo quaisquer questões escalada das empresas e dos clientes Esperada grande mudars que vai (ou pode) afetam o serviço durante o período de serviço seguinte, bem como as alterações e mudanças fracassadas que causaram incidentes Principais eventos de negócios durante o período próximo serviço que precisam de atenção especial do fornecedor (Por exemplo, o processamento final do trimestre) Melhores práticas e Planos de Melhoria de Serviço (PIS).

Iniciativas de melhoria de serviços importantes e ações são controladas através de PIS com cada fornecedor, incluindo quaisquer ações para lidar com qualquer falhas ou fraquezas. Progresso do PIS existentes, ou a necessidade de uma nova iniciativa, é revisado em reuniões de avaliação de serviços. Organizações pró-ativas ou com visão de futuro, não só usar PIS para lidar com falhas, mas também para melhorar um serviço consistentemente alcançado. É importante que um contrato fornece incentivos adequados para ambas as partes para investir na melhoria do serviço. Estes aspectos são abordados com mais detalhes na publicação Melhoria de Serviço Continuada. O governo mecanismos de fornecedores e contratos são retirados das necessidades de adequada das partes interessadass em diferentes níveis dentro de cada organização, e são estruturados de modo que os representantes da organização face-off com os seus homólogos no de fornecedor organização. Definir as responsabilidades de cada representante, atendendo fóruns e processos de assegurar que cada pessoa está envolvida no momento certo em influenciar ou dirigir as atividades certas. A escala ea importância da serviço e / ou fornecedor influenciar os mecanismos de governança necessários. O mais significativo a dependência, O maior empenho e esforço envolvidos na gestão da relação. O esforço necessário no provedor de serviços lado para governar um terceirização contrato não deve ser subestimado, especialmente em indústrias de perto regulamentados, como setores de finanças e farmacêuticos. Um objetivo chave para Gestão de Fornecedores é o de assegurar que o valor de um fornecedor para a organização é completamente realizado. Valor é percebido através de todos os aspectos da relação, a partir operacional atuação garantia, capacidade de resposta para mudar pedidos e as flutuações da demanda, por meio de contribuição de conhecimento e de experiência para a organização do capacidade. O fornecedor de serviços também devem assegurar que as prioridades do fornecedor corresponder prioridades do negócio. O fornecedor deve compreender que a sua nível de serviços são mais significativos para o negócio.

ITIL V3 - Service Design - Página:

296 de 477

Uma empresa multi-nacional de grande tinha acordos de software no lugar com o mesmo fornecedor em nada menos que 24 países. Ao organizar um acordo de licenciamento global único com o fornecedor, a empresa fez uma economia anual de £ 5.000.000. Para garantir que todas as atividades e contatos para uma fornecedor são consistentes e coordenadas, cada relacionamento fornecedor deve ter um único indivíduo nomeado responsável por todos os aspectos do relacionamento. A organização nacional de varejo teve um indivíduo possuir geral a gestão do seu principal fornecedor de serviços de rede. No entanto, serviços, contratos e faturamento foram geridos por vários indivíduos espalhados por toda a organização. O proprietário individual apresentar uma caso de negócio para a posse única do fornecedor e todos os diversos contratos, em conjunto com a consolidação de todas as facturas individuais em uma única fatura trimestral. A economia de custos estimados para a organização estavam em excesso de £ 600.000 por ano. Pesquisas de satisfação também desempenham um importante papel em revelar o quão bem fornecedor nível de serviços estão alinhados às necessidades do negócio. Uma pesquisa pode revelar casos em que há insatisfação com o serviço, mas o fornecedor é, aparentemente, um bom desempenho contra seus alvos (e vice-versa). Isto pode acontecer quando os níveis de serviço são inadequadamente definidos e deve resultar numa rever dos contratos, acordos e metas. Alguns provedores de serviços publicar tabelas da liga fornecedores com base em seus resultados de pesquisa, estimular a concorrência entre os fornecedores. Para aqueles significativa fornecedor relações em que o negócio tem um interesse directo, ambas as empresas (em conjunto com o departamento de compras) e ele vai ter estabelecido a sua objetivos para o relacionamento, e definiu os benefícios que eles esperam para realizar. Isso forma uma parte importante do plano de negócios para assumirem a relação. Estes benefícios devem ser ligados e complementares, e deve ser medido e gerenciado. Onde a empresa está buscando melhorias no atendimento ao cliente, relações fornecedor de TI contribuindo para os clientes serviços deve ser capaz de demonstrar um melhor serviço em seu próprio domínio, e quanto isso tem contribuído para melhor atendimento ao cliente. Para benefícios avaliaçãos para permanecer válida durante a vida do contrato, Alterações nas circunstâncias que ocorreram desde o caso benefícios original foi preparada deve ser tida em conta. Um fornecedor pode ter sido selecionado em sua capacidade de fornecer uma poupança anual de 5% custo operacional em comparação com outras opções, mas depois de dois anos entregou nenhuma poupança. No entanto, quando isso é devido a alterações no contrato, ou custos

ITIL V3 - Service Design - Página:

297 de 477

da indústria em geral que afectaram também as outras opções, é provável que uma poupança de custos em relação ainda está sendo realizado. Um caso mantida benefícios mostra que a poupança. Avaliações de benefícios muitas vezes recebem prioridade menor do que o custo de poupança de iniciativas, e são dadas menos prioridade em relatórios de desempenho do que as questões e problema resumos, mas é importante para a relação de longo prazo que realizações são reconhecidas. Um relatório benefícios deve fazer avaliações objetivas contra os objectivos iniciais, mas pode também incluir moralizadora evidência anedótica de realizações e de valor agregado. É importante para os dois organismos, e para a longevidade da relação, que os benefícios de ser derivado da relação são regularmente analisados e relatados. Um avaliação do sucesso de uma relação de fornecedor, a partir de um perspectiva de negócios, É provável que seja substancialmente baseado financeira atuação. Mesmo quando um serviço é um bom desempenho, pode não ser um encontro ou metas financeiras de ambas as partes. É importante que ambas as partes continuam a se beneficiar financeiramente do relacionamento. Um contrato que comprime as margens de um fornecedor com muita força pode levar a falta de investimento por parte do fornecedor, resultando em uma degradação gradual do serviço, ou até mesmo ameaçar a viabilidade do fornecedor. Em ambos os casos isso pode resultar em impactos adversos de negócios para a organização. A chave para o sucesso a longo prazo Gestão Financeira do contrato é de um esforço conjunto dirigido no sentido de manter o equilíbrio financeiro, em vez de uma relação de confronto entrega de benefícios de curto prazo para um só partido. Construir relacionamentos leva tempo e esforço. Como resultado, o organização só pode ser capaz de construir relacionamentos de longo prazo com poucos fornecedores-chave. A experiência, cultura e compromisso dos envolvidos na execução de um fornecedor relacionamento são pelo menos tão importante quanto ter um bom contrato e governo regime. As pessoas certas com as atitudes certas no relação equipe pode fazer um contrato de trabalho pobre, mas um bom contrato não garante que uma equipe de má relação proporciona. Uma quantidade considerável de tempo e dinheiro é normalmente investido em negociar acordos principal fornecedor, com mais de novo em risco para ambas as partes, se a relação não for bem sucedida. Ambas as organizações devem garantir que eles investem adequadamente nos recursos humanos afectos à gestão do relacionamento. A personalidade, comportamento e cultura dos representantes de relacionamento todos influenciar o relacionamento. Para que

ITIL V3 - Service Design - Página:

298 de 477

uma relação de parceria, todos os envolvidos precisam ser capazes de respeitar e trabalhar de perto e de forma produtiva com os seus homólogos. 4.7.5.5 renovação do Contrato e / ou rescisão

Críticas de contrato deve ser feita em uma base regular para garantir o contrato é de continuar a atender às necessidades de negócio. Críticas de contrato avaliar a operação de contrato de forma holística e em um nível mais alto do que os comentários de serviços que são realizados em um operacional nível. Esses exames devem considerar: • • • •

• •

Como bem o contrato de trabalho e sua relevância para o futuro Se mudars são necessários: serviços, produtos, contratos, acordos, metas Qual é a visão de futuro para o relacionamento - o crescimento, encolhimento, alteração, rescisão, transferência, etc? Desempenho comercial do contrato, revisões contra referências ou de mercado avaliaçãos, adequação do preços estrutura e carregamento arranjos Orientação sobre direção contrato futuro e assegurar melhores práticas gestão processoes são estabelecidos Fornecedor e governança contrato.

Para regime de abastecimento de alto valor, longos e complexos, o período de negociação do contrato e acordo pode ser demorado, caro e pode envolver um período prolongado de negociação. Pode ser uma tendência natural para desejar evitar alterações adicionais a um contrato para o maior tempo possível. No entanto, para o negócio para obter o valor integral do relacionamento com o fornecedor, o contrato deve ser capaz de ser regular e rapidamente alterada para permitir a negócio a beneficiar da evolução do serviço. Aferição fornece uma avaliação em relação ao mercado. O fornecedor pode ser cometida por contrato a manter as acusações contra uma taxa de mercado. Para manter a mesma margem, o fornecedor é obrigada a melhorar o seu funcionamento eficiência em linha com os seus concorrentes. Coletivamente, esses métodos de ajudar a fornecer uma avaliação de uma melhoria da eficiência ou deterioração. O ponto de responsabilidade dentro da organização para decidir alterar uma relação fornecedor é provável que dependem do tipo de relacionamento. O provedor de serviços pode ter identificado uma necessidade de mudar de fornecedor, com base no existente fornecedor atuação, Mas por uma relação contratual a decisão precisa ser tomada em conjunto com os contratos da organização e departamentos jurídicos. A organização deve tomar medidas cuidadosas para:

ITIL V3 - Service Design - Página:

299 de 477

•

•

•

•

Realizar um impacto profundo e Análise de Risco de uma mudança de fornecedor sobre a organização e seus negócios, especialmente durante um período de transição. Isto pode ser particularmente importante no caso de um estratégico relação. Faça um comercial avaliação da saída custars. Isso pode incluir os custos de rescisão contratual, se fornecedor responsabilidade não é clara, mas os maiores custos são susceptíveis de ser associado com um transição projeto. Para qualquer relação significativa de tamanho, este geralmente inclui um período de alimentação dupla como serviços são migrados. Qualquer alteração associada a uma mudança de fornecedor irá aumentar os custos, seja imediatamente como custos fixos, ou ao longo do tempo, onde ados pelo fornecedor e refletida de volta em taxas de serviço. Aconselhamento jurídico em termos de rescisão, o período de aviso prévio aplicável e mecanismos, e quaisquer outras conseqüências, especialmente se o contrato é ser antecipada. Reavaliar o mercado para identificar potenciais benefícios em mudar de fornecedor.

A prudente organização compromete a maioria destes os, no momento do contrato original é estabelecido para assegurar que as disposições adequadas e cláusulas estão incluídos, mas este comentário atividade deve ser reavaliado quando a mudança de fornecedor está sendo considerado.

4.7.6 Triggers, entradas, saídas e interfaces Existem muitos eventos que podem desencadear Gestão de Fornecedores atividade. Estes incluem: • • • • • •

• • •

Novos ou alterados corporativa governo diretrizs Novo negócio ou alterado e estratégias, políticas ou planos Necessidades de negócios novos ou alterados ou novas ou alteradas serviços Requisitos novos ou alterados dentro de acordos, como SLRs, SLAs, Olas ou contratos Revisão e revisão de projetos e estratégias Atividades periódicas, tais como a revisão, revisão ou comunicação, incluindo revisão e revisão de políticas de gestão de fornecedores, relatórios e planos Pedidos de outras áreas, particularmente SLM e Gestão de Segurança, Para a assistência com fornecedor questões Requisitos para os contratos novos, renovação de contrato ou rescisão de contrato Re-categorização de fornecedores e / ou contratos.

ITIL V3 - Service Design - Página:

300 de 477

As principais interfaces que Gestão de Fornecedores se com outros processos são os seguintes: • •

•

•

•

ITSCM: com relação à gestão de fornecedores de serviços de continuidade. SLM: ajuda com a determinação de metas, exigências e responsabilidades ea sua inclusão nos acordos subjacentes e contratos para garantir que eles am todos SLR e metas de SLA. Além disso, a investigação de violações de SLA e SLR causada por desempenho do fornecedor pobres. ISM: na gestão de fornecedores e seu o a serviços e sistemas, e suas responsabilidades com respeito à conformidade com as políticas e os requisitos do ISM. Gestão Financeira: Fornecer fundos suficientes para financiar Gestão de Fornecedores requisitos e contratos e de aconselhamento e orientação sobre a compra e matéria de contratos. Gestão de Portfólio de Serviços: Para garantir que todos serviços de apoios e os seus pormenores e relaçãos são precisamente refletido dentro do Portfólio de Serviços.

4.7.6.1 Entradas •

•

•

• • • •

•

•

Informações de negócios: De negócio da organização estratégia, Os planos e os planos financeiros e informações sobre suas necessidades atuais e futuras Fornecedor e estratégia de contratos: Abrange a terceirização política do provedor de serviços e os tipos de fornecedores e contratos utilizados. É produzido pela Estratégia de Serviço processos Fornecedor planos e estratégias: Detalhes dos planos de negócios e estratégias de fornecedores, Juntamente com detalhes de seus desenvolvimentos tecnológicos e planos e declarações e informações sobre a sua actual situação financeira ea viabilidade da empresa projetada Contratos com fornecedores, acordos e metas: De ambos os contratos existentes e novos acordos de fornecedores Fornecedor e informações sobre o desempenho do contrato: De ambos os contratos existentes e novos e fornecedores Informações de TI: A partir da IT estratégia planos e atuais orçamentos Problemas de desempenho: O incidente e Gerenciamento de Problemas processos, com incidentes e problemas relativa ao contrato de pobre ou o desempenho do fornecedor Informações financeiras: De Gestão Financeira, a custar fornecedor de serviço (s) e pro serviçovisão, O custo de contratos e os benefícios de negócios resultante e os planos financeiros e orçamentos, bem como os custos associados ao serviço e falha fornecedor Informações sobre o serviço: A partir do processo de SLM, com detalhes dos serviços da Portfólio de Serviços e a Catálogo de

ITIL V3 - Service Design - Página:

301 de 477

•

Serviços,meta de nível de serviços dentro de SLAs e SLRs, e, possivelmente, a partir da monitoramento de SLAs, serviço de opiniões e violações dos SLAs. Também cliente Dados de satisfação no serviço qualidade CMS: Contendo informações sobre as relações entre o negócio, Os serviços, o serviços de apoios e a tecnologia.

4.7.6.2 Saídas

As saídas dos Gestão de Fornecedores são utilizados em todas as outras partes do processo, por muitos outros processos e por outras partes do organismo. Muitas vezes, essa informação é fornecida como relatórios eletrônicos ou displays em áreas comuns ou como páginas de intranet servidors para garantir o mais up-to-date informações é sempre utilizado. A informação fornecida é como se segue: •

•

•

•

•

O Banco de Dados de Fornecedores e Contratos (SCD): Contém as informações necessárias a todos os sub-processos dentro Gestão de Fornecedores - Por exemplo, os dados monitorados e coletados como parte da gestão de fornecedores. Este é, então, invariavelmente, usada como entrada para todas as outras partes do processo de gestão de fornecedores. Fornecedor e informações sobre o desempenho do contrato e relatórios: Usado como entrada para reuniões de avaliação de fornecedores e contratos para gerenciar a qualidade do serviço prestado pela fornecedors e parceiros. Isto deve incluir informações sobre compartilhado risco se for caso disso. Fornecedor minutos e reunião de revisão do contrato: Produzido para registrar as atas e de todas as reuniões de avaliação com os fornecedores. Fornecedor Planos de Melhoria de Serviço (PIS): Usado para registrar todas as ações de melhoria e planos acordados entre provedor de serviçoss e seus fornecedores, onde for necessário, e deve ser usado para gerenciar o andamento das ações de melhoria acordadas, incluindo as medidas de redução de risco. Levantamento relatórios fornecedor: Muitas vezes, muitas pessoas dentro de um provedor de serviços organização tem relações com os fornecedores. Os comentários destas pessoas devem ser reunidas para garantir que a consistência na qualidade de serviço prestado pelos fornecedores é fornecida em todas as áreas. Estes podem ser publicados como tabelas da liga de incentivar a concorrência entre os fornecedores.

4.7.7 Indicadores Chave de Desempenho Muitos KPIs e métricos pode ser usada para avaliar a eficácia e eficiência do Gestão de Fornecedores processos e atividades. Essas métricas precisam ser

ITIL V3 - Service Design - Página:

302 de 477

desenvolvidas a partir do serviço ao cliente, e perspectivas de negócios, tais como: •

•

•

•

Empresas protegido de fornecedor pobres atuação ou perturbação: • O aumento do número de fornecedores que satisfaçam os alvos dentro da contrato • Redução do número de violações de metas contratuais. Serviços de apoios e os seus objectivos alinhados com as necessidades do negócio e metas: • Aumento do número de serviços e revisões contratuais mantidas com fornecedores • Aumento do número de fornecedores e contratuais metas alinhadas com SLA e metas SLR. Disponibilidade de serviços não é comprometida pela fornecedor desempenho: • Redução do número de violações de serviços causada por fornecedores • Redução do número de violações de serviços ameaçados causados por fornecedores. Propriedade clara e sensibilização para as questões de fornecedores e contratos: • Aumento do número de fornecedores com os gestores nomeados fornecedor • Aumento no número de contratos com gestores de contrato nomeados.

4.7.8 Gestão da Informação Todas as informações exigidas pela Gestão de Fornecedores deve ser contido dentro da SCD. Isto deve incluir todas as informações relativas aos fornecedores e contratos, bem como todas as informações relativas à operação dos serviços de apoio prestados pelos fornecedores. As informações relativas a estes serviços de apoios também deve estar contido no interior da Portfólio de Serviços, Em conjunto com as relações com todos os outros serviços e componentes. Esta informação deve ser integrado e mantido em alinhamento com todos os outros sistemas de TI de gestão da informação, em especial o Portfólio de Serviços e do. CMS

4.7.9 Desafios, Fatores Críticos de Sucesso e riscos Gestão de Fornecedores enfrenta muitos desafios, que podem incluir alguns dos seguintes: •

Continuamente mudando de negócios e de TI precisa e gestão da mudança significativa em paralelo com a entrega de serviço existente

ITIL V3 - Service Design - Página:

303 de 477

•

• • • •

• • • • • •

•

Trabalhar com um contrato de não-ideal imposta, um contrato que tem metas pobres ou termos e condições, ou definição pobre ou inexistente de serviço ou fornecedor metas de desempenho Questões de legado, especialmente com serviços terceirizados recentemente Perícia insuficiente retida dentro da organização Sendo amarrado em contratos de longo prazo, sem possibilidade de melhoria, que têm penalidades punitivas para saída precoce Situações em que o fornecedor depende da organização no cumprimento da prestação de serviços (por exemplo, para uma alimentação de dados) pode levar a problemas mais responsabilidade para pobre atuação Disputas sobre acusações Interferência por qualquer uma das partes na disputa da outra operação Ser pego em um modo de combate a incêndios por dia, perdendo a abordagem proactiva Comunicação - não interagir bastante com freqüência suficiente ou rápido ou concentrando-se nas questões certas Conflitos de personalidade Uma parte usando o contrato em detrimento da outra parte, resultando em ganha-perde mudanças, em vez de conjuntos ganha-ganha mudanças Perder a estratégico perspectiva, focando operacional questões, causando uma falta de foco em relação estratégica objetivos e questões.

Os elementos-chave que podem ajudar a evitar as questões acima são: • • • • • •

Claramente contrato escrito, bem definido e bem gerida Mutuamente benéfica relação Claramente definida (e comunicado) papels e responsabilidades de ambos os lados Interfaces de bons e comunicações entre as partes Bem definido Serviço de Gestão de processos de ambos os lados Seleção de fornecedores que obtiveram certificado contra certificações internacionalmente reconhecidas, tais como ISO 9001, ISO / IEC 20000, etc

Os CSFs principais para o Gestão de Fornecedores processo são os seguintes: • • • •

Empresas protegido de pobres fornecedor desempenho ou interrupção Serviços de apoios e os seus objectivos alinhados com as necessidades do negócio e metas Disponibilidade de serviços não é comprometida pelo desempenho fornecedor Propriedade clara e consciência do fornecedor e questões contratuais.

As principais áreas de risco associado Gestão de Fornecedores incluem:

ITIL V3 - Service Design - Página:

304 de 477

• • • • •

• • • • •

Falta de compromisso do negócio e gerência sênior para o Gestão de Fornecedores processo e procedimentos Falta de informação adequada sobre futuros negócios e políticas de TI, planos e estratégias Falta de recursos e / ou orçamento para o processo ISM Legado de mal escrito e acordado contratos que não estão na base ou e às necessidades de negócio ou de SLA e metas SLR Fornecedores concordar com metas e nível de serviços em contratos que são impossíveis de cumprir, ou fornecedores falham ou são incapazes de satisfazer os termos e condições do contrato Fornecedor pessoal ou organizacional cultura não estão alinhados ao do provedor de serviços ou se a actividade Os fornecedores não são cooperativos e não estão dispostos a participar e apoiar a necessária Gestão de Fornecedores processo Fornecedores são tomados e relacionamentos, pessoal e contratos são alterados As exigências do fornecedor corporativa e procedimentos contratuais são excessivas e burocrática Pobres processos financeiros corporativos, como compras e compra, não am Gestão de Fornecedores bem.

ITIL V3 - Service Design - Página:

305 de 477

5 Serviços de design de tecnologia actividades relacionadas com o Este capítulo considera as atividades relacionadas à tecnologia de engenharia de requisitos e da desenvolvimento de arquiteturas de tecnologia. As arquiteturas de tecnologia abrangem aspectos de Design de Serviços nas seguintes áreas: • • • •

Gestão de infra-estrutura Gestão Ambiental Dados e Gestão de Informação Aplicação de Gestão de.

ITIL V3 - Service Design - Página:

306 de 477

5,1 Engenharia de requisitos Engenharia de requisitos é a abordagem pela qual o rigor suficiente é introduzido no processo de entender e documentar o negócio e usuário'S requisitos e assegurar a rastreabilidade de mudanças para cada exigência. Este processo compreende as fases de elicitação, análise (que realimenta a eliciação) e validação. Tudo isso contribui para a produção de um rigoroso requisitos completos documento. O núcleo deste documento é um repositório de requisitos individuais que é desenvolvido e gerenciado. Muitas vezes, estes requisitos são instigadas pela TI, mas, finalmente, eles precisam ser documentadas e concordou com o negócio. Existem muitos diretrizs em engenharia de requisitos, incluindo a prática recomendada para Requisitos de Software Especificaçãos (IEEE 830), Corpo de Engenharia de Software do Conhecimento (SWEBOK), CMMI e do V-Model, que é descrito em detalhes no Transição de Serviço publicação.

5.1.1 Diferentes tipos de requisitos Um pressuposto fundamental aqui é que a análise da corrente e da necessária processo de negócioresultados es em requisitos funcionais conheceu através De serviços de TIs (compreendendo aplicaçãos, dados, infra-estrutura, ambiente e habilidades de e). É importante notar que não são comumente dito ser de três tipos principais de requisitos para qualquer sistema - requisitos funcionais, de gestão e operacional requisitos, e usabilidade requisitos. • •

•

Os requisitos funcionais são aqueles especificamente necessária para ar um negócio particular função. De gestão e operacional requisitos (por vezes referido como requisitos não-funcionais) abordar a necessidade de um serviço ágil, seguro e disponível, e lidar com questões como a facilidade de desenvolvimento, Operacionalidade, as necessidades de gestão e segurança. Usabilidade requisitos são os que abordam o "look and feel" necessidades do usuário e resultam em características do serviço que facilitam a sua facilidade de uso. Esse tipo de requisito é muitas vezes visto como parte de gestão e as necessidades operacionais, mas para os fins desta seção que será tratado separadamente.

5.1.1.1 Os requisitos funcionais

Os requisitos funcionais descrevem as coisas que um serviço se destina a fazer, e pode ser expressa como tarefas ou funções que o componente é necessário para executar. Uma abordagem para especificação de requisitos funcionais é através de métodos como um diagrama de contexto do sistema ou um caso de

ITIL V3 - Service Design - Página:

307 de 477

uso modelo. Outras abordagens mostram como as entradas estão a ser transformados em saídas (fluxo de dados ou diagramas de objeto) e as descrições textuais. Um diagrama de contexto do sistema, por exemplo, captura todas as trocas de informações entre, por um lado, o serviço de TI e seu meio ambiente e, por outro, as fontes ou destinos de dados usados pelo serviço. Essas trocas de informação e fontes de dados representam restrições sobre o serviço em desenvolvimento. Um modelo de caso de uso define um conjunto goal-oriented de interações entre atores externos e os serviços em questão. Atores são pessoas de fora do serviço que interagir com o serviço. Um ator pode refletir uma classe de usuário papels que os usuários podem jogar, ou de outros serviços e seus requisitos. O principal objectivo da modelagem caso de uso é o de estabelecer o limite do sistema proposto e totalmente indicar as capacidades funcionais para ser entregue ao usuários. Os casos de uso também são úteis para estabelecer a comunicação entre desenvolvedores de negócios e aplicação. Eles fornecem uma base para o dimensionamento e a definição de alimentar usabilidade requisitos. Os casos de uso definir todos os cenários que um aplicação tem que apoiar e pode, portanto, ser facilmente expandido em casos de teste. Desde que os casos de uso descrevem a funcionalidade de um serviço em um nível que é compreensível tanto para negócios e de TI, eles podem servir como um veículo para especificar os elementos funcionais de uma SLA, Tal como o negócio real entregas a partir do serviço. Um nível "abaixo" do caso de uso e o diagrama de contexto, muitas outras técnicas de modelação pode ser aplicado. Esses modelos representam as características estáticas e dinâmicas dos serviços em desenvolvimento. Um modelo conceitual de dados (seja chamado de objeto ou dados) descreve os diferentes 'objetos' no serviço, sua mútua relaçãos e a sua estrutura interna. Dinâmica do serviço pode ser descrita usando modelos de estado (por exemplo, estado transição diagramas) que mostram os vários estados das entidades ou objetos, juntamente com eventos que podem causar estado mudars. Interações entre os componentes de aplicação diferentes podem ser descritos através de diagramas de interação (por exemplo, diagramas de interação de objetos). Ao lado de um processo maduro requisitos de modelagem, ferramentas CASE pode ajudar na obtenção e manutenção desses modelos consistente, correta e completa. 5.1.1.2 Gestão e requisitos operacionais

De gestão e operacional requisitos (ou requisitos não-funcionais) são usados para definir os requisitos e as restrições ao De serviços de TI. Os requisitos de servir de base para os primeiros sistemas de colagem e de serviço e as estimativas de custar, E pode apoiar o avaliação da viabilidade do serviço de TI

ITIL V3 - Service Design - Página:

308 de 477

proposto. Gestão e operacional requisitos também devem incentivar os desenvolvedores a dar uma visão mais ampla da projeto metas. Categorias de requisitos de gestão e operacionais incluem: • • • • • • • • • • •

Gerenciabilidade: Será que funciona? Será que não? Como é que falha? Eficiência: Quantas recursos é que consumir? Disponibilidade e confiança: Como confiável que é preciso para ser? Capacidade e atuação: Qual a capacidade que precisamos? Segurança: O que classificação de segurança é necessária? Instalação: Quanto esforço é necessário para instalar o aplicação? É usando a instalação automatizada procedimentos? Continuidade: Qual o nível de resiliência e recuperação é necessária? Controlabilidade: Pode ser monitorado, gerenciado e ajustado? Manutenibilidade: Como bem pode a aplicação ser ajustada, corrigido, mantido e mudado para necessidades futuras? Operacionalidade: Será que os aplicativos perturbar outras aplicações em suas funcionalidades? Mensurabilidade e reportabilidade: Podemos medir e informar sobre todos os aspectos necessários da aplicação?

Os requisitos de gestão e operacional pode ser usado para prescrever o qualidade atributos do aplicação sendo construída. Estes atributos de qualidade pode ser utilizada para a concepção teste planos para testar os aplicativos no observância às necessidades de gestão e operacional. 5.1.1.3 Os requisitos de usabilidade

O propósito principal de usabilidade requisitos é assegurar que o serviço atende as expectativas do seu usuários no que respeita à sua facilidade de uso. Para alcançar este objectivo: • •

Estabelecer atuação padrões para avaliações de usabilidade Definir teste cenários para usabilidade planos de testes e testes de usabilidade.

Como a istração e os requisitos operacionais, requisitos de usabilidade também podem ser usados como os atributos de qualidade dos planos de teste para testar o projeto aplicaçãos sobre a sua conformidade com os requisitos de usabilidade.

5.1.2 Requisitos para apoio - a visão de usuário Os usuários têm formalmente definida papels e atividades como usuário representantes na definição de requisitos e testes de aceitação. Eles devem

ITIL V3 - Service Design - Página:

309 de 477

participar activamente na identificação de todos os aspectos do serviço, incluindo as três categorias acima, e também em: • •

Usuário procedimentos de treinamento e instalações Atividades de apoio e Service Desk procedimentos.

5.1.3 Requisitos técnicas de investigação Há uma série de técnicas que podem ser utilizadas para investigar situações de negócios e elicitar os requisitos de serviço. Por vezes, o clientes e a negócio não estão completamente certos do que realmente são suas necessidades e vai precisar de alguma ajuda e inspiração do designer ou coletor requisitos. Este deve ser preenchido de forma sensível para garantir que ele não é visto como TI ditar os requisitos de negócios novamente. As duas técnicas mais utilizadas são entrevistas e workshops, mas estes são geralmente complementados por outras técnicas, como a observação e cenários. 5.1.3.1 Entrevistas

A entrevista é uma ferramenta fundamental e pode ser vital para a realização de várias objetivos, tais como: • • •

Fazer o contato inicial com a chave das partes interessadass e estabelece uma base para o progresso Construção e desenvolvimento de relacionamento com diferentes usuários e gerentes Aquisição de informações sobre a situação da empresa, incluindo questões e problemas.

Há três áreas que são consideradas durante as entrevistas: • • •

Atual processo de negócioes que precisam ser cumpridas em todos os sistemas de novos negócios e serviços Problemas com as operações atuais que precisam ser abordadas Novos recursos exigido do novo sistema de negócio ou serviço e qualquer apoio De serviços de TI.

A entrevista processo é melhorada quando o entrevistador tem preparado minuciosamente como isso economiza tempo, evitando explicações desnecessárias e demonstra interesse e profissionalismo. A estrutura clássica de questionamento "Por que, O que, Quem, Quando, Onde, Como" oferece uma excelente estrutura para preparação para entrevistas. É igualmente importante para encerrar formalmente a entrevista: •

Resumindo os pontos cobertos e das acções acordadas

ITIL V3 - Service Design - Página:

310 de 477

• •

Explicando o que acontece a seguir, tanto após a entrevista e além Pedir ao entrevistado como qualquer contato deve ser feito.

É sempre uma boa idéia para escrever as notas da entrevista o mais rápido possível - de preferência, de imediato e, geralmente, no dia seguinte. As vantagens da entrevista são: • • • • • • •

Constrói uma relação com os usuários Pode fornecer informações importantes Oportunidade para entender pontos de vista e atitudes diferentes em todo o usuário grupo Oportunidade para investigar novas áreas que surgem Conjunto de exemplos de documentos e relatórios Valorização de fatores políticos Estudo do ambiente em que o novo serviço operar.

As desvantagens da entrevista são: • •

Caro em tempo decorrido Nenhuma oportunidade para resolução de conflitos.

5.1.3.2 Workshops

Workshops proporcionar um fórum em que as questões possam ser discutidas, os conflitos resolvidos e requisitos provocou. Workshops são especialmente importantes quando o tempo e orçamentos são fortemente constrangido, diversos pontos de vista precisam ser negociou e iterativo e incremental de vista de serviço desenvolvimento está sendo tomada. As vantagens do workshop são: •

• • •

Obter uma visão ampla da área sob investigação - com um grupo de das partes interessadass em uma sala vai permitir uma compreensão mais completa dos problemas e problemas Aumente a velocidade e produtividade - é muito mais rápido para ter uma reunião com um grupo de pessoas do que entrevistando-os um por um Obter buy-in e aceitação para o serviço de TI Obter uma visão de consenso - se todos os das partes interessadass estão envolvidos, a chance deles tomar posse dos resultados é melhorada.

Existem algumas desvantagens, incluindo: •

Pode ser demorada para organizar - por exemplo, nem sempre é fácil de obter todas as pessoas necessárias em conjunto ao mesmo tempo,

ITIL V3 - Service Design - Página:

311 de 477

• •

Pode ser difícil de obter todos os participantes com o nível exigido de autoridade Pode ser difícil conseguir uma combinação de negócios e operacional as pessoas a compreender as diferentes necessidades.

O sucesso ou falha de uma sessão do workshop depende, em grande parte, no trabalho preparatório pelo facilitador e promotor de negócios para a oficina. Eles devem ar o tempo antes do evento planejando as seguintes áreas: • •

•

•

O objetivo da oficina - este tem de ser um objetivo que pode ser alcançado dentro das limitações de tempo do workshop. Quem vai ser convidado para participar do workshop - que é importante que todos das partes interessadass interessados no objetivo deve ser convidado a participar ou ser representada. A estrutura da oficina e técnicas a serem utilizadas. Estes precisam ser orientados no sentido de atingir o objectivo definido, por exemplo, levantamento de requisitos ou priorização, e deve tomar as necessidades dos participantes em conta. Arranjar um local adequado - o que pode estar dentro da organização, Mas é melhor usar um local "neutro" para fora do escritório.

Durante o workshop, um facilitador precisa garantir que as questões são discutidas, as visões são arejadas e progresso é feito no sentido de alcançar o objetivo estabelecido. A registro precisa ser mantida dos pontos-chave que emergem da discussão. No final da oficina, o facilitador precisa resumir os pontos principais e ações. Cada acção deve ser atribuído a um proprietário. Existem duas categorias principais de técnica necessários para um workshop de requisitos - técnicas de descoberta e técnicas de documentação, como mostrado na figura 5.1.

ITIL V3 - Service Design - Página:

312 de 477

Figura 5.1 técnicas Requisitos oficina 5.1.3.3 Observação

Observando o local de trabalho é muito útil para obter informações sobre o negócio ambiente e o trabalho práticas. Isto tem duas vantagens: • •

Uma melhor compreensão dos problemas e dificuldades enfrentados pela empresa usuários Ele vai ajudar a conceber soluções viáveis que são mais susceptíveis de ser aceitável para o negócio.

Por outro lado, sendo observado pode ser um pouco irritante, eo velho ditado "você muda quando está sendo observado" tem de ser tido em conta em sua abordagem e descobertas. Observação formal envolve assistindo uma tarefa específica a ser realizada. Existe o perigo de ser mostrado apenas o 'front-história ", sem qualquer do cotidiano variaçãos, mas ainda é uma ferramenta útil. 5.1.3.4 Análise de Protocolo

Análise protocolo é simplesmente recebendo os usuários a executar uma tarefa, e para eles para descrever cada o como realizá-la. 5.1.3.5 Shadowing

Sombreamento envolve seguindo um usuário durante um período tal como um dia para saber sobre um determinado trabalho. É uma forma poderosa de entender uma função de usuário em particular. Pedindo explicações de como o ITIL V3 - Service Design - Página:

313 de 477

trabalho é feito, ou o fluxo de trabalho, esclarece alguns dos aspectos já assumidos. 5.1.3.6 Análise de Cenário

Análise de Cenário é essencialmente contando a história de uma tarefa ou transação. Seu valor é que ele ajuda a usuário que é incerto o que é necessário de um novo serviço para perceber isso mais claramente. Cenários também são úteis quando se analisa ou redesenhar processo de negócioes. Um cenário vai traçar o curso de uma transação a partir de um gatilho de negócios inicial por cada um dos os necessários para alcançar um bem-sucedido resultado. Cenários fornecem um quadro para descobrir caminhos alternativos que podem ser seguidos para completar o transação. Isto é extremamente útil na elicitação de requisitos e análise, porque situações da vida real, incluindo as circunstâncias excepcionais, são debatidas. Cenários oferecem vantagens significativas: •

• • •

Eles forçam o usuário para incluir todas as etapas, para que não haja tomadas como certas elementos eo problema do conhecimento tácito é dirigida Ao ajudar o usuário visualizar todas as contingências, eles ajudam a lidar com a incerteza sobre os futuros sistemas e serviços Um grupo de oficina de refino de um cenário vai identificar os caminhos que não se adaptam a empresa cultura Eles fornecem uma ferramenta para preparar teste scripts.

As desvantagens de cenários é que eles podem consumir muito tempo para se desenvolver, e alguns cenários podem se tornar muito complexo. Quando for este o caso, é mais fácil de analisar se cada um dos caminhos principais alternativas é considerada como um quadro distinto. Uma abordagem popular para descrições de cenários documentam é desenvolver descrições de casos de uso para apoiar caso de uso diagramas. No entanto, há também um número de métodos gráficos de documentar a situação, tal como storyboards, diagramas de atividade, tarefa modelos e diagramas de árvore de decisão. 5.1.3.7 prototipagem

Prototipagem é uma técnica importante para suscitar, análise, demonstração e validação de requisitos. É difícil para os usuários a prever o novo serviço antes que seja realmente construído. Protótipos oferecer uma maneira de mostrar a usuário como o novo serviço pode funcionar e os modos pelos quais ele pode ser usado. Se um usuário está claro o que eles precisam do serviço para fazer

ITIL V3 - Service Design - Página:

314 de 477

para eles, utilizando um protótipo muitas vezes libera blocos para pensar e podem produzir uma nova onda de exigências. Abordagens incrementais e iterativos para o serviço desenvolvimento, Tais como o Método Dynamic Systems Development (DSDM), utilize prototipagem evolutiva como uma parte integrante do seu desenvolvimento ciclo de vida. Há uma série de abordagens para a construção de protótipos. Eles podem ser construídas utilizando uma aplicação ambiente de desenvolvimento de modo que eles espelham a serviço, As imagens das telas e navegações podem ser construídas usando software de apresentação, ou podem simplesmente ser 'mock-ups' no papel. Existem dois métodos básicos de prototipagem: • •

O descartável mock-up, que só é usado para demonstrar a aparência A implementação incremental, em que o protótipo é desenvolvido para o sistema final.

É importante seleccionar conscientemente o que é para ser usada, caso contrário, existe o perigo de que a má qualidade maquete torna-se a base para o sistema real, causando problemas mais tarde. Há uma forte ligação entre cenários e protótipos porque os cenários podem ser usados como base para o desenvolvimento de protótipos. Além de confirmar os requisitos dos usuários, prototipagem muitas vezes podem ajudar os usuários a identificar novas necessidades. Protótipos são usados com sucesso para: • • • •

Esclarecer qualquer incerteza por parte dos desenvolvedores de serviços e confirmar a usuário que o que eles pediram foi entendido Abra o usuário se às novas exigências, como eles entendem o que o serviço será capaz de fazer para apoiá-los Mostrar aos usuários o "look and feel" do serviço proposto e suscitar usabilidade requisitos Validar os requisitos e identificar eventuais erros.

Problemas potenciais incluem: • •

Iteração infinita Uma visão que, se o protótipo funciona, o serviço completo pode estar pronto amanhã.

5.1.3.8 Outras técnicas

Outras técnicas que podem ser utilizadas, incluem:

ITIL V3 - Service Design - Página:

315 de 477

•

•

•

Questionários: Pode ser útil para obter uma quantidade limitada de informações de um grande número de pessoas ao entrevistar todos eles não seria prático ou econômico. Especiais registros de propósito: Técnica envolve os usuários a manter um registro sobre um assunto específico ou tarefa. Por exemplo, eles poderiam manter um registro simples portão cinco-bar sobre a frequência com que eles precisam para transferir chamadas telefônicas - que poderia fornecer informações sobre os problemas com este processo de negócio. Amostragem atividade: É uma forma muito mais quantitativa de observação e pode ser usado quando é necessário saber como as pessoas gastam seu tempo - por exemplo, quanto tempo é gasto em faturamento? Quanto tempo é gasto em reconciliar os pagamentos? Quanto tempo é gasto em resolvendo consultas?

5.1.4 Problemas com a engenharia de requisitos Requisitos, vistas por usuários como o bit de um simples desenvolvimento de novos serviços, são, na verdade, o aspecto mais problemático, e ainda o tempo alocado é muito menor do que para as outras fases. Prazos apertados e orçamentos apertados - tanto o resultado de restrições sobre o negócio - Pressões lugar no desenvolvimento equipe para entregar um serviço. O problema é que, sem o devido tempo para entender e definir os requisitos corretamente, o serviço que é entregue na hora pode não ser o serviço que a empresa achou que estava pedindo. Estudos realizados em projeto de TI falhas contar uma história comum. Muitos dos projetos e insatisfatória De serviços de TIs sugerem as seguintes conclusões: • •

• •

Uma grande proporção de erros (mais de 80%) são introduzidos na fase de requisitos Muito poucos defeitos (menos de 10%) são introduzidos em projeto e desenvolvimento - os desenvolvedores estão desenvolvendo as coisas direito, mas muitas vezes não desenvolver as coisas certas Na maioria das vezes é alocado projecto para o desenvolvimento e as fases de teste do projecto Menos de 12% do tempo de projecto é atribuído aos requisitos.

Estes resultados são particularmente importantes porque o custo de correção de erros nos requisitos aumenta dramaticamente o mais tarde no ciclo de desenvolvimento que eles são encontrados. Um dos principais problemas com a engenharia de requisitos é a falta de habilidade detalhada e compreensão global da área quando as pessoas usam

ITIL V3 - Service Design - Página:

316 de 477

isso. Se realizada com precisão, o trabalho pode integrar os requisitos de várias áreas em algumas perguntas. Outros problemas típicos com os requisitos foram identificados como: • • • • • • • • • • •

•

Falta de relevância para o objetivos do serviço A falta de clareza na redação Ambiguidade Duplicação entre os requisitos Os conflitos entre os requisitos Requisitos expressos de forma que é difícil de avaliar se ou não foram alcançados Requisitos que assumem uma solução, em vez de declarar o que é para ser entregue pelo serviço Incerteza entre os usuários sobre o que eles precisam do novo serviço Omitindo usuários para identificar as necessidades Níveis inconsistentes de detalhe Um pressuposto que o pessoal do usuário e de TI têm conhecimento de que eles não possuem e, portanto, não garantir que há um entendimento comum Requisitos fluência - a adição gradual de requisitos aparentemente pequenas, sem ter o esforço extra em conta no projeto plano.

Outro problema é a aparente incapacidade por parte dos usuários de articular claramente o que é que gostaria que o serviço fazer por eles. Muitas vezes, eles são impedidos de fazê-lo porque a natureza do requisito é explicado em uma declaração simples. 5.1.4.1 Resolução de problemas de engenharia requisitos

Definindo os atores Há alguns participantes que devem ter parte nos requisitos processo. Eles representam três grandes das partes interessadas grupos: • • •

O negócio A comunidade de usuários A equipe de desenvolvimento do serviço.

O usuário comunidade deve ser representado pelo especialista do domínio (ou objecto de especialista) e usuários finais. Lidar com o conhecimento tácito Ao desenvolver um novo serviço, os usuários vão ar para nós o seu conhecimento explícito conhecimento, ou seja, de procedimentos e os dados

ITIL V3 - Service Design - Página:

317 de 477

que está na frente da cabeça e que eles podem facilmente articular. Um grande problema quando provocando requisitos é o do conhecimento tácito, ou seja, os outros aspectos do trabalho que um usuário é incapaz de articular ou explicar. Alguns elementos comuns que causam problemas e mal-entendidos são: • •

•

•

•

•

•

Competências - explicando como realizar ações com palavras por si só é extremamente difícil. Tomadas como certas informações - os usuários de negócios, mesmo experientes e perito pode deixar de mencionar informações ou esclarecer a terminologia, eo analista pode não perceber que o questionamento é necessária. Front-story/back-story - esta questão diz respeito a uma tendência para enquadrar uma descrição do trabalho atual práticas, ou um local de trabalho, a fim de dar uma visão mais positiva do que é realmente o caso. Conhecimento dos sistemas de futuro - se o estudo é para um desenvolvimento de novos serviços, com nenhuma experiência ou conhecimento existente na organização, Como pode a prospectiva usuários sabem o que querem? A dificuldade de uma pessoa de fora assumindo uma linguagem comum para o discurso e as normas comuns de comunicação. (Se não tem isso, então o escopo por falsidade da situação pode crescer consideravelmente.) Compreensão intuitiva, geralmente nascem de uma experiência considerável. Os tomadores de decisão são muitas vezes pensado para seguir um caminho lógico, linear de inquérito ao fazer suas decisões. Na realidade, porém, como melhorou tomada de decisão habilidades e conhecimentos são adquiridos, o caminho linear é muitas vezes abandonado em favor do reconhecimento de padrões intuitiva. Organizacional cultura - Sem uma compreensão da cultura de uma organização, o exercício requisitos pode ser falho.

Comunidades de prática são grupos distintos de trabalhadores - talvez relacionadas por tarefa, por departamento, por localização geográfica ou algum outro fator - que têm seus próprios conjuntos de normas e práticas, diferentes de outros grupos dentro da organização e da organização como um todo. Tácito

Explícito

Individual

Habilidades, valores, tomado como certo intuição,

Tarefas descrição do trabalhos, metas, volumes e frequências

Corporativo

Normas, para trás-história, cultura, Comunidades de prática

Procedimentos, guias de estilo, processos, compartilhamento de conhecimento

ITIL V3 - Service Design - Página:

318 de 477

Tabela 5.1 Engenharia de requisitos - tácito e conhecimento explícito

Exemplo níveis de conhecimento tácito e explícito: Técnica

O conhecimento explícito

O conhecimento tácito

Entrevistando

Habilidades

Necessidades futuras

X

Sombreamento

X

Workshops

X

Prototipagem Análise de cenário

X

Análise de protocolo

X

Tabela 5.2 Engenharia de requisitos, exemplos de conhecimento tácito e explícito (Maiden e Rugg, 1995)

5.1.5 Documentação de requisitos Os requisitos documento é o coração do processo e pode ter um número de formas. Normalmente, o documento vai incluir um catálogo de requisitos, com cada requisito documentado usando um modelo padrão. Um ou mais modelos mostrando aspectos específicos, tais como o processamento de dados ou requisitos, poderá complementar este catálogo. Antes que eles são formalmente entrou para o catálogo, as exigências são sujeitos ao escrutínio cuidadoso. Este controlo pode envolver organizar os requisitos em grupos e verificar que cada exigência é "bem formado". Uma vez que o documento é considerado como sendo completa, deve ser analisado por representantes comerciais e confirmada como sendo uma indicação verdadeira dos requisitos, neste ponto do tempo. Durante esta fase, os revisores analisar os requisitos e pergunta se eles estão bem definida, clara e completa. Como descobrimos os requisitos de nossos vários usuários, é preciso documentá-los. Este é o melhor feito em duas fases distintas - a construção da lista de requisitos e, mais tarde, o desenvolvimento de um catálogo de requisitos organizado. A lista tende a ser um documento informal e pode ser apresentada como quatro colunas, como mostrado na Tabela 5.3.

ITIL V3 - Service Design - Página:

319 de 477

Requisitos Fonte Comentários Nível de detalhe Tabela 5.3 lista de requisitos

Cada requisito na lista deve ser verificado para ver se ele está ou não bem formado e A SMART (Específico, mensurável, atingível, realista e oportuno). Ao verificar o indivíduo ea totalidade dos requisitos, a lista a seguir pode ser usado: • • • • • • • •

São os requisitos, como capturados, inequívocas? É o significado claro? O requisito é alinhado com o desenvolvimento de serviços e negócios objetivos, ou é irrelevante? É a exigência razoável, ou seria caro e demorado para satisfazer? Fazer qualquer conflito requisitos um com o outro de tal forma que apenas um pode ser implementado? Será que eles implicam uma solução ao invés de um estado de necessidade? São eles atômica, ou são realmente vários requisitos agrupados em uma entrada? Se sobrepõem várias exigências ou duplicar o outro?

Existem várias potenciais resultados do exercício: • • • •

Aceite o exigência como está Re palavra-requisito para remover o jargão e ambigüidade Mesclar repetido / sobreposição de requisitos Tome requisitos obscuros e ambíguos de volta para a usuários para esclarecimentos.

5.1.5.1 O Catálogo de Requisitos

O Catálogo de Requisitos é o repositório central de requisitos dos usuários, e todos os requisitos devem ser documentados aqui, após a análise da lista acima definidos. O Catálogo de Requisitos deve fazer parte do Pipeline Serviço geral dentro da geral Portfólio de Serviços. Cada requisito de que foi analisado está documentado através de um modelo padrão, tal como a mostrada na Tabela 5.4. De serviços de TI

Autor

ID exigência

Data

Nome exigência

Fonte

Proprietário Prioridade Descrição Requisito Funcional

ITIL V3 - Service Design - Página:

320 de 477

Processo de negócio

Gestão e Operacional e Requisitos de Usabilidade

Descrição

Justificação Documentos relacionados Requisitos relacionados Comentários Resolução Nenhuma versão

Histórico de Alterações pedido de Mudança Data

Tabela 5.4 modelo de Requisitos

As entradas de chave no molde são as seguintes: •

•

•

•

ID exigência - Esta é uma identificação única que nunca muda e é usado para rastreabilidade - por exemplo, para fazer referência ao exigência em documentos de projeto, teste especificaçãos ou implementadas código. Isso garante que todos os requisitos foram cumpridos e que todas as funções implementadas são baseados em necessidades. Fonte - A área de negócios ou usuários que solicitou a exigência ou a documento onde a exigência foi levantada. A gravação da fonte de um requisito ajuda a garantir que as perguntas podem ser respondidas ou a necessidade pode ser re-avaliada no futuro, se necessário. Proprietário - O usuário que aceita a propriedade da exigência individual vai concordar que está formulado e documentado corretamente, e vai assiná-lo fora em testes de aceitação quando satisfeito. Prioridade - O nível de importância e necessidade de uma exigência. Normalmente, tais como abordagens MoSCoW são utilizados, onde a seguinte interpretação do mnemônico se aplica: • Deve ter - Um requisito fundamental, sem o qual o serviço não tem valor. • Deve ter - Um requisito importante que deve ser entregue, mas, onde o tempo é curto, poderia ser adiada para uma entrega futura. Isto deve haver um atraso curto prazo, mas o serviço ainda teriam valor sem eles. • Poderia ter - Um requisito que não seria benéfico para incluir, se não custa muito ou demorar muito tempo para entregar, mas não é central para o serviço. • Não terá (Mas quero da próxima vez) - a exigência de que serão necessários no futuro, mas não é necessário para esta entrega. Em um serviço futuro liberar, Esta exigência pode ser atualizado para um 'must have'.

ITIL V3 - Service Design - Página:

321 de 477

O seguinte deve ser claramente acordados durante esta priorização atividade: • •

• • •

•

•

•

•

•

Prioridades de requisitos podem e devem mudar ao longo da vida de um desenvolvimento de serviços projeto. "Deve ter" requisitos precisam ser cuidadosamente considerado, pois, se não forem entregues dentro do estágio inicial do projeto, que pode ser impossível de implementar mais tarde. Os requisitos são, invariavelmente, mais difícil e mais caro para encontrar mais tarde no Ciclo de Vida de Serviço. Não são apenas os requisitos funcionais que podem ser 'must haves' alguns dos requisitos de gestão e operacional deve ser "must haves". Exigência Descrição - uma descrição sucinta do requisito. Uma abordagem é útil para descrever o requisito usando a seguinte estrutura: • Ator (ou usuário papel) • Expressão verbal • Objeto (frase de substantivo ou substantivo). Onde a exigência incorpora regras de negócio complexas ou dados validação, Mesa de decisão ou árvore de decisão pode ser mais útil para definir regras de negócio complexas, enquanto dados validação regras pode ser definido de um repositório. Se uma técnica complementar é usada para especificar ou modelar o requisito, deve haver uma referência cruzada ao documento relacionado. Processo de negócio - Uma frase simples de agrupar requisitos que am uma específica atividade, Tais como vendas, estoque, atendimento ao cliente, e assim por diante. Justificação - não todos os requisitos que são solicitados serão cumpridos. Isto pode ser devido a restrições de tempo e orçamento, ou pode ser porque o requisito é abandonado em favor de um requisito conflitantes. Muitas vezes, a exigência não for cumprida, porque acrescenta pouco valor para a negócio. A justificativa apresenta os motivos para solicitar a exigência. Requisitos relacionados - requisitos podem ser relacionados entre si por várias razões. Às vezes, há uma ligação entre a funcionalidade exigida pelos requisitos ou um requisito de alto nível é clarificada por uma série de requisitos mais detalhados. Mudar a história - As entradas nesta seção fornecem uma registro de todo o mudars que afetaram a exigência. Isso é necessário para o gerenciamento de configuração e fins de rastreabilidade.

5.1.5.2 documentação de requisitos completo

Um requisitos eficazes documento deve compreender os seguintes elementos: •

Um glossário de termos, para definir cada termo organizacional usado dentro do documento de requisitos. Isso vai ajudar a gerir o problema do

ITIL V3 - Service Design - Página:

322 de 477

• • •

jargão local e irá esclarecer sinônimos e homônimos para qualquer pessoa usando o documento Um escopo modelo, Tal como um diagrama de contexto do sistema O Catálogo de Requisitos, idealmente mantidos como parte de uma estratégia global Portfólio de Serviços Modelos de apoio, como processo de negócio modelos, diagramas de fluxo de dados e diagramas de interação.

Gerenciamento das mudanças feitas na documentação Mudanças podem acontecer porque: • • • •

O escopo do novo serviço alterou através de restrições orçamentárias O serviço deve cumprir nova regulamentação ou legislação Mudanças nas prioridades de negócios foram anunciados Stakeholders ter entendido um requisito melhor depois de uma análise detalhada - por exemplo, usando cenários ou protótipos - e alterado o original exigência em conformidade.

Há uma série de ferramentas de apoio especializados no mercado para apoiar os processos de requisitos. Estas são algumas vezes chamado CARE (Computer Aided Engenharia de Requisitos) ou CASE (Computer Aided Software Engineering). As características incluem: • • • • • •

Manter referências cruzadas entre os requisitos Armazenar documentação de requisitos Gerenciamento das mudanças feitas na documentação de requisitos Gerenciando versãos da documentação de requisitos Produzir requisitos formatados especificação documentos do banco de dados Documentos garantindo sido entregue por um projeto de solução são adequados para ativar o e.

5.1.6 Requisitos e terceirização O objetivo é selecionar soluções padrão embalados sempre que possível para atender às necessidades de serviço. No entanto, se os requisitos de TI estão a ser adquiridos de prateleira, desenvolvida in-house ou externa, todas as actividades acima para a produção de um especificação de requisitos de negócios são feitas em casa. Desenvolvimento de serviços de TI muitos contratos assumir que é possível saber quais são os requisitos no início, e que é possível produzir um especificação que expressa de forma inequívoca os requisitos. Para todos, mas os mais simples serviços este raramente é verdade. Análise de requisitos é um processo iterativo - os requisitos serão alterados durante o período da aplicação e serviços estão sendo desenvolvidos. Isto irá

ITIL V3 - Service Design - Página:

323 de 477

exigir usuário envolvimento em todo o desenvolvimento processo, como no DSDM e outros ágeis 'abordagens. 5.1.6.1 requisitos típicos cenários de terceirização

Abordagens típicas de contrato para o desenvolvimento de sistemas de TI para ser entregue em e de um De serviços de TI são os seguintes: •

•

Requisitos de baixo nível especificação - a fronteira entre "cliente" e fornecedor é feita entre os requisitos detalhados especificação e quaisquer atividades de projeto. Todos os requisitos que têm impacto no usuário foram especificadas em detalhe, dando o prestador de um alvo aplicação muito clara e precisa. No entanto, há um aumento do esforço de especificação, eo valor acrescentado do fornecedor é aos aspectos menos difíceis de desenvolvimento. Requisitos de alto nível especificação - o limite do cliente / fornecedor está entre os requisitos de alto nível e todas as outras fases. O provedor contrato cobre tudo abaixo da linha. O cliente é responsável por testar o serviço prestado contra os requisitos de negócios. Uma vez que é mais fácil para especificar requisitos de alto nível, há um esforço reduzido de desenvolver entradas de contrato. No entanto, pode haver problemas significativos de aumento custar e risco tanto para o cliente e fornecedor, juntamente com espaço maior de erros, instabilidade de requisitos e maior dificuldade em saber o que os sistemas de informação que você deseja.

ITIL V3 - Service Design - Página:

324 de 477

5.2 Dados e Gestão da Informação De dados é um dos tipos de ativos críticos que precisam ser geridas de forma a desenvolver, entregar e ar os serviços de TI de forma eficaz. Dados / Gestão da Informação é como um organização planos, coleta, cria, organiza, usos, controles, divulga e dispõe de seus dados / informações, tanto estruturada registros e dados não estruturados. Assegura também que o valor do que os dados / informações são identificadas e exploradas, tanto em apoio das suas operações internas e no aumento do valor para o seu cliente-revestimentos processo de negócioes. Um número de termos são comuns nesta área, incluindo "Gestão de dados", "Gestão da Informação" e "Gestão de Recursos de Informação. Para os fins da presente publicação, "Gestão de Dados", o termo é utilizado como abreviatura para todos os três acima. O papel de Gestão de Dados descrito não é apenas sobre o gerenciamento de dados brutos: é sobre o gerenciamento de todos os metadados contextual "dados sobre os dados" adicionais - que vai com ele, e quando adicionado aos dados brutos dá 'informação' ou 'dados em contexto' . De dados, como base para a informação da organização, tem todos os atributos necessários para ser tratado como um ativos (Ou recurso). Por exemplo, é essencial para a 'obtenção de objetivo de negócios e os trabalhos bem sucedidos diárias de uma 'organização. Além disso, ele pode ser "obtida e conservada por uma organização, mas apenas com um custo financeiro". Finalmente, pode, juntamente com outros recursos / bens, ser usado para "acelerar a consecução dos objetivos de uma organização". Fatores-chave de sucesso para gerenciamento de dados são os seguintes: • • • • • •

Todos os utilizadores têm o imediato através de uma variedade de canais para as informações que eles precisam para fazer seu trabalho. Ativos de dados são totalmente explorados, através de compartilhamento de dados dentro da organização e com outros organismos. A qualidade dos dados da organização é mantido a um nível aceitável, e as informações utilizadas na negócio é preciso, confiável e consistente. Requisitos legais para manter a privacidade, segurança,confidencialidade e integridade de dados são observados. A organização atinge um nível elevado de eficiência e eficácia em seus dados e tratamento da informação atividades. Um os dados da empresa modelo para definir as entidades mais importantes e as suas relações - o que ajuda a evitar redundâncias e para evitar a deterioração do arquitetura como está mudado ao longo dos anos.

ITIL V3 - Service Design - Página:

325 de 477

5.2.1 Gerenciamento de ativos de dados Se os dados não são geridos de forma eficaz: • • • • • •

As pessoas a manter e coletar dados que não são necessários A organização pode ter informações históricas, que não é mais usado A organização pode conter uma grande quantidade de dados que é inível para os usuários potenciais A informação pode ser divulgada para mais pessoas do que deveria ser, ou não a essas pessoas a quem deve ser A organização pode usar métodos ineficientes e fora-de-data para coletar, analisar, armazenar e recuperar dados A organização pode deixar de coletar dados de que precisa, reduzindo a qualidade dos dados e integridade de dados é perdido, por exemplo, entre as fontes de dados relacionados.

Além disso, se as informações é derivado de dados de boa qualidade é uma pergunta difícil de responder, porque não há medidas em vigor contra a qual comparar-lo. Por exemplo, má qualidade dos dados surge muitas vezes por causa de cheques pobres na entrada e / ou atualização procedimentos. Uma vez que dados incompletos ou imprecisos foram armazenados no sistema de TI, todos os relatórios produzidos utilizando esses dados refletem essas imprecisões ou lacunas. Também pode haver uma falta de coerência entre gerado internamente gestão da informação do operacional sistemas, e de outros internos, sistemas localmente utilizados, criada porque a central de dados não é confiável. Uma forma de melhorar a qualidade dos dados é a utilização de uma gestão de dados processo que estabelece política e padrões, fornece conhecimentos e torna mais fácil para lidar com os aspectos de dados de novos serviços. Este deverá permitir que os dados completos / Gestão de Ativos de Informação para: • • • •

Agregar valor ao serviços entregues clientes Reduzir os riscos no negócio Reduzir os custos dos processos de negócios Estimular a inovação no interior processo de negócioes.

5.2.2 Âmbito da Gestão de Dados Existem quatro áreas de gestão incluídos dentro do escopo de Dados / Gestão da Informação: •

Gestão de recursos de dados: O governo de informações na organização deve assegurar que todos estes recursos são conhecidos e que as responsabilidades foram atribuídas para a sua gestão, incluindo a

ITIL V3 - Service Design - Página:

326 de 477

•

•

•

propriedade dos dados e metadados. Este processo é normalmente referido como a istração de dados e inclui a responsabilidade por: • Definir as necessidades de informação • Construção de um inventário de dados e um modelo de dados da empresa • Identificar a duplicação de dados e deficiências • A manutenção de um catálogo / índice dos dados / informações de conteúdo • Medindo o custar eo valor dos dados da organização. Gestão de dados /tecnologia da informação: A gestão da TI, que sustenta sistemas de informação da organização, o que inclui processos tais como o projeto de banco de dados e istração de banco de dados. Este aspecto é normalmente tratada por especialistas dentro da TI função - Veja o Operação de Serviço publicação para mais detalhes. Gestão dos processos de informação:processo de negócioes levará a De serviços de TIs, que inclua um ou outro dos recursos de dados da organização. Os processos de criação, coleta, o, modificação, armazenamento, exclusão e arquivamento de dados - ou seja, os dados ciclo de vida - Deve ser devidamente controlada, muitas vezes em conjunto com o processo de gerenciamento de aplicações. Gestão de padrões de dados e políticas: A organização terá de definir normas e políticas para a sua gestão de dados como um elemento de uma TI estratégia. Políticas irá reger a procedimentos e responsabilidades para gerenciamento de dados na organização, e políticas técnicas, arquiteturas e as normas que serão aplicadas ao Infra-estrutura de TI que a os sistemas de informação da organização.

As melhores práticas escopo do processo de gerenciamento de dados inclui a gestão não-estruturadas de dados que não são mantidos em sistemas de banco de dados convencionais - por exemplo, usando formatos como texto, imagem e áudio. É também responsável por assegurar processo qualidade em todas as fases do ciclo de vida de dados, a partir de requisitos para a aposentadoria. O foco principal desta publicação será em seu papel nas necessidades, projeto e desenvolvimento fases do ciclo de vida de ativos e Serviço. A equipe de apoio ao processo de gerenciamento de dados também pode fornecer uma empresa de serviços de e de informação. Neste caso, eles são capazes de responder a perguntas sobre o significado formato, e da disponibilidade de dados internos à organização, porque gerir os metadados. Eles também são capazes de compreender e explicar o que os dados externos podem ser necessários, a fim de realizar processos de negócios necessários e irá tomar as medidas necessárias para a fonte disso. Criticamente, quando da criação ou redesenho de processos e apoio De serviços de TIs, é bom prática considerar re-utilizando dados e metadados em diferentes áreas da organização. A capacidade de fazer isso pode ser ado

ITIL V3 - Service Design - Página:

327 de 477

por um conjunto de dados corporativos modelo - Às vezes conhecido como um modelo de informação comum - para ajudar a apoiar a reutilização, muitas vezes, um grande objetivo para gerenciamento de dados.

5.2.3 Gestão de Dados e do Ciclo de Vida do Serviço Recomenda-se que uma abordagem do ser adoptadas em compreender o uso de dados em processos de negócios. Questões gerais incluem: • • • • • • •

Que dados é realizada atualmente e como ele pode ser classificado? O que os dados precisam ser coletados ou criados pelos processos de negócio? Como os dados serão armazenados e mantidos? Como os dados serão ados, por quem e de que forma? Como os dados serão eliminados, e sob que autoridade? Como será a qualidade dos dados ser mantida (precisão, consistência, moeda, etc)? Como os dados podem ser mais íveis / disponíveis?

5.2.4 Apoio ao Ciclo de Vida do Serviço Durante requisitos e projeto inicial, Gestão de Dados pode ajudar projeto e equipes de desenvolvimento com serviço de dados específicos modelagem e dar conselhos sobre a utilização de várias técnicas para os dados do modelo. Durante o projeto ("físico") detalhado e desenvolvimento, O gerenciamento de dados função de oferecer conhecimentos técnicos em sistemas de gestão de banco de dados e de como converter iniciais "lógicos" modelos de dados em física, de produtos específicos, implementações. Muitos novos serviços falharam porque má qualidade dos dados não foi abordada durante o desenvolvimento do serviço, ou porque um determinado desenvolvimento criado os seus próprios dados e metadados, sem consulta com outro proprietário do serviços, ou com gerenciamento de dados.

5.2.5 Valorização dados De dados é um ativos e tem valor. Claramente em algumas organizações isso é mais evidente do que em outros. Organizações que são fornecedores de dados para outros organizaçãos - Yell, Dun e Bradstreet, e Reuters - dados de valor CAN como uma 'saída' em termos de preço que eles estão cobrando organizações externas para recebê-lo. Também é possível pensar de valor em termos do que os dados internos valeria a pena para outra organização. É mais comum a dados de valor em termos de que vale a pena para a organização proprietário. Há um número de maneiras de se fazer isso sugeridos:

ITIL V3 - Service Design - Página:

328 de 477

•

•

•

Valorizar dados por disponibilidade: Uma abordagem freqüentemente usada é a de considerar que processo de negócioes não seria possível se uma determinada peça de dados não estavam disponíveis, e como muito do que não-disponibilidade de dados custaria o negócio. Valorizando os dados perdidos: Uma outra abordagem que é frequentemente usado é pensar sobre os custos de obtenção de alguns dados, se fosse para ser destruído. Valorização de dados, considerando os dados ciclo de vida: Trata-se de pensar sobre como os dados é criado ou obtido, em primeiro lugar, como ele é disponibilizado para as pessoas a usar, e como os dados são aposentados, seja através de arquivamento ou destruição física. Pode ser que alguns dados são fornecidos a partir de uma fonte externa e, em seguida, realizada internamente, ou pode ser que os dados têm de ser criados sistemas internos da organização. Nestes dois casos, o ciclo de vida e é diferente do processoes que têm lugar durante a captura de dados será inteiramente separada. Em ambos os casos, o custars de refazer esses estágios podem ser avaliados. O mais valorizado os dados, mais o esforço que precisa ser gasto em assegurar a sua integridade,disponibilidade e confidencialidade.

5.2.6 Classificando dados Os dados podem ser inicialmente classificados como operacional,tático ou estratégico: •

•

•

Dados operacionais: Necessário para o funcionamento contínuo e de uma organização pode ser considerada como a mais baixa, mais específico, nível. Dados táticos: Geralmente necessária para segunda-line de gestão - ou superior - e, normalmente preocupados com dados resumidos e dados históricos, tipicamente ano-a-ano de dados ou dados trimestrais. Muitas vezes os dados que é usada aqui aparece em sistemas de gestão de informação que requerem dados de resumo de uma série de sistemas operacionais, a fim de lidar com uma exigência de contabilidade, por exemplo. Dados estratégicos: Muitas vezes preocupados com tendências a longo prazo e com a comparação com o mundo exterior, para fornecer os dados necessários para um sistema de apoio estratégico envolve a reunião de dados operacionais e táticas de muitas áreas diferentes, com dados externos relevantes. Muito mais dados é necessária a partir de fontes externas.

Um método alternativo é a utilização de um segurança classificação de dados e documentos. Isso normalmente é adotado como uma das empresas política dentro de uma organização.

ITIL V3 - Service Design - Página:

329 de 477

Uma classificação ortogonal distingue de toda a organização de dados, funcional-área de dados e serviços de dados específicos. • •

•

De toda a organização de dados precisa ser gerenciado centralmente. O próximo nível de dados é funcional-área de dados que devem ser compartilhadas através de um negócio completo função. Isso envolve a partilha de 'instâncias' de dados - por exemplo, cliente individual registros - e também garantir que os metadados consistente em que a área funcional, como formatos de endereço padrão, estão sendo usados. O último nível é o serviço de TI específico, onde os dados e metadados são válidos por um De serviços de TI e não precisa ser compartilhada com outros serviços.

Dados 5.2.7 estabelece normas Um dos aspectos críticos da istração de dados é garantir que os padrões de metadados estão no local - por exemplo, o que é metadados a ser mantido para diferentes tipos de dados subjacentes ». Diferentes detalhes são mantidos sobre estruturadas dados tabulares do que para outras áreas. 'Propriedade' é um item crítico desses metadados, algum tipo de identificador exclusivo é outra, uma descrição em termos de negócios significativos outro, e um formato pode ser outro. O custodiante ou mordomo, alguém no departamento de TI, que assume a responsabilidade pela gestão do dia-a-dia dos dados, também é registrado. Outro benefício de um processo de gerenciamento de dados seria no campo de dados de referência. Certos tipos de dados, como códigos postais ou nomes de países, pode ser necessário em uma variedade de sistemas e precisa ser consistente. É parte da responsabilidade de istração de dados para gerenciar os dados de referência, em nome de toda a empresa, e para se certificar de que os dados de referência utilizada é a mesma em todos os sistemas da organização. Normas para a nomeação devem estar no lugar, por isso, por exemplo, se um novo tipo de dados é requerido num novo serviço, Então não há a necessidade de utilizar os nomes que correspondam a estas normas. Um exemplo padrão pode ser 'todas as capitais, sem sublinhado e sem abreviaturas.

5.2.8 Propriedade dos dados istração de dados pode ajudar o desenvolvedor do serviço, fazendo responsabilidades seguros para a propriedade dos dados são levadas a sério pela negócio e pelo departamento de TI. Uma das formas mais bem sucedidas de fazer isso é fazer com que a empresa eo departamento de TI para se inscrever a uma carta de dados - um conjunto de normas processuais e de orientação para a gestão cuidadosa dos dados da organização, por adesão a

ITIL V3 - Service Design - Página:

330 de 477

padrões definidos corporativamente. Responsabilidades de um proprietário de dados são muitas vezes definidas aqui e podem incluir: • • • • •

Concordando uma descrição do negócio e um propósito para os dados Definir quem pode criar, alterar, ler e apagar os dados de ocorrências de Alterações orçamentais na forma como os dados são capturados ou derivados Aprovar quaisquer faixas de domínio, formato e valor Aprovar a nível relevante de segurança, Inclusive certificando-se de que os requisitos legais e políticas internas sobre a segurança de dados são respeitados.

5.2.9 A migração de dados A migração de dados é um problema em um novo serviço está substituindo uma série de (possivelmente apenas um) dos serviços existentes, e é necessária a realização de diâmetro, para o novo serviço, boa qualidade de dados dos sistemas e serviços existentes. Existem dois tipos de migração de dados de interesse para projetos aqui: uma é a migração de dados em data warehouses, etc, para inteligência de negócios / fins de análise, a outra é a migração de dados para um novo transaçãoal, operacional serviço. Em ambos os casos, será benéfica se os padrões de migração de dados, procedimentos e os processos são estabelecidas pela istração de Dados. Ferramentas de migração de dados já pode ter sido adquirido em nome da organização, a equipe de gerenciamento de dados. Sem este apoio, é muito fácil subestimar a quantidade de esforço que é necessário, especialmente se consolidação de dados e limpeza tem de ter lugar entre os sistemas de múltiplas fontes, eo qualidade dos dados dos serviços existentes "é conhecido por ser questionável.

5.2.10 O armazenamento de dados Uma área em que a tecnologia evoluiu muito rapidamente se encontra na área de armazenamento de dados. Há uma necessidade de se considerar meios de armazenamento diferentes - por exemplo, o armazenamento óptico - e estar ciente do tamanho e implicações de custos associados a este. A principal razão para a compreensão dos desenvolvimentos nesta área é que eles tornam possíveis muitos tipos de áreas de gerenciamento de dados que foram considerados demasiado caro antes. Por exemplo, para armazenar vídeo em tempo real, que utiliza uma largura de banda grande, tem, até que os últimos dois ou três anos, sido considerado demasiado caro. O mesmo é verdade para a digitalização de um grande número de documentos em papel, especialmente quando esses documentos não são baseados em texto, mas contêm diagramas detalhados ou imagens. Compreender desenvolvimentos tecnológicos no que diz respeito ao armazenamento eletrônico de dados é fundamental para a compreensão das oportunidades para o negócio para explorar a informação recurso efetivamente, fazendo o melhor uso de novas tecnologias.

ITIL V3 - Service Design - Página:

331 de 477

5.2.11 A captura de dados Também é muito importante trabalhar com gerenciamento de dados sobre medidas eficazes para a captura de dados. O objetivo aqui é capturar dados mais rápida e precisa possível. Existe uma necessidade de assegurar que os processos de captura de dados requer o mínimo de codificação, e explorar as vantagens que gráficas usuário interfaces fornecem, em termos de minimizar o número de batidas de tecla necessários, diminuindo também a possibilidade de erros durante a captura de dados. É razoável esperar que a gestão de dados processo tem padrões para, e pode fornecer conhecimentos sobre os métodos eficazes de captura de dados em vários ambientes, incluindo "não-estruturados" de captura de dados utilizando mecanismos como a digitalização.

5.2.12 recuperação de dados e uso Uma vez que os dados tenham sido captado e armazenado, o próximo aspecto a ser considerado é a recuperação da informação a partir dos dados. Serviços para permitir o o fácil a dados estruturados através de ferramentas de consulta de vários níveis de sofisticação são necessários a todas as organizações, e gerar as suas próprias exigências arquitetônicas. Toda a área de pesquisa dentro do texto digitalizado e outros não-estruturadas de dados, tais como vídeo, imagens ou som ainda é uma importante área de expansão. Técnicas como a indexação automática, e a utilização de motores de busca para dar um o eficiente por meio de palavras-chave para as peças relevantes de uma documento, São as tecnologias essenciais que têm sido amplamente implementadas, principalmente na internet. Experiência na utilização de dados ou de conteúdo dentro de sites devem existir dentro da Gestão de Dados, bem como gerenciamento de conteúdo - normas e procedimentos que são vitais para websites.

5.2.13 A integridade de dados e questões relacionadas Ao definir os requisitos para De serviços de TIs, é vital que a gestão operacional e requisitos relacionados com dados serem considerados. Em particular, as seguintes áreas devem ser abordadas: • • • •

Recuperação de dados perdidos ou corrompidos o controlado aos dados Implementação de políticas de arquivamento de dados, incluindo observância com períodos de retenção de regulamentação Dados periódicos integridade cheques.

A integridade dos dados está preocupado com a garantia de que os dados são de alta qualidade e não corrompido. É também sobre a prevenção da duplicação de dados sem controle, e, portanto, evitando qualquer confusão sobre o que é o

ITIL V3 - Service Design - Página:

332 de 477

válido versão dos dados. Há várias abordagens que podem ajudar com isso. Vários dispositivos de tecnologia, tais como "bloqueio de banco de dados 'são usados para evitar múltipla, inconsistente, atualização de dados. Além disso, a prevenção de actualização ilegal pode ser conseguido através de mecanismos de controlo de o.

ITIL V3 - Service Design - Página:

333 de 477

5,3 Gerenciamento de Aplicativos Um aplicação é aqui definido como o programa de software (s) que desempenhar as funções específicas que apóiam diretamente a execução de processo de negócioes e / ou procedimentos. Aplicações, juntamente com os dados e infra-estrutura componentes tais como hardware, o sistema operacional e middleware, Fazem-se os componentes de tecnologia que fazem parte de um serviço de TI. O aplicativo em si é apenas um componente, embora importante do serviço. Por isso, é importante que a aplicação entregue corresponde aos requisitos acordados da negócio. No entanto, muitos organizaçãos gastar muito tempo focando os requisitos funcionais do novo serviço e aplicação, e tempo insuficiente é gasto para projetar a gestão e operacional requisitos (não-funcionais) do serviço. Isto significa que quando o serviço estiver operacional, atende a todas as funcionalidades necessárias, mas totalmente não atender a expectativa do negócio e da clientes em termos da sua qualidade e atuaçãoE, portanto, tornase inutilizável. Duas abordagens alternativas são necessárias para implementar integralmente Aplicação de Gestão de. Uma abordagem emprega um longo serviço Development Lifecycle (SDLC) para apoiar a desenvolvimento de um serviço de TI. SDLC é uma abordagem sistemática para a resolução de problemas e é composto das seguintes etapas: • • • • • • •

Estudo de viabilidade Análise Projeto Teste Implementação Avaliação Manutenção.

A outra abordagem tem uma visão global de todos os serviços para garantir a contínua manutenção e gerenciamento da aplicaçãos: •

•

•

Todas as aplicações são descritos de uma forma consistente, através de um Application Portfolio que é gerido e mantido para permitir alinhamento com as necessidades dinâmicas dos negócios. Consistência da abordagem do desenvolvimento é aplicada através de um número limitado de estruturas de aplicativos e padrões de projeto e através da filosofia primeira a 'reutilização'. Componentes de software comuns, geralmente, para suprir as necessidades operacionais e de gestão, são criados ou adquiridos em um nível "organizacional" e utilizados por sistemas individuais como eles são projetados e construídos.

ITIL V3 - Service Design - Página:

334 de 477

5.3.1 O portfólio de aplicativos Isto é simplesmente um completo registro de todos aplicaçãos dentro da organização e é dinâmico em seu conteúdo. Nome do aplicativo

Operações de TI proprietário

Novo desenvolvimento custar

Identificador da aplicação

TI proprietário desenvolvimento

Anual custo operacionals

Descrição da aplicação

Contatos de e

Custo de e anual

Processo de negócio ada

Tecnologias de banco de dados

Custos anuais de manutenção

Serviços de TI apoiada

Aplicativos dependentes

Terceirizado componentes

Patrocinador executivo

Sistemas de TI apoiada

Terceirizar parceiros

Geografias ado

Interfaces de usuário

Produção métricos

Importância do negócio

Arquitetura de TI, incluindo a topologia de rede

Ligação OLA

SLA link

Tecnologias de aplicação utilizada

Métricas de apoio

Proprietário da empresa

Número de usuários

Tabela Application Portfolio 5,5 atribui exemplo

5.3.2 Vinculação portfólios de aplicativos e serviço Alguns organizaçãos manter um separado Application Portfolio com separado atributos, enquanto que em outras organizações Carteira de aplicação é armazenado dentro da CMS, juntamente com a apropriada relaçãos. Outras organizações combinar o portfólio de aplicativos em conjunto com o Portfólio de Serviços. Cabe a cada organização decidir o mais adequado estratégia para suas próprias necessidades. O que está claro é que deve haver relações muito estreitas e as ligações entre o aplicaçãos e os serviços que eles am e os componentes de infra-estrutura utilizada.

ITIL V3 - Service Design - Página:

335 de 477

5.3.3 frameworks de aplicação O conceito de uma estrutura de aplicativo é muito poderoso. A estrutura do aplicativo cobre toda a gestão e operacional aspectos e, na verdade, oferece soluções para todas as necessidades de gestão e operacionais que cercam uma aplicação. Implícita no uso de frameworks de aplicação é o conceito de padronização. Se uma organização usa e tem de manter uma estrutura de aplicativo para cada única aplicação, Não haverá muitos benefícios da utilização de uma estrutura de aplicação. Uma organização que pretende desenvolver e manter estruturas de aplicativos, e para assegurar que os frameworks de aplicação em conformidade com as necessidades dos desenvolvedores de aplicativos, deve investir em fazê-lo. É essencial que as arquiteturas de Aplicativos não são desenvolvidas de forma isolada, mas estão intimamente relacionadas e integradas com todos os outro quadro e actividades de arquitectura. As arquiteturas de serviços, de Infraestrutura, Meio Ambiente e dados devem ser todos em estreita integração com a arquitetura do aplicativo e um quadro. Estruturas de arquitetura, aplicação e padrões Arquitetura atividades relacionadas devem ser planejados e gerenciados separadamente do software baseado no sistema indivíduo projetos. Também é importante que a arquitectura actividades relacionadas com o ser realizada para o benefício de mais do que apenas um aplicação. Os desenvolvedores de aplicativos deve se concentrar em uma única aplicação, enquanto os desenvolvedores de aplicativos quadro deve se concentrar em mais de um aplicativo, e sobre as características comuns desses aplicativos, em particular. Um comum prática é distinguir entre vários tipos de aplicações. Por exemplo, nem todas as aplicações podem ser construídas em cima de um Microsoft ® Windows plataforma de sistema operacional, ligado a um UNIX servidor, Usando HTML, applets Java, JavaBeans e um banco de dados relacional. Os vários tipos de aplicações pode ser considerada como famílias de aplicação. Todos os aplicativos da mesma família são baseados no quadro do mesmo aplicativo. Utilizando o conceito de uma estrutura de aplicação, o primeiro o da fase de design da aplicação é identificar a estrutura de aplicação apropriada. Se o quadro de aplicação é maduro, um grande número de decisões de projeto são dadas. Se ele não está madura, e todos os requisitos de gestão e operacionais não podem ser cumpridas em cima de uma estrutura de aplicativo existente, o preferido estratégia é coletar e analisar os requisitos que não podem ser tratadas na atual versão da estrutura do aplicativo. Com base nos requisitos de aplicação, novos requisitos podem ser definidos para a estrutura do aplicativo.

ITIL V3 - Service Design - Página:

336 de 477

Em seguida, o quadro de aplicação pode ser modificado para que possa lidar com as necessidades de aplicação. De facto, toda a família de aplicaçãos, que corresponde à estrutura de aplicativos podem usar os recursos de estrutura recém-adicionados ou alterados. Desenvolvimento e manutenção de uma estrutura de aplicativo é uma tarefa exigente e, como todos os outros projeto atividades, devem ser realizados por pessoas competentes e experientes. Alternativamente, frameworks de aplicação podem ser adquiridos de terceiros.

5.3.4 A necessidade de ferramentas CASE e repositórios Um aspecto importante do que o alinhamento global é a necessidade de alinhar aplicaçãos com as suas estruturas de apoio subjacentes. Aplicação ambiente de desenvolvimentos tradicionalmente têm seu próprio computador Assistido / Auxiliado Engenharia de Software (CASE) ferramentas que oferecem os meios para especificar os requisitos, desenhar diagramas de design (de acordo com especial modelagem normas), ou até mesmo gerar aplicações completas, ou esqueletos quase completos de aplicação, quase pronto para ser implantado. Estes ambientes também fornecer um local central para armazenar e gerenciar todos os elementos que são criados durante o desenvolvimento de aplicativos, geralmente chamado de repositório. Funcionalidade inclui repositório versão controle e verificação de coerência entre as diferentes modelos. A abordagem atual é usar metacase-ferramentas para modelar linguagens específicas de domínio e usá-los para fazer o caso mais trabalho alinhado às necessidades do negócio.

5.3.5 Design de aplicações específicas A fase de requisitos do ciclo de vida foi abordado anteriormente na seção de engenharia de requisitos. A fase de projeto é uma das fases mais importantes dentro do ciclo de vida da aplicação. Assegura-se que um aplicação é concebido com operacionalidade e Aplicação de Gestão de em mente. Esta fase tem as saídas a partir da fase de requisitos e transforma-os em a especificação que irão ser utilizados para desenvolver a aplicação. A meta para projetos deve ser satisfazer os requisitos da organização. Projeto inclui a projeto da aplicação em si, eo projeto de infra-estrutura e ambiente dentro da qual a aplicação opera. Considerações de arquitetura são o aspecto mais importante desta fase, uma vez que podem ter impacto sobre a estrutura eo conteúdo de ambos aplicação e modelo operacional. Considerações de arquitetura para a aplicação (desenho da arquitetura de aplicações) e considerações de arquitetura para o ambiente (desenho da arquitetura de TI) estão fortemente relacionados e precisam ser alinhados. Arquitetura e design de aplicação não deve ser considerada isoladamente, mas devem formar um componente global e integrada da arquitetura de serviço e design.

ITIL V3 - Service Design - Página:

337 de 477

Geralmente, na fase de projeto, o mesmo modelos será produzido como foram entregues na fase de requisitos, mas durante o projeto muitos mais detalhes são adicionados. Os novos modelos incluem o arquitetura modelos, em que a maneira pela qual o funcionais diferentes componentes são mapeados para os componentes físicos (desktops, por exemplo, servidors, bancos de dados e de rede) precisa ser definido. O mapeamento, em conjunto com a carga estimada do sistema, devem permitir o dimensionamento da infra-estrutura necessária. Outro aspecto importante do modelo de arquitectura é a incorporação do aplicação no ambiente existente. Que partes da infra-estrutura existente será utilizado para apoiar as funções necessárias novas? Pode servidores existentes ou redes de ser usado? Com que impacto? São necessárias funções disponíveis em aplicações já existentes que podem ser utilizados? Não existem pacotes que oferecem a funcionalidade necessária ou se as funções de ser construído a partir do zero? O projeto fase tem todos os requisitos em consideração e começa a montá-los em um projeto inicial para a solução. Fazer isso não só dá aos desenvolvedores uma base para começar a trabalhar: é também provável para trazer perguntas que precisam ser feitas da clientes /usuários. Se possível, frameworks de aplicação deve ser aplicado como um ponto de partida. Nem sempre é possível prever todos os aspectos do design de uma solução antes do tempo. Como uma solução seja desenvolvida, coisas novas serão aprendidas sobre como fazer as coisas e também como não. A chave é criar um projeto flexível, de modo que fazer uma mudar não enviar os desenvolvedores de todo o caminho de volta para o início da fase de projeto. Há uma série de abordagens que podem minimizar a chance de que isso aconteça, incluindo: • • • •

Projetando para requisitos de gestão e operacionais Gerenciando trade-offs Usando independente de aplicação de design diretrizs, utilizando frameworks de aplicação Empregando um processo estruturado o modelo da lista / gerenciamento.

Projeto de gestão e requisitos operacionais significa dar requisitos de gestão e operacionais de um nível de importância similar ao dos requisitos funcionais, e incluí-los como parte obrigatória da fase de projeto. Isto inclui um número de gestão e os requisitos operacionais, tais como disponibilidade,capacidade,manutenção,confiança e segurança. Agora, é inconcebível em projetos de desenvolvimento de aplicativos modernos que usuário design de interface (usabilidade requisitos) seria omitido como um projeto-chave atividade. No entanto, muitos organizaçãos ignorar ou esquecer

ITIL V3 - Service Design - Página:

338 de 477

de gerenciamento. Detalhes da gestão necessária e requisitos operacionais estão contidas dentro do SDP e SAC nos apêndices A e B.

5.3.6 Gerente trade-offs Gerenciando trade-off decisões foca equilibrando a relação entre os recursos, o cronograma do projeto, e os recursos que precisam ser incluídos no aplicação por causa da qualidade. Quando as equipes de desenvolvimento de tentar completar este equilíbrio, é muitas vezes em detrimento da gestão e operacional requisitos. Uma forma de evitar isso é para incluir a gestão e os requisitos operacionais nas orientações aplicação independente de concepção - por exemplo, sob a forma de uma estrutura de aplicação. Operacionalidade e capacidade de gestão efetivamente se tornar padrão componentes de todo o projeto processoes - por exemplo, sob a forma de uma estrutura de aplicação - e ficar encaixado no trabalho práticas e cultura da organização de desenvolvimento.

5.3.7 típicas saídas de projeto Os seguintes são exemplos das saídas a partir de uma peça de design aplicações formação do conjunto Design de Serviços: • • • • • • • • •

De entrada e saída de projeto, incluindo formulários e relatórios A utilizável usuário design de interface (interação homem-computador) Um dado adequado / objeto modelo Um fluxo de processo ou fluxo de trabalho modelo Detalhado especificaçãos para atualização e somente leitura processos Mecanismos para alcançar os controles de auditoria, segurança,confidencialidade e privacidade A tecnologia específica projeto "físico" Scripts para testar o projeto de sistemas Interfaces e dependências de outras aplicações.

Tem diretrizs e estruturas que podem ser adotadas para determinar e definir as saídas de projeto dentro do Gerenciamento de Aplicativos, como Capability Maturity Model Integration (CMMI).

5.3.8 Os padrões de design Um padrão de projeto é uma solução, em geral repetitivo para um problema comumente ocorrem em design de software. Padrões de design orientado a objeto normalmente mostrar as relações e interações entre classes ou objetos, sem especificar as classes de aplicações finais ou objetos que estão envolvidos. Padrões de projeto descrevem tanto um problema e uma solução para problemas comuns encontrados no desenvolvimento do aplicativo.

ITIL V3 - Service Design - Página:

339 de 477

Um importante projeto princípio usado como a base para um grande número de padrões de design encontrados em literatura recente é o de separação de preocupação. Separação de preocupações vai conduzir a aplicações divididas em componentes, com uma forte coesão e acoplamento mínimo entre componentes. A vantagem de uma tal aplicação é que a modificação pode ser feita para os componentes individuais com pouco ou nenhum impacto sobre as outras componentes. No desenvolvimento de aplicações típicas projetos, mais de 70% do esforço é gasto na concepção e desenvolvimento de funções genéricas e em satisfazer as necessidades de gestão e operacional. Isso porque cada aplicação precisa fornecer uma solução para tais características genéricas como a impressão, erro manuseamento e segurança. Entre outros, o Object Management Group (OMG, www.omg.com) definiu um grande número de serviços que são necessários em todos os aplicação. Arquitetura da OMG (Object Management OMA) distingue claramente entre os aspectos funcionais e de gestão e operacionais de uma aplicação. Ela se baseia no conceito de proporcionar um tempo de execução ambiente que oferece todos os tipos de instalações para um aplicativo. Neste conceito, a aplicação abrange os aspectos funcionais, e ao meio ambiente abrange todos os aspectos de gestão e operacional. Os desenvolvedores de aplicativos deve, por definição, o foco sobre os aspectos funcionais de uma aplicação, enquanto outros podem se concentrar na criação de um ambiente que oferece a gestão necessária e serviços operacionais. Isto significa que os programadores de aplicações focar os requisitos da negócio, Enquanto que o arquitetura desenvolvedores ou programadores Application Framework focar as necessidades dos desenvolvedores de aplicativos.

5.3.9 Desenvolvimento de aplicações individuais Uma vez que a fase de projeto estiver concluído, a equipe de desenvolvimento do aplicativo levará os projetos que tenham sido produzidos e ar para o desenvolvimento do aplicação. O aplicativo e ambiente relacionados estão prontas para desenvolvimento. Componentes de aplicação são codificados ou adquirida, integrado e testado. Para garantir que o aplicativo é desenvolvido com a gestão no núcleo, a equipe de desenvolvimento tem de se concentrar em garantir que a fase de desenvolvimento continua a endereçar corretamente a gestão e operacional aspectos da projeto (E.g. capacidade de resposta,disponibilidade,segurança). O desenvolvimento orientação fase abrange os seguintes tópicos: •

Consistentes convenções de codificação

ITIL V3 - Service Design - Página:

340 de 477

• • • •

Aplicação independentes diretrizes de construção Testes de operacionalidade Lista de verificação de Gestão para a fase de construção Organização da equipe de construção papels.

5.3.10 consistentes convenções de codificação A principal razão para a utilização de um conjunto consistente de design e convenções de codificação é padronizar a estrutura e estilo de codificação de um aplicação para que todos possam facilmente ler, entender e gerenciar o desenvolvimento de aplicações processo. Um bom design e codificação resultado convenções no código fonte precisa, legível e inequívoca de que é consistente com a codificação de organização e normas de gestão e é tão intuitivo para seguir possível. Adicionando operacionalidade aplicativo para esta convenção garante que todas as aplicações são construídas de uma maneira que garante que eles podem ser totalmente gerenciado por todo o caminho através de seu ciclo de vidas. Uma convenção de codificação em si pode ser uma ajuda significativa à gestão da aplicação, como consistência permite que as ferramentas de gerenciamento de interagir com a aplicação de uma forma conhecida. É melhor introduzir um conjunto mínimo de convenções que todos vão seguir, em vez de criar um conjunto muito complexo que engloba todos os aspectos, mas não é seguido ou usado de forma consistente em todo o organização.

5.3.11 modelos e geração de código Uma série de ferramentas de desenvolvimento fornecem uma variedade de modelos para a criação de componentes de aplicativos comuns. Em vez de criar todas as peças de uma aplicação a partir do zero, os desenvolvedores podem personalizar um modelo existente. Eles também podem reutilizar personalizado componentes em múltiplas aplicaçãos, criando seus próprios modelos. Outras ferramentas de desenvolvimento irá gerar grandes pedaços de código (esqueletos), baseado no desenho modelos e convenções de codificação. O código pode incluir ganchos nas peças de código que têm de ser adicionados. A este respeito, modelos e estruturas de aplicativos de TI deve ser considerada ativoss. Esses ativos não apenas orientar o desenvolvimento de aplicações, mas também incorporar as lições aprendidas ou capital intelectual de esforços para o desenvolvimento de aplicações anteriores. Quanto mais os componentes normais são concebidos para a solução, as aplicações mais rápidas podem ser desenvolvidos, contra menor custars, a longo prazo (não ignorando o fato de que o desenvolvimento de modelos, geradores de código e estruturas de aplicação requer um investimento significativo).

ITIL V3 - Service Design - Página:

341 de 477

5.3.12 instrumentação aplicativo embutido O desenvolvimento ofertas de fase com a incorporação de instrumentação no tecido do aplicação. Desenvolvedores precisam de uma maneira consistente para fornecer instrumentação para os motoristas de aplicação /middleware componentes (por exemplo, motoristas de banco de dados) e aplicações que é eficiente e fácil de implementar. Para manter os desenvolvedores de aplicativos de reinventar a roda a cada nova aplicação que se desenvolvem, a indústria de computadores fornece métodos e tecnologias para simplificar e facilitar o processo de instrumentação. Estes incluem: • • • • • •

Aplicação Medição de resposta (ARMS) IBM Application Management Specification (AMS) Common Information Model (CIM) e Web-Based Enterprise Management (WBEM) da Distributed Management Task Force (DMTF) Desktop Management Instrumentation (DMI) Microsoft Windows © Management Instrumentation (WMI) Java Management Extension (JMX).

Cada uma destas tecnologias proporciona um modelo consistente e ricamente descritivo da configuração, estado e aspectos operacionais da aplicaçãos e serviços. Estes são fornecidos através de interfaces de programação de aplicativos (APIs Programa) que o desenvolvedor incorpora em uma aplicação, normalmente através da utilização de modelos de programação padrão. É importante assegurar que todas as aplicações são construídos para estar em conformidade com um certo nível de observância para a aplicação de instrumentação. Maneiras de fazer isso podem incluir: • • • •

Proporcionar o o a dados de gestão por meio da API de instrumentação Publicar dados de gestão para outros sistema de gestãos, de novo através do API instrumentação Fornecer aplicações evento manipulação Fornecer um gancho de diagnóstico.

5.3.13 ganchos de diagnóstico Ganchos de diagnóstico são de maior valor durante o teste e, quando um erro Foi descoberto no serviço de produção. Ganchos de diagnóstico, principalmente, fornecer as informações necessárias para resolver problemas e erros de aplicação rápida e restaurar serviço. Eles também podem ser usados para fornecer a medição e gestão da informação de aplicações.

ITIL V3 - Service Design - Página:

342 de 477

As três categorias principais são: • •

• •

Nível de sistema informações fornecidas pelo sistema operacional e de hardware Software nível de informações fornecidas pela infra-estrutura de aplicação componentes, tais como web banco de dados, servidor ou sistemas de mensagens Informação personalizada fornecida pela aplicaçãos Informações sobre o componente e serviço atuação.

5.3.14 Principais saídas de serviço de desenvolvimento As saídas importantes a partir da fase de desenvolvimento são os seguintes: • • • • •

• • • • • • •

Scripts para ser executado antes ou depois desenvolvimento Scripts para iniciar ou parar a aplicação Scripts para verificar configurações de hardware e software de ambientesalvo antes da implantação ou instalação Especificação de métricos e eventos que podem ser obtidos a partir da aplicação e que indicam o desempenho estado do aplicação Scripts personalizados iniciadas por Operação de Serviço equipe para gerenciar a aplicação (incluindo a manipulação de atualizações de aplicativos) Especificação das informações de controle de o para o sistema recursos usado por um aplicativo Especificação dos detalhes necessários para controlar um aplicativo de grande transaçãos Metas de SLA e requisitos Operacional requisitos e documentação Necessidades de apoio Aplicação recuperação e apoios Outros requisitos de TI SM e metas.

ITIL V3 - Service Design - Página:

343 de 477

6 Organizador para Design de Serviços Para Design de Serviços para ser bem sucedido, é essencial para definir o papels e responsabilidades dentro da organização das várias actividades. Ao projetar um serviço ou um processo, É imperativo que todas as funções estão claramente definidas. A marca de alto desempenho organizaçãos é a capacidade de tomar as decisões certas rapidamente e executá-los de forma eficaz. Se a decisão envolve estratégico escolha ou uma crítica operação, Ser claro sobre quem tem de entrada, quem decide e quem toma a ação vai permitir à empresa a avançar rapidamente. O RACI modelo será benéfico para permitir que as decisões sejam tomadas com ritmo e confiança. RACI é um acrônimo para as quatro principais funções: • • • •

Responsável - A pessoa ou as pessoas responsáveis por fazer o trabalho Responsável - Só uma pessoa pode ser responsável por cada tarefa Consultado - As pessoas que são consultados e cujas opiniões são procurados Informado - As pessoas que são mantidos up-to-date em andamento.

Ocasionalmente, um expandida versão de RACI é usado chamado RACI-VS, com duas funções adicionais, como segue: • •

Verifica - A pessoa ou grupo que verifica se os critérios de aceitação foram atendidos Sinais fora - A pessoa que aprova a decisão V e autoriza o produto handoff. Esta poderia ser a pessoa A.

Uma terceira variação do modelo RACI é RASCI, onde o S representa de e. Este papel oferece recursos adicionais para realizar o trabalho, ou tem um apoio papel na implementação, por exemplo. Isto pode ser benéfico para De serviços de TI implementação. Diretor do Serviço de Gerenciamento

Gerente de Nível de Serviço

Gerente de problema

Security Manager

Gerente de Compras

Atividade 1

AR

C

Eu

Eu

C

Atividade 2

A

R

C

C

C

Atividade

Eu

A

R

Eu

C

ITIL V3 - Service Design - Página:

344 de 477

3 Atividade 4

Eu

A

R

Eu

Atividade 5

Eu

Eu

A

C

Eu

Tabela 6.1 Exemplo de matriz RACI

O gráfico RACI na Tabela 6.1 mostra a estrutura e do poder de RACI modelagem com as atividades abaixo o lado esquerdo, incluindo as ações que precisam ser tomadas e as decisões que devem ser feitas. Na parte superior, a tabela lista os papéis funcionais responsáveis pela realização da iniciativa ou a desempenhar um papel na tomada de decisões. Se RACI ou alguma outra ferramenta ou modelo é usado, o importante é não deixar a atribuição de responsabilidades ao acaso ou deixar para o último minuto para decidir. Os conflitos podem ser evitados e as decisões podem ser tomadas rapidamente se os papéis são distribuídos com antecedência. Para construir um gráfico RACI os seguintes os são necessários: • • • • • •

Identificar as atividades /processoes Identificar / definir os papéis funcionais Realizar reuniões e atribuir os códigos RACI Identificar eventuais lacunas ou sobreposições - por exemplo, onde existem duas RS ou no RS (ver análise abaixo) Distribua o gráfico e incorporar o Certifique-se que as atribuições estão sendo seguidos.

ITIL V3 - Service Design - Página:

345 de 477

6.1 Análise Funcional papéis • • • •

Muitos Como: são deveres segregados corretamente? Caso alguém ser responsável por algumas dessas atividades? É este causando um gargalo em algumas áreas que irão atrasar decisões? Rs muitos: Isso é demais para um função? Sem espaços vazios: Será que isso papel precisam estar envolvidos em tantas tarefas? Além disso, é o tipo ou o grau de participação caber qualificações este papel de?

6.2 Análise de Atividade • • • • • •

Mais do que um A: apenas um papel pode ser responsável. Como não: pelo menos um A, deve ser atribuído a cada atividade. Mais de um R: também muitos papéis responsáveis, muitas vezes significa que ninguém assume a responsabilidade. A responsabilidade pode ser compartilhada, mas somente se os papéis são claros. Não Rs: pelo menos uma pessoa deve ser responsável. Muitos Cs: Existe uma exigência de consulta com tantos papéis? Quais são os benefícios e pode o tempo extra pode ser justificada? Cs e não é: são os canais de comunicação abertos para permitir que as pessoas e departamentos para falar uns com os outros e manter-se mutuamente up-to-date?

ITIL V3 - Service Design - Página:

346 de 477

6,3 habilidades e atributos As funções específicas dentro de ITIL Serviço de Gestão de todos exigem habilidades específicas, atributos e competências das pessoas envolvidas para que possam trabalhar de forma eficaz e eficiente. No entanto, qualquer que seja o papel, É imperativo que a pessoa realizar essa função tem os seguintes atributos: • • • • • •

A consciência das prioridades da empresa, objetivos e drivers de negócio Consciência do papel que desempenha em permitir que o objetivo de negócios a serem cumpridas Serviço ao cliente habilidades Consciência do que TI pode entregar ao negócio, Incluindo as mais recentes capacidades A competência, conhecimento e informações necessárias para concluir o seu papel A capacidade de usar, entender e interpretar o melhores práticas, Políticas e procedimentos para garantir a adesão.

Os seguintes são exemplos de atributos necessários em muitas das funções, dependendo da organização e da função específica: • • •

• • •

Competências de gestão - Quer a partir de uma perspectiva de gestão de pessoas e para o controlo global de processo Habilidades de reunião - Organizar, documento cadeira, e garantir as ações são acompanhadas Comunicações - Um elemento importante de todas as funções é a sensibilização dos processos para garantir o buy-in e conformidade. A capacidade de comunicar em todos os níveis dentro da organização será imperativo Articular - Tanto escrita, por relatórios, etc, e verbal Negociação - Necessário para vários aspectos, tais como a aquisição e contratos Analítico - Analisar métricos produzidos a partir da actividade.

Mais informações sobre as habilidades e competências desses papéis pode ser encontrada no âmbito do Quadro de Competências para a Informação Idade (SFIA - www.sfia.org.uk).

ITIL V3 - Service Design - Página:

347 de 477

6,4 Funções e responsabilidades O documento secções seguintes da papéis e responsabilidades dos vários papéis dentro Design de Serviços. Em alguns organizaçãos pode ser um indivíduo em tempo integral e nos outros pode ser várias pessoas, ou pode ser um papel de meio período. Em organizações menores muitas destas funções podem ser desempenhadas por uma única pessoa. Isso vai depender do tamanho e da volatilidade da organização. As funções ou cargos geralmente variam entre organizações. No entanto, o que é importante é que os papéis, responsabilidades, processos, dependências e interfaces são claramente definidos e escopod para cada organização. (Veja o Apêndice C para um modelo de documento exemplo processo.) A seguir, são ilustrações das principais atividades dentro de cada uma das funções de design de serviço.

6.4.1 Processo de proprietário Aproprietário do processo é responsável por assegurar que o seu processo está sendo realizado de acordo com o processo acordado e documentado e está a cumprir os objectivos da definição do processo. Isso inclui tarefas tais como: • • • • • • • • • • •

Documentar e divulgar o processo de Definindo o Key Performance Indicators (KPI) para avaliar a eficácia e eficiência do processo Revendo KPIs e tomar medidas necessárias após a análise Ajudar com e ser o responsável pelo projeto do processo Melhorar a eficácia e eficiência do processo de Análise de todas as melhorias propostas para o processo Fornecendo a entrada para o curso Plano de Melhoria de Serviço Enfrentar os problemas com o funcionamento do processo de Assegurar todo o pessoal relevante tem a formação exigida no processo e estão conscientes de sua papel no processo Garante que os processos, funções, responsabilidades e documentação são regularmente revisados e auditados Interfaces com a gestão da linha, garantindo que o processo recebe os recursos humanos necessários. (Gestão da linha e proprietário do processos têm tarefas complementares - eles precisam trabalhar juntos para garantir que os processos eficientes e eficazes. Muitas vezes é a tarefa de gestão de linha para garantir a formação necessária do pessoal.)

6.4.2 Gerente de Service Design O papel-chave e responsabilidades do Gerente de Service Design são cobertos ao longo desta publicação e são responsáveis pela coordenação geral e

ITIL V3 - Service Design - Página:

348 de 477

desenvolvimento de projetos de qualidade de soluções para serviços e processos. Responsabilidades do papel além e acima das de gerenciamento de linha de todas as pessoas envolvidas em papéis de design de serviços incluem: •

• •

• • •

Tomando as Estratégias de serviço global e assegurar que eles são refletidos no Design de Serviços prática e os projetos de serviço que são produzidos para atender e satisfazer os requisitos de negócios documentados Projetando os aspectos funcionais dos serviços, bem como a infraestrutura, ambiente aplicações e gerenciamento de dados Produtor qualidade, Desenhos de seguro e resiliente para serviços novos ou melhorados, arquitetura tecnológica, processos ou sistemas de medição que satisfaçam todos os acordadas atuais e futuros requisitos de TI da organização Produção e manutenção de toda a documentação do projeto, incluindo desenhos, planos, arquiteturae as políticas Produção e manutenção de todos os SDPs necessárias Medindo o eficácia e eficiência do Design de Serviços processo.

6.4.3 Planner TI Um planejador de TI é responsável pela produção e coordenação de planos de TI. Os principais objectivos do papel são os seguintes: • • •

•

•

•

Desenvolver planos de TI que se encontram e continuam a cumprir os requisitos de TI da empresa. Coordenar, avaliar e rever o progresso da implementação de todas as estratégias de TI e planos. Produzir e manter o conjunto global de TI normas, políticas, planos e estratégias, abrangendo todos os aspectos de TI necessários para ar o negócio de uma organização estratégia. TI planejamento inclui a participação na criação de SLAs e planejamento de todos os aspectos de infra-estrutura - interna e externa, pública ou privada, internet e intranet - necessárias para garantir que o provisão de De serviços de TIs satisfaz negócio. Assumir a responsabilidade por todos os aspectos de padrões de TI, política e implementação da estratégia de TI como um todo e para a significativa projetos ou nova e importante estratégico aplicações. Recomendar políticas para o uso eficaz de TI em todo o organização e trabalhar com TI Designers para garantir que os planos e estratégias gerais são desenvolvidas em conjunto com TI projeto para todas as áreas de TI. Comente TI custars contra orçamentos e novos desenvolvimentos, novas propostas para alterá-la iniciando planos e estratégias quando necessário, em conjunto com Gestão Financeira.

ITIL V3 - Service Design - Página:

349 de 477

•

•

•

•

•

• •

•

•

•

•

•

•

Assumir a responsabilidade total para o planejamento, gestão e coordenação de sistemas de TI e serviços, incluindo a investigação, análise, especificação, Design, desenvolvimento, Testes, manutenção de atualização, transição e operação. É essencial que durante a realização dessas actividades, a negócio, Gestão de TI e todos os Serviço de Gestão de processos são mantidos atualizados com o andamento dos projetos. Obter e avaliar propostas de fornecedors de equipamentos, serviços de software, transmissão e outros serviços, assegurando que todos os requisitos de negócio e de TI estão satisfeitos. Identificar internos e externos que influenciam fatores necessidades futuras, previsão e definir planos para o uso eficaz da TI dentro da organização. Patrocinar e monitorar a pesquisa, desenvolvimento e planejamento de longo prazo para o profissionalvisão e uso de arquiteturas de TI, produtos e serviços Comente TI atuação com todas as outras áreas e iniciar as melhorias na organização para garantir que nível de serviços e as metas continuam a ser respeitados em todas as áreas. Assumir a responsabilidade final para priorizar e programar a implementação de serviços novos ou alterados dentro de TI. Trabalhar com a istração sênior e outros especialistas seniores e planejadores na elaboração de planos e tomar decisões de contratação pública aplicáveis a todas as áreas de TI. Reconhecer os drivers de negócio principais e as áreas de necessidade de negócio que não são devidamente apoiados por atuais e planejadas serviços de TI, desenvolvimento de planos de TI e resposta às necessidades do negócio. Identificar adequado aplicaçãos, serviços e produtos, em conjunto com os seus ambientes, para atender as necessidades do negócio dentro do prazo exigido. planejamento Desenvolver os planos iniciais para a implementação de novos autorizados serviços de TI, aplicações e infra-estrutura de apoio, identificando restrições orçamentais, técnicos e de pessoal e custos claramente anúncio e os benefícios esperados. Monitorar o existente planos de TI em relação às necessidades de negócio e de TI estratégia para determinar oportunidades de melhoria processo de negócioes por meio do uso de novas tecnologias, e identificar os riscos imprevistos para a realização do benefício do negócio de previsão. Investigue principais opções para a prestação de De serviços de TIs forma eficaz e eficiente e recomendar soluções inovadoras, com base em novas abordagens para processoes, provisão, Recrutamento e retenção, e oferta global contratos. Produzir estudos de viabilidade de negócios, modelos, modelos de TI, caso de negócios, Sors e ITTs para recomendadas novos sistemas de TI,

ITIL V3 - Service Design - Página:

350 de 477

•

•

• • • •

• •

identificando o negócio impacto, A probabilidade de satisfazer as necessidades do negócio, os benefícios esperados de negócios e os riscos e conseqüências de falha. Supervisionar e coordenar o programa de implementações de TI planejadas do projeto e mudars, tomar as medidas adequadas para identificar e superar problemas e resolver conflitos. Realizar revisões pós-implementação (PIRs) em conjunto com a Gestão de Mudança desses sistemas de informação utilizados na prossecução dos planos, para avaliar até que ponto os benefícios comerciais esperados foram realizados. A ligação com Estratégia,Transição e Operações de equipes e processos para planejar as suas necessidades imediatas e futuras. Prestar assessoria e orientação sobre autoritário nacionais e internacionais relevantes normas, regulamentos, protocolos e tarifas. Documentar todo o trabalho usando padrões exigidos, métodos e ferramentas. Garantir que todos os processos de planejamento de TI, papels, responsabilidades e documentação são regularmente revisados e auditados por eficiência,eficácia e observância. Manter um bom conhecimento geral de todos os recursos de produtos de TI e os quadros técnicos em que eles operar. Caso seja necessário, avaliar mudars para a sua conformidade com as estratégias de projeto, incluindo a participação em reuniões de cabina, se apropriado.

6.4.4 TI Designer / Arquiteto Um Designer de TI / Arquiteto é responsável pela coordenação geral e projeto da tecnologia necessária. Muitas vezes, os designers e arquitetos dentro de grandes organizações que se especializam em um dos cinco aspectos do projeto (ver seção 3). No entanto, uma abordagem integrada do projeto deve sempre ser adotado, portanto, Designers e Arquitetos precisam trabalhar juntos dentro de um método formal e estrutura para garantir projetos consistentes e compatíveis são produzidos. Em organizações menores, alguns ou todos os papels geralmente são combinados, e este é um problema menor, embora uma abordagem formal ainda deve ser usada. Sempre que os projetos são produzidos, eles devem sempre adotar uma abordagem integrada, que abranja todas as áreas, e deve ser aceito e assinado por todas as áreas. Todos os designers precisam entender como arquiteturas, estratégias, projetos e planos se encaixam e todos os principais aspectos do projeto. Designer / Arquiteto deve produzir um mapa detalhado processo que documenta todos os processos e suas interfaces de alto nível. Isso garante que a estrutura global não é desnecessariamente complexa, que interfaces centrais do processo fazem parte do desenho, e apresenta um resumo de todos na forma como o cliente e todos os outros das partes interessadass interagir com os processos.

ITIL V3 - Service Design - Página:

351 de 477

Para desempenhar o papel de designer ou arquiteto, é necessário para a equipe ter um bom conhecimento e experiência prática de filosofias de design e planejamento, incluindo Projeto de Programa, e Serviço de Gestão de, Métodos e princípios. O principal objetivos do Designer IT / Architect são os seguintes: • •

• •

• • • •

• •

•

•

•

Produzir e analisar os projetos de todos os serviços novos ou alterados, SLAs, Olas e contratos. Produzir um mapa de processo de todos os processos e as suas interfaces de alto nível, para garantir a consistência, integração e continuidade através de todos os processos. Projetar arquiteturas de tecnologias seguras e resistentes que atendem todo o futuro atual e previsto requisitos de TI da organização. Garantir que o projeto de todos os processos, papéis, Responsabilidades e documentação são regularmente analisados e auditados para a eficácia, eficiência e conformidade. Projetar um e adequado Portfólio de Serviços, ando todas as atividades dentro do Ciclo de Vida do Serviço completo. Projeto de sistemas de medição e técnicas para apoio à melhoria contínua do serviço provisão e todos os processos de apoio. Produzir e manter-se atualizado todo o projeto de TI, arquitetura, política e especificação documentação. Produzir e manter todos os aspectos da TI especificação, incluindo os projetos globais, arquiteturas, topologias e configurações de infraestrutura, ambiente,aplicaçãos e dados, bem como a documentação de design de todos os sistemas de TI. Isto deve incluir não apenas a tecnologia, mas também o sistema de gestãos, processos, fluxos de informação e serviços externos. Recomendar proativas e inovadoras soluções de TI para a melhoria do design e TI operação quando e onde for possível. Traduzir projetos lógicos em projetos físicos, tendo em conta os requisitos de negócios, ambientes-alvo, processos, atuação requisitos, sistemas e serviços existentes, e quaisquer potenciais relacionados com a segurança aspectos. Criar e manter políticas de TI do projeto, filosofias e critérios, que abrangem todas as áreas, incluindo conectividade, capacidade, Interfaces, segurança, Resiliência, recuperação, o e o remoto, e garantir que todos os novos serviços satisfazer as suas nível de serviços e metas. Trabalhar com Gerenciamento da Capacidade e rever os volumes de tráfego e requisitos de TI, identificação de tendências nos fluxos de tráfego e níveis de serviço. Propor melhorias de projeto Infra-estrutura de TI, Mudanças de capacidade, continuidade, apoio e recuperação, conforme necessário, e estar ciente de operacional requisitos, especialmente em termos de níveis de serviço, disponibilidade,tempo de respostas, segurança e reparar

ITIL V3 - Service Design - Página:

352 de 477

•

•

•

•

• •

• •

• •

•

• • • •

vezes. Todas essas atividades são realizadas em articulação com todos os Serviço de Gestão de processos. Comente TI custars contra prestador de serviços externos, novidades e novos serviços, propostas para mudar de TI iniciam projeto onde as reduções de custos adequadas e benefícios podem ser alcançados, em consulta com Gestão Financeira. Fornecer aconselhamento e orientação para a gestão da projeto e planejamento fases de sistemas de TI, para garantir que os requisitos (nomeadamente a capacidade, a recuperação, desempenho e segurança necessidades) são refletidas no geral especificaçãos. Fornecer aconselhamento e orientação a todas as áreas de TI e gestão de negócios, analistas, planejadores, projetistas e desenvolvedores de todos os aspectos de TI de design e tecnologia. Interface com os desenhistas e projetistas de externa fornecedors e provedor de serviçoss, garantindo todos externo De serviços de TIs são projetados para atender a sua concordou nível de serviços e metas. Desempenhar um importante papel na seleção de qualquer infra-estrutura de TI novo ou soluções de tecnologia. Assumir a responsabilidade técnica de TI padrões política, e design para todos significativos projetos ou principais áreas de aplicação, ajudando com a avaliação de impacto e avaliação de grandes novas opções de design de TI. Prestar assessoria técnica e orientação sobre nacionais e internacionais relevantes normas, regulamentos, protocolos e tarifas. Assumir total responsabilidade pelos aspectos de design de todas as fases do ciclo de vida de sistemas de TI, incluindo a investigação, análise, especificação, Projeto, desenvolvimento, construção, testes, manutenção de atualização, transição, Operação e melhoria. Trabalhar com TI colegas quando necessário, produzindo ou atualização de TI e documentação de projeto corporativo e modelos. Atualizar ou fornecer informações para análises custo-benefício, análises de risco, casos de negócios, Sors e ITTs e planos de desenvolvimento, para ter em conta as decisões de design. Obter e ajudar com a avaliação e selecção de propostas e soluções de fornecedors de equipamentos, softwares e outros serviços de TI e fornecedores de produtos. Construir, interpretar e monitorar o teste planos para verificar correta operação de sistemas completos contra seus objetivos de projeto. Documentar todo o trabalho usando padrões exigidos, métodos e ferramentas. Manter um bom conhecimento técnico de todos os recursos de produtos de TI e os quadros técnicos em que eles operar. Caso seja necessário, avaliar mudars para a sua conformidade com os princípios de design, incluindo a participação em reuniões CAB se for o caso.

ITIL V3 - Service Design - Página:

353 de 477

Nota: Muitas vezes os designers e arquitetos dentro de grandes organizações que se especializam em um dos cinco aspectos do projeto (ver seções 3 e 4 para mais detalhes). No entanto, uma abordagem integrada do projeto deve sempre ser adotado, portanto, Designers e Arquitetos precisam trabalhar juntos dentro de um método formal e estrutura para garantir projetos consistentes e compatíveis são produzidos. Em organizações menores, alguns ou todos os papels geralmente são combinados, e este é um problema menor, embora uma abordagem formal ainda deve ser usada. Sempre que os projetos são produzidos, eles devem sempre adotar uma abordagem holística, abrangendo todas as áreas, e deve ser aceito e assinado por todas as áreas. Todos os designers precisam entender como arquiteturas, estratégias, projetos e planos se encaixam.

6.4.5 Gerente de Catálogo de Serviço O Catálogo de Serviços Gestor tem a responsabilidade de produzir e manter o Catálogo de Serviços. Isto inclui responsabilidades tais como: •

• • •

Garantir que todos operacional serviços e todos os serviços que estão sendo preparados para a gestão operacional são registrados dentro do Catálogo de Serviço Assegurar que todas as informações dentro do Catálogo de Serviço é preciso e up-to-date Assegurar que todas as informações dentro do Catálogo de Serviço é consistente com a informação dentro do Portfólio de Serviços Assegurar que a informação dentro do Catálogo de Serviço está devidamente protegido e apoiado.

6.4.6 Gerente de Nível de Serviço O Gerente de Nível de Serviço tem a responsabilidade de garantir que os objectivos da Gerenciamento de Nível de Serviço são atendidas. Isto inclui responsabilidades tais como: • • •

• •

Mantendo consciente de novas necessidades de negócio Garantir que o atual e futuro serviço requisitos clientes são identificados, entendido e documentado em SLA e documentos SLR Negociar e concordar níveis de serviço a ser entregues com o cliente (interno ou externo); formalmente documentar esses níveis de serviço, SLAs Negociar e concordar OLAs e, em alguns casos, outros SLAs e os acordos que sustentam os SLAs com os clientes do serviço Ajudar na produção e manutenção de um preciso Portfólio de Serviços,Catálogo de Serviços,Application Portfolio e a manutenção correspondente procedimentos

ITIL V3 - Service Design - Página:

354 de 477

• •

•

•

• •

• • • • •

Garantir que as metas acordadas no âmbito subjacente contratos estão alinhados com SLA e metas SLR Assegurar que os relatórios de serviços são produzidos para cada serviço ao cliente e que as violações de SLA alvos são destaque, investigado e as medidas tomadas para prevenir sua repetição A garantia de que o serviço atuação opiniões estão programadas, realizadas com clientes regularmente e são documentados com ações acordadas progrediu Assegurar que as iniciativas de melhoria identificadas no serviço de opiniões são aproveitados e os relatórios de progresso são fornecidas aos clientes Revendo serviço escopo, SLA, OLA e outros acordos em uma base regular, de preferência pelo menos anualmente Garantir que todos mudars são avaliados quanto à sua impacto em nível de serviços, incluindo SLAs, e OLAs subjacente contratoassiduidade, inclusive em reuniões CAB se for o caso Identificar todas as principais das partes interessadass e clientes Em desenvolvimento relaçãos e comunicação com as partes interessadas, os clientes e os principais usuários A definição e adopção de queixas e sua gravação, gestão, escalada, Se necessário, e resolução Gravação em definição e comunicação de todas as reclamações Medir, registrar, analisar e melhorar a satisfação do cliente.

6.4.7 Availability Manager Um Gerente de Disponibilidade tem a responsabilidade de garantir que os objectivos da Gerenciamento de Disponibilidade são atendidas. Isto inclui responsabilidades tais como: • •

•

• •

•

Assegurar que todos os serviços existentes entregar os níveis de disponibilidade acordado com o negócio em SLAs Assegurar que todos os novos serviços são projetados para oferecer os níveis de disponibilidade exigidos pelo negócio, e validação do projeto final para atender os níveis mínimos de disponibilidade, conforme acordado pela empresa para De serviços de TIs Ajudar na investigação e diagnóstico de todos os incidentes e problemas que causam problemas de disponibilidade ou indisponibilidade de serviços ou componentes Participar da Infra-estrutura de TI projeto, incluindo a especificação dos requisitos de disponibilidade de hardware e software Especificando os requisitos para novos ou aprimorados gestão de eventos para sistemas automáticos monitoramento de disponibilidade de TI componentes Especificando o confiança,manutenção e manutenção requisitos para componentes fornecidos pelo interno e externo fornecedors

ITIL V3 - Service Design - Página:

355 de 477

•

•

•

•

• • • • • •

•

Ser responsável por monitorar a disponibilidade de TI real alcançado em relação às metas de SLA, e oferecendo uma gama de TI relatórios disponibilidade para assegurar que concordou níveis de confiabilidade, disponibilidade e facilidade de manutenção são medidos e monitorados em uma base contínua Proativamente melhorar a disponibilidade do serviço, sempre que possível, e otimizando a disponibilidade da infra-estrutura de TI para entregar custo-efetivas melhorias que proporcionam benefícios tangíveis para o negócio Criar, manter e rever regularmente um AMIS e uma visão de futuro Plano de disponibilidade, Que visa melhorar a disponibilidade global de serviços de TI e infra-estrutura componentes, para garantir que os requisitos de disponibilidade existentes e futuros negócios podem ser atendidas Assegurar que o Gerenciamento de Disponibilidade processo, suas técnicas e métodos associados são regularmente revisados e auditados, e que todos estes estão sujeitos à melhoria contínua e permanecem apto para o efeito Criando disponibilidade e recuperação critérios de desenho a ser aplicado a nova infra-estrutura ou desenho melhorado Trabalhando com Gestão Financeira, Garantindo os níveis de disponibilidade exigido TI são custo-justificado Manutenção e preenchimento de um cronograma de testes a disponibilidade de mecanismos de disponibilidade Garantir que todos os testes disponibilidade e planos são testados após cada mudança grande negócio Assistir Segurança e Gerenciamento da Continuidade do Serviço com a avaliação e gestão de risco Avaliando mudars para a sua impacto sobre todos os aspectos de disponibilidade, incluindo a disponibilidade geral do serviço e do Plano de Disponibilidade Participar de reuniões do CAB, quando apropriado.

6.4.8 Gestor de Continuidade de Serviços de TI O Gerente de Continuidade de Serviços de TI é responsável por garantir que os objectivos de TI Gestão da Continuidade do Serviço são atendidas. Isso inclui tarefas e responsabilidades tais como: • •

•

Realizar análises de impacto de negócios para todos os serviços existentes e novos Implementação e manutenção do ITSCM processo, Em conformidade com os requisitos globais do da organização Gestão de Continuidade de Negócios processo, e representando os serviços de TI função dentro do processo de Gestão de Continuidade de Negócios Garantir que todos os planos ITSCM, riscos e atividades de sustentar e alinhar com todos os planos de GCN, riscos e atividades, e são capazes

ITIL V3 - Service Design - Página:

356 de 477

• • • •

• • • •

• • •

• • •

de cumprir as metas acordadas e documentadas em qualquer circunstância Executando avaliação de risco e gestão de risco de prevenção de desastres, onde o custo-justificável e sempre que possível Desenvolvimento e manutenção do organização'S continuidade estratégia Avaliar o potencial serviço questões de continuidade e invocando o Plano de Continuidade do Serviço, se necessário Gerenciando o Plano de Continuidade de Serviço enquanto ele estiver em operação, incluindo failover para um local secundário e restauração para o local principal Realizar revisões post mortem de testes de serviços de continuidade e invocações, e instigar ações corretivas quando necessário Desenvolvimento e gestão da ITSCM planos para garantir que, em todos os momentos, a recuperação objetivos da negócio pode ser conseguida Garantir que todas as áreas de serviços de TI são preparados e capazes de responder a uma invocação dos planos de continuidade A manutenção de um cronograma de testes abrangentes de TI, incluindo testar todos os planos de continuidade, de acordo com os requisitos de negócios e depois de cada mudança grande negócio Proceder a revisões de qualidade de todos os procedimentos e assegurar que estes são incorporados no programa de testes Comunicar e manter a consciência dos objectivos ITSCM dentro das áreas de negócio e áreas de e de serviços de TI Proceder a revisões regulares, pelo menos anualmente, da Continuidade planos com as áreas de negócio para garantir que refletem com precisão as necessidades do negócio Negociação e gestão contratos com fornecedores de terceiros recuperação serviços Avaliando mudars por seu impacto sobre Continuidade de Serviço e Planos de Continuidade Participar de reuniões do CAB, quando apropriado.

6.4.9 Capacity Manager A Capacity Manager tem a responsabilidade de garantir que os objectivos da Gerenciamento da Capacidade são atendidas. Isso inclui tarefas tais como: •

• •

Garantindo que não é adequada TI capacidade para atender aos níveis exigidos de serviçoE que a gestão de TI sênior está corretamente informado sobre como combinar a capacidade ea demanda e para garantir que o uso da capacidade existente é otimizard Identificar, com o Gerente de Nível de Serviço, os requisitos de capacidade através de discussões com o negócio usuários Compreender o uso atual da infra-estrutura e serviços de TI, ea capacidade máxima de cada componente

ITIL V3 - Service Design - Página:

357 de 477

•

• •

• • •

• • • • • • •

•

• • • • •

•

Realizando dimensionamento em todos os serviços propostos e novos sistemas, possivelmente usando modelagem técnicas, requisitos de capacidade para averiguar Previsão das necessidades futuras de capacidade com base em planos de negócios, tendências de uso, dimensionamento de novos serviços, etc Análise de produção, regular e revisão do Plano de capacidade, Em linha com o negócio da organização planejamento ciclo, identificar o uso atual e as necessidades previsíveis durante o período coberto pelo plano Garantir que os níveis adequados de monitoramento de recursos e sistema atuação são definidos Análise de dados de uso e desempenho, e elaboração de relatórios sobre o desempenho em relação às metas contidas no SLAs Aumentar incidentes e problemaÉ quando as violações de capacidade ou desempenho limiars são detectados, e ajudar com a investigação e diagnóstico da capacidade de incidentes relacionados e problemas Identificação e de iniciar qualquer afinação a efectuar a optimizar e melhorar a capacidade ou o desempenho Identificar e implementar iniciativas para melhorar o uso de recursos - por exemplo, gestão da procura técnicas Avaliar novas tecnologias e sua relevância para o organização em termos de desempenho e custar Estar familiarizado com a demanda futura potencial de serviços de TI e avaliando este desempenho em nível de serviços Garantir que todos mudars são avaliados quanto à sua impacto na capacidade e desempenho e reuniões CAB presentes quando apropriado Produzir relatórios regulares de gestão que incluem o uso atual de recursos, tendências e previsões Dimensionamento de todos os serviços propostos e novos sistemas para determinar os recursos do computador e rede necessários, para determinar a utilização de hardware de desempenho, nível de serviços e implicações de custo Avaliar novas técnicas e produtos de hardware e software para uso pelo Gerenciamento da Capacidade que pode melhorar a eficiência e eficácia do processo O teste de desempenho de novos serviços e sistemas Relatórios sobre serviço e componente desempenho em relação às metas contidas no SLAs A manutenção de um conhecimento da demanda futura de serviços de TI e prever os efeitos da demanda sobre os níveis de desempenho Determinar o desempenho nível de serviços que são de fácil manutenção e custo-justificado Recomendando afinação de serviços e sistemas, e fazer recomendações para a gestão de TI na projeto e utilização de sistemas para ajudar a garantir uma utilização óptima de todos os recursos de hardware e software de sistema operacional Atuando como um ponto focal para todos capacidade e atuação questões.

ITIL V3 - Service Design - Página:

358 de 477

6.4.10 Security Manager O Gerente de Segurança é responsável por garantir que os objectivos da Gestão de Segurança da Informação são atendidas. Isso inclui tarefas e responsabilidades tais como: •

• • • • •

• • •

• • •

•

• • •

• •

Desenvolvimento e manutenção do Política de Segurança da Informação e um conjunto de políticas específicas de apoio, garantindo a devida autorização, empenho e apoio da gerência sênior de TI e de negócios Comunicação e divulgação da Política de Segurança da Informação a todas as partes apropriadas Garantir que a Política de Segurança da Informação é aplicada e respeitada Identificação e classificação de TI e informações ativoss (Item de Configuraçãos) e do nível de controlar e protecção exigido Ajudar com análises de impacto nos negócios Execução de Análise de Risco de Segurança e gestão de risco em conjunto com disponibilidade e Gerenciamento da Continuidade do Serviço Desenho segurança controles e planos de segurança em desenvolvimento Desenvolver e documentar procedimentos para a operação e manutenção dos controles de segurança Monitoramento e gerenciamento de todas as violações de segurança e tratar incidentes de segurança, tomando ações corretivas para evitar a recorrência, sempre que possível Relatar, analisar e reduzindo o impacto e volumes de todos os incidentes de segurança em conjunto com Gerenciamento de Problemas Promoção da educação e conscientização de segurança A manutenção de um conjunto de controles de segurança e de documentação, e rever regularmente e auditoria todos os controles e procedimentos de segurança Assegurar todas as alterações são avaliados para o impacto em todos os aspectos de segurança, incluindo a Política de Segurança da Informação e controles de segurança, e participação em reuniões CAB quando apropriado Realização de testes de segurança Participar em quaisquer revisões de segurança decorrentes de violações de segurança e instigar ações corretivas Assegurar que o confidencialidade,integridade e disponibilidade dos serviços são mantidos os níveis acordados no SLAs e que estejam em conformidade com todos os requisitos legais aplicáveis Garantir que todo o o a serviços de parceiros e fornecedores externos está sujeita a acordos contratuais e responsabilidades Atuando como um ponto focal para todos segurança questões.

ITIL V3 - Service Design - Página:

359 de 477

6.4.11 Gerente de Fornecedor O Gerente de fornecedor tem a responsabilidade de garantir que os objectivos da Gestão de Fornecedores são atendidas. Isto inclui as tarefas, tais como: •

• •

• • • •

•

•

•

• •

• •

•

Prestação de assistência na desenvolvimento e revisão de SLAs, contratos, acordos ou quaisquer outros documentos para fornecedores terceiros Garantir que valor para o dinheiro é obtido a partir de todos os fornecedores de TI e contratos Garantir que todos os processos de TI são consistentes fornecedor e interface para todas as estratégias de fornecedores de empresas, processos e termos e condições padrão Manutenção e revisão de um Fornecedor e Contratos Banco de Dados (SCD) Revisão e Análise de Risco de todos os fornecedores e contratos em uma base regular Garantir que qualquer subjacente contratos, acordos ou SLAs desenvolvidos estão alinhados com os da negócio Garantir que todos serviços de apoios são escopo e documentada e que as interfaces e dependências entre fornecedores, serviços de apoio e processos de fornecedores estão acordadas e documentadas Garantir que todos papels e relaçãos entre chumbo e quaisquer fornecedores terceirizados estão documentadas, mantidas e sujeita ao acordo contratual Revisão de processos fornecedores de chumbo "para garantir que todos os fornecedores terceirizados estão cumprindo suas obrigações contratuais Realizar revisões contratuais ou SLA pelo menos anualmente, e garantir que todos contratos são consistentes com os requisitos organizacionais e termos e condições padrão, sempre que possível Atualizando contratos ou SLAs, quando necessário, garantindo que o processo de Gerenciamento de Mudança é seguido A manutenção de um processo para lidar com disputas contratuais, e garantir que todos os litígios são tratados de uma maneira eficiente e eficaz A manutenção de um processo para lidar com o fim esperado, fim precoce ou transferência de um serviço Comunicação, monitoramento e revisão regular fornecedor atuação contra alvos, identificando ações de melhoria conforme o caso e garantir que estas ações são implementadas Garantir mudars são avaliados quanto à sua impacto em fornecedores, serviços de apoio e contratos e reuniões CAB presentes quando apropriado

ITIL V3 - Service Design - Página:

360 de 477

•

Coordenar e apoiar todo indivíduo de TI fornecedor e gestores de contrato, garantindo que cada fornecedor / contrato tem um proprietário designado no provedor de serviços organização.

ITIL V3 - Service Design - Página:

361 de 477

7 considerações de tecnologia É geralmente reconhecido que o uso de Serviço de Gestão de ferramentas é essencial para o sucesso de todo o processo, mas as implementações mais pequenas muito. No entanto, é importante que a ferramenta de e a ser utilizado o processoes - e não o contrário. Como regra geral, não modificam os processos para ajustar a ferramenta. No entanto, com o uso de ferramentas para apoiar os processos, existe uma necessidade de ser pragmáticos e reconhecer que pode não haver uma ferramenta que a o processo desenvolvido totalmente, de modo que um elemento de um processo de re-concepção pode ser necessário. Não limitar os requisitos de funcionalidade: considerar a capacidade do produto de executar, ampliar o tamanho das bases de dados, recuperação de falha e manter a integridade dos dados. Será que o produto em conformidade com as normas internacionais? É eficiente o suficiente para que você possa atender às suas necessidades de Gerenciamento de Serviço? Muitas vezes, as organizações acreditam que através da compra ou o desenvolvimento de uma ferramenta de todos os seus problemas serão resolvidos, e é fácil esquecer que ainda estamos dependentes do processo, o função e, mais importante, as pessoas. Lembre-se: "Um tolo com uma ferramenta ainda é um tolo"

ITIL V3 - Service Design - Página:

362 de 477

7,1 projeto Ferramentas de serviço Existem muitas ferramentas e técnicas que podem ser usadas para ajudar na projeto de serviços e de seus associados componentes. Estas ferramentas e técnicas permitem: • • • • •

Design de hardware Design de software Projeto ambiental Projeto de processos Design de dados.

As ferramentas e técnicas são muitas e variadas, incluindo tanto o proprietário e não-proprietário, e são úteis em: • • • • • •

Acelerar o processo de design Garantir que as normas e convenções são seguidas Oferecendo prototipagem, modelagem e instalações de simulação Habilitando 'E se?' Cenários a serem analisados Interfaces de Habilitação e dependências para verificar e correlacionados Validar projetos antes que eles sejam desenvolvidos e implementados para garantir que eles satisfazer e cumprir os seus requisitos pretendidos.

Em desenvolvimento Design de Serviçoss pode ser facilitada pela utilização de ferramentas que fornecem vistas gráficas do serviço e dos seus componentes constituintes, a partir do processo de negócioes, através do serviço e SLA à infra-estrutura, ambiente, Dados e aplicaçãos, processoes, Olas, equipes, contratos e fornecedors. Alguns Gerenciamento da Configuração ferramentas fornecem tais instalações, e são por vezes referido como um elemento de Business Service Management (BSM) ferramentas. Eles podem conter ou ser ligada a ferramentas de "auto-descoberta" e mecanismos e permitir que as relações entre todos esses elementos a serem representados graficamente, fornecendo a capacidade de drill down dentro de cada componente e obter informações detalhadas, se necessário. Se este tipo de ferramenta também conter informação financeira, e são então ligados ao KPIs fornecem uma "árvore Métricas 'e métricos dos vários aspectos do serviço, o serviço pode ser monitorado e controlado através de todas as fases da sua ciclo de vida. Compartilhar este conjunto único e centralizado de informações sobre o serviço permite que todos na provedor de serviços organização e do negócio para ar uma visão única, consistente, "mundo real" do serviço e seu desempenho, e fornece uma base sólida para o desenvolvimento de boas relações e parcerias entre o prestador de serviço e seu clientes.

ITIL V3 - Service Design - Página:

363 de 477

Estes tipos de ferramentas não só facilitar os processos de design, mas também muito apoiar e ajudar todos os estágios no ciclo de vida do serviço, incluindo: • • • • • • • • • • • •

Gestão de todas as fases do ciclo de vida de serviço Todos os aspectos do serviço e de suas atuação Realização de serviços, SLA, OLA, contratual e fornecedor relatórios, medição e gestão Métricas consolidadas e árvores métricas, com pontos de vista de gestão de instrumentoss até detalhada desempenho dos componentes, informações e culpa análise e identificação Visualizações consistentes e consolidadas em todos os processos, sistemas, tecnologias e grupos Relações e integração do negócio e seus processos com De serviços de TIs, sistemas e processos Um conjunto abrangente de recursos de pesquisa e relatórios, permitindo que informações precisas e análise para tomada de decisão informada Gestão de serviço custars Gestão de relaçãos, interfaces e inter-dependências Gestão do Portfólio de Serviços e Catálogo de Serviços A Sistema de Gerenciamento da Configuração (CMS) Um Sistema de Gerenciamento do Conhecimento (SKMS).

As seguintes atividades genéricos serão necessários para implementar essa abordagem: •

• • • • •

Estabelecer o genérico ciclo de vida para ativos de TI (Requisitos, Projeto e desenvolver, Construir, Testar, implantar Operar e Otimizar, Dispose) e definir o principal processoes, políticas, atividades e tecnologias em cada fase do ciclo de vida para cada tipo de ativo Formalizar as relações entre os diferentes tipos de TI ativos, Ea relação entre TI e gestão de aquisição de ativos e de outras disciplinas de TI Definir todos os papéis e as responsabilidades envolvidas em atividades de TI de ativos Estabelecer medidas para a compreensão do Custo (total) de propriedade de um serviço de TI Estabelecer políticas para a reutilização de ativos de TI através de serviços, por exemplo, em nível corporativo Definir um estratégia para a aquisição e gestão de ativos de TI, incluindo a forma como deve ser alinhado com a TI e outras estratégias de negócio.

Para o tipo de ativo aplicações, adicionalmente: •

Definir um estratégia para a aquisição e gestão de TI ativoss, incluindo como ele deve estar alinhado com a TI e outras estratégias de negócios

ITIL V3 - Service Design - Página:

364 de 477

• • •

•

•

Documentar o papel desempenhado pela aplicaçãos na entrega de De serviços de TIs para o negócio Verifique se o ciclo de vida de ativos de TI genérico modelo é adaptada a um ciclo de vida de aplicações, adaptados para diferentes tipos de aplicação Estabelecer normas para o uso de diferentes abordagens para o desenvolvimento de aplicaçãos, e reconhecer o papel das metodologias de desenvolvimento, incluindo os baseados em 'reutilização' (ver a seção sobre Design e Desenvolvimento para discussão) Certifique-se que procedimentos estão no local para considerar todos os tipos de requisitos (como serviço de operacionalidade, atuação,manutenção,segurança) Nas fases iniciais de desenvolvimento da aplicação Definir normas para decidir sobre a entrega ideal de aplicaçãos para o organização, Tais como o uso de Provedores de Serviços de Aplicação, Desenvolvimentos personalizados, COTS e personalização do pacote.

Para o tipo de ativo de dados / informações, adicionalmente: •

Estabelecer como os princípios gerais de TI e gestão de aquisição de ativos pode ajudar a gerenciar os dados / informações recursos de uma organização.

Garantir que os projetos de dados são realizados à luz de: • • • • • • • •

A importância dos metadados padronizados e reutilizáveis A necessidade de qualidade de dados O valor dos dados para uma organização A necessidade de istração de dados e habilidades de istração de banco de dados Compreender o 'corporate (ou comum / cooperativa) Área de assunto e individual serviço ("Sistema") exibições de dados A necessidade de gerenciar dados de tipos de dados não tradicionais, tais como texto, imagens digitalizadas, vídeo e áudio A consciência do armazenamento principal, segurança e questões legais para dados Especificar como o modelo de ciclo de vida genérico ativos de TI pode ser adaptado para o tipo de ativo de dados.

Para o Infra-estrutura de TI e tipo de ativo ambiental, adicionalmente: •

Estabelecer normas para aquisição e gestão do equipamento de infraestrutura de TI e ambientais (incluindo hardware, software poder, O / S, dbms software, middleware e redes), e garantir que eles fornecem uma

ITIL V3 - Service Design - Página:

365 de 477

• • •

base estável ainda adaptável que sustenta o próvisão de serviços de TI para o negócio Estabelecer como o ciclo de vida de ativos de TI genérico modelo deve ser adaptado para um ciclo de vida de infra-estrutura de TI específicas Estabelecer atividades para otimizar o uso da infraestrutura de TI ativoss através da sua reutilização Especificar a necessidade de ferramentas e descrever como a sua utilização global e integração auxilia na gestão de uma infra-estrutura de TI eficaz e serviços relacionados.

Para as habilidades, competências (pessoas), adicionalmente: • •

• •

Formalizar como as competências dos indivíduos responsáveis pelos ativos de TI e serviços relacionados podem ser considerados como um ativo dentro da organização e são gerenciados como tal Especificar como o ativo de TI ciclo de vida aplica-se a pessoas ativos, particularmente em termos de competências mensuráveis, como a habilidade, conhecimento, entendimento, qualificações, experiência, atitude e comportamento Garantir a documentação das competências actualmente em vigor e especificar como estes podem ser reutilizados ou reforçada Garantir padrões de organização são compatíveis com os actuais quadros de competência padrão para o setor de TI, tais como SFIA + (habilidades para a Era da Informação) aptidões e competências são incorporados em papéis e responsabilidades.

Além disso, a fim de estabelecer interfaces eficazes e dependências: • • •

Definir as interfaces que a TI aquisição de ativos e gestão tem com ele habilitado Mudança de Negócios, IT Project Gestão e TI Segurança Formalizar as interfaces que a TI aquisição de ativos e gestão tem com funções e processoes fora de TI Finalmente formalizar medição e relatório nesta área: o Identificação adequada métricos e os relatórios sobre TI ativoss para a distribuição em toda a organização, conforme apropriado o Formalização de controle de qualidade e medição na aquisição e gestão de ativos de TI.

ITIL V3 - Service Design - Página:

366 de 477

7,2 Ferramentas de Gestão de Serviço Ferramentas irá permitir o Design de Serviços processos para trabalhar de forma mais eficaz. Ferramentas aumentará eficiência e eficáciaE fornecer uma riqueza de gestão da informação, Que conduz à identificação de áreas fracas. Os benefícios a longo prazo a serem obtidos a partir do uso de ferramentas são economias de custo e aumento de produtividade, o que por sua vez pode levar a um aumento na qualidade do serviço de TI próvisão. O uso de ferramentas permitirá a centralização de processos-chave e da automação e integração do núcleo Serviço de Gestão de processos. Os dados brutos recolhidos pelas ferramentas podem ser analisados, resultando na identificação de "tendências". Medidas preventivas podem então ser aplicadas, novamente a melhoria da qualidade do serviço de TI próvisão. Alguns pontos que as organizações devem considerar ao avaliar ferramentas de gerenciamento de serviços incluem: • •

• • • • • • • • •

Estrutura de dados, processamento de dados e de integração Integração de multi-fornecedor de infra-estrutura componentes, e a necessidade de se absorver novos componentes no futuro - estes colocará exigências particulares sobre a manipulação de dados e modelagem capacidades da ferramenta A conformidade com as normas internacionais abertas Flexibilidade no compartilhamento de uso, implementação e dados Usabilidade - A facilidade de uso permitido pela usuário interface e para monitoramento nível de serviços Distribuído clientes com uma base de dados centralizada partilhada (por exemplo, o cliente servidor) Requisitos de conversão de dados previamente rastreados Dados apoio,controlar e segurança As opções de e oferecido pelo fabricante da ferramenta de Escalabilidade para o aumento da capacidade (o número de utilizadores, o volume de dados e assim por diante).

Consideração deve ser dada aos requisitos exatos para a ferramenta. Quais são os requisitos obrigatórios e quais são os requisitos desejados? Geralmente a ferramenta deve apoiar os processos, e não o contrário, para minimizar a modificação dos processos para se adequar a ferramenta. Sempre que possível, é melhor para comprar um instrumento totalmente integrado (embora não seja à custa da eficiência e eficácia) para apoiar a muitos (se não todos) Serviço de Gestão de processos. Se isto não for possível, deve-se considerar que as interfaces entre as diferentes ferramentas. É essencial ter um Declaração de Requisitos (SOR) para utilização durante o processo de selecção - este comando pode ser utilizado como uma "lista de ITIL V3 - Service Design - Página:

367 de 477

carrapato '. Os requisitos das ferramentas devem ser classificados usando o MoSCoW análise: • • • •

M - deve ter presente S - devem ter este se possível C - poderia ter isso se ele não afeta qualquer outra coisa W - não terá esse tempo, mas gostaria no futuro.

A ferramenta deve ser flexível para ar adequadamente o seu o necessário direitos. Você deve ser capaz de determinar quem tem permissão para ar quais dados e com que finalidade, por exemplo, o de leitura clientes. Nos estágios iniciais, a consideração também deve ser dada para a plataforma sobre a qual a ferramenta que se espera que operar - Isto pode ser em hardware e software existentes ou uma nova compra. Pode haver restrições impostas por TI estratégia - Por exemplo, todos os novos produtos podem ter a residir em específico servidors. Isto pode restringir o qual os produtos podem ser incluídos na avaliação processo. Certifique-se de que a aquisição se encaixa dentro existente aprovado orçamentos. Existem ferramentas de Serviço de Gestão muitos disponíveis. Detalhes podem ser encontrados na internet, Serviço de Gestão de publicações, de pedir outras organizações, de pedir consultores ou a participar de seminários e conferências para ver quais os produtos que estão disponíveis. Durante os estágios iniciais do processo de seleção, pensar fornecedor e credibilidade da ferramenta. Eles ainda estão indo para apoiar a compra em alguns meses ou daqui a um ano? Considere o registro do ado fornecedor , bem como a da ferramenta. Telefone Service Desk do fornecedor para ver como é fácil de ar, e fazer algumas perguntas de teste para avaliar a sua competência técnica. Peça ao vendedor para organizar uma visita a um site de referência para ver o que a experiência é com a ferramenta na prática - se possível sem o vendedor ou fornecedor atual. Certifique-se de que o organização tem requisitos semelhantes da ferramenta. Veja a ferramenta em funcionamento e falar com os usuários sobre suas experiências, tanto inicialmente e em curso. Avaliar as necessidades de treinamento da organização e avaliar a capacidade do fornecedor para fornecer a formação adequada. Também a formação contínua atualização e ferramenta (upgrades e mudanças na usuário requisitos) terá que ser avaliada para determinar o e e treinamento custars. Em particular, considerar os custos de treinamento, local de treinamento, tempo necessário, como logo após o treinamento da ferramenta estarão em uso, e durante a implementação projeto assegurar que a formação suficiente é fornecido - pensar sobre como a nova ferramenta terá um impacto tanto de TI e

ITIL V3 - Service Design - Página:

368 de 477

cliente. Também garantir que as interfaces com outras ferramentas e telefonia estão funcionando corretamente. É sábio para identificar se a combinação planejada tem sido usado (ou tentou) em outro lugar e com que resultados. Considere os períodos de paralelo correr ao lado de soluções existentes antes de finalmente ir viver. Ao avaliar ferramentas, um ajuste de 100% para os requisitos não deve ser esperado e quase certamente não ser encontrado. A regra '80 / 20 'deve ser levado em vigor vez. A ferramenta é considerado adequado para a sua finalidade, se encontra 80% ou mais do negócio'S requisitos operacionais. Aqueles operacional requisitos devem ser classificados como discutido anteriormente. Qualquer produto deve ser rejeitada como inadequada se não de todos os requisitos obrigatórios ('must haves') são satisfeitas. Em algumas circunstâncias, será impossível encontrar um produto de software existente, que quer atender a todos os requisitos obrigatórios ou fornecer uma correspondência de 80%. Nesta situação, o produto oferece a melhor design funcional devem ser selecionados e os elementos inadequados re-escrito. Este processo de melhoria deve ser feito pelo fornecedor, se possível. Em alguns casos, parte dos custos de melhoria podem ser cumpridas pelo comprador. Alguns produtos foram concebidos para incluir usuário ganchos - isto proporciona ibilidade ao local de código escrito em pontos-chave do processo, sem a necessidade de um pacote a ser modificado. Ela não termina quando o produto foi selecionado. Em muitos aspectos, este poderia ser considerado como apenas o começo. A ferramenta agora tem de ser implementada. Uma vez que a plataforma de hardware foi preparado e carregado o software, a população de dados precisa ser considerada. O que, de onde, como e quando? O tempo é importante para a implementação de testes, e os go-live processoes. Recursos deve estar disponível para garantir o sucesso. Em outras palavras, não agendar a implementação durante um determinado período ocupado, como no final do ano de processamento. Software de hoje como um serviço«Os produtos estão disponíveis em hardware e software não são necessários. Estes produtos dão o baseado em rede e gestão de software disponível comercialmente. Estes tipos de produtos ainda exigirão planejamento e implementação, mas isso deve simplificar o processo como nenhum hardware dedicado é necessário. Deverá também ser dada para gerenciado provedor de serviçoss e Application Service Providers, que pode ser capaz de fornecer a mesma funcionalidade. Em qualquer ferramenta ou o tipo de ferramenta é escolhido, o cumprimento os requisitos podem ser diferenciados entre: •

Out-of-the-box - A exigência é cumprida

ITIL V3 - Service Design - Página:

369 de 477

• •

Configuração - A ferramenta pode ser configurada com x dias de esforço para preencher o requisito e este será preservada durante actualizações de produtos Personalização - A ferramenta deve ser reprogramado com x dias de esforço para cumprir a exigência, E este pode ter de ser repetida em cada actualização do produto.

Personalização extensiva de qualquer produto é sempre melhor evitar por causa da alta custars incorridos na atualização do produto. Os vendedores podem não estar dispostos a apoiar versões antigas, e os compradores podem ser incapazes de o recurso necessário re-aplicação de qualquer personalização sob medida. Personalização também pode liberar o fornecedor de grande parte das suas obrigações de apoio - isso seria desastroso se, como resultado, sua Serviço de Gestão de sistema não estiver disponível por qualquer período de tempo. Os custos adicionais seriam incorridos na prestação do treinamento personalizado, que seria necessário. Seria impossível para tirar vantagem de qualquer baratos cursos de formação programados sendo executados pelo software fornecedor. O processo de avaliação da ferramenta é mostrada na Figura 7.1.

Figura 7.1 Serviço de Gestão de processo de avaliação de ferramentas

A Figura 7.1 mostra a abordagem padrão de identificação de requisitos antes de identificação de produtos, mas de forma pragmática pode haver algum elemento de sobreposição, onde a exploração de ferramentas no mercado abre os olhos para novas opções que mudam os requisitos. Estes estágios são direcionados

ITIL V3 - Service Design - Página:

370 de 477

principalmente ao avaliação de pacotes de produtos de software, mas uma abordagem semelhante pode também ser utilizado na avaliação construído sob encomenda software. Produzir uma clara Declaração de Requisitos (SOR) que identifica os requisitos de negócio em conjunto com as instalações obrigatórias e as características de que seria "bom ter". Também identificar as políticas do site e as normas a que o produto deve estar de acordo. Tais padrões podem incluí-lo em execução no software do sistema particular, ou em hardware específico. Lembre-se as considerações sobre o fornecedorAdequação 's, e realizar uma avaliação formal dos produtos em questão. Se as ferramentas bem desenvolvidas e adequadas são utilizados para apoiar os processos, os resultados obtidos será muito maior e, frequentemente, os custos globais de serviço provisão será menor. Selecionar a ferramenta certa significa prestar atenção a uma série de questões: • • • • • • • • • • • • • •

Um ajuste de 80% a todos os requisitos funcionais e técnicos Uma reunião de todos os requisitos obrigatórios Personalização de produtos pouco (se houver) necessário A adesão da ferramenta e fornecedor para Gestão de Serviços melhores práticas Uma estrutura de dados de som e manuseamento Integração com outros Serviço de Gestão de e ferramentas de Gestão Operacional e de padrões abertos e interfaces Business-Driven não impulsionada pela tecnologia istração e manutenção custars dentro orçamento Níveis aceitáveis de manutenção e liberar políticas Segurança e integridade Disponibilidade de serviços de formação e consultoria Geração de relatório boa Escalabilidade e crescimento.

ITIL V3 - Service Design - Página:

371 de 477

8 Design de Serviços Implementar Esta seção da publicação considera que a tarefa de implementar a Design de Serviços processos e aborda questões como: • • •

Por onde começar? Como podemos melhorar? Como sabemos que estamos a fazer progressos?

As atividades de implementação e melhoria Service Design precisa ser focada nas necessidades e desejos do cliente e a negócio. Portanto, essas atividades devem ser orientadas e priorizados por: • •

Necessidades de negócio e impactos nos negócios Os riscos para os serviços e processoes.

As atividades serão influenciada significativamente pelos requisitos descritos nas SLRs e pelos acordos feitos no SLAs.

ITIL V3 - Service Design - Página:

372 de 477

8.1 Análise de Impacto no Negócio Uma valiosa fonte de entrada ao tentar verificar as necessidades de negócios, impactos e riscos é o Análise de Impacto no Negócio (BIA). A BIA é um elemento essencial de todo o processo de continuidade de negócios (ver secção 4.7) e vai ditar o estratégia para a redução de riscos e recuperação de desastres. Sua finalidade é normal para identificar o efeito de um desastre teria sobre o negócio. Ela vai mostrar quais partes do organização serão os mais afectados por um incidente grave e qual o efeito que isso terá sobre a empresa como um todo. É, portanto, permite o reconhecimento das funções de negócios mais críticos para a sobrevivência da empresa e onde esta criticidade difere, dependendo da hora do dia, semana, mês ou ano. Além disso a experiência tem mostrado que os resultados da BIA pode ser um contributo extremamente útil para um certo número de outras áreas, e vai dar uma compreensão muito maior do serviço do que seria o caso. A BIA pode ser dividido em duas áreas: • •

Um a gestão de negócios, que tem de investigar o impacto da perda (ou perda parcial) de um processo de negócio ou um negócio função. Isto inclui o conhecimento de solução manuals e a sua custars. Um segundo papel localizado em Serviço de Gestão de é essencial para quebrar os efeitos da perda de serviço para a empresa. Este elemento da BIA mostra o impacto da interrupção do serviço ao negócio. Os serviços podem ser gerenciados e influenciados pelo Service Management. Outros aspectos também cobertos em 'Negócio BIA' não pode ser influenciado pelo Service Management.

Como parte da fase de concepção de um novo serviço ou alterados, a BIA deve ser realizada para ajudar a definir a continuidade do negócio estratégia e permitir uma maior compreensão sobre a função e importância do serviço. Isso vai permitir que a organização define: •

• • • •

Quais são os serviços essenciais, o que constitui um grande incidente sobre esses serviços, bem como o impacto subseqüente e inconvenientes causados aos negócios - importante para decidir quando e como implementar mudars Níveis aceitáveis e horários dos níveis de interrupção do serviço - uma vez mais importantes na consideração de cronogramas de mudança e implementação Negócios críticos e períodos de serviço - períodos importantes para evitar O custo de perda de serviço - importante para Gestão Financeira O potencial segurança implicações de uma perda de serviço considerações importantes na gestão de risco.

ITIL V3 - Service Design - Página:

373 de 477

8,2 Nível Requisitos de Serviço Como parte do Gerenciamento de Nível de Serviço processo (ver Capítulo 4), a Nível Requisitos de Serviço para todos os serviços será apurado e capacidade para entregar a estes requisitos serão avaliados e, finalmente, concordou em um formal SLA. Para novos serviços, os requisitos devem ser verificada no início do desenvolvimento processo, e não após a conclusão. Construir o serviço com os Requisitos de Nível de Serviço em primeiro lugar em mente é essencial do ponto de vista Design de Serviços.

8,3 Riscos para os serviços e processos Ao implementar o Design de Serviços e ITSM processoes, business-as-usual práticas não deve ser afetado negativamente. Este aspecto tem de ser considerado durante a produção e selecção da solução preferida para assegurar que a perturbação operacional serviços é minimizado. Este avaliação de risco deve ser considerado em detalhe no Transição de Serviço atividades como parte do processo de implementação

ITIL V3 - Service Design - Página:

374 de 477

8,4 Service Design Implementar O processo, política e arquitetura para o projeto de De serviços de TIs descrito nesta publicação terá de ser documentado e utilizado para garantir o adequado inovadores serviços de TI pode ser projetado e implementado para atender atuais e futuros requisitos de negócios acordados. O IT Service Management processos descritos no capítulo 4 desta publicação e nas publicações nesta série também terá de ser implementada para garantir a prestação de serviços que corresponda às exigências da negócio. A questão muitas vezes colocada é "Qual processo devo implementar primeiro? 'A verdadeira resposta é de todos eles, como o verdadeiro valor da aplicação de todas as Serviço de Gestão de processos é muito maior do que a soma dos processos individuais. Todos os processos estão interligados e, em alguns casos, são totalmente dependentes de outras pessoas. O que é necessário é em última análise, um conjunto único e integrado de processos, fornecendo gerenciamento e controlar de um conjunto de serviços de TI em todo o seu ciclo de vida. Embora reconhecendo que, para obter o benefício completo de implementação de IT Service Management, todos os processos precisam ser abordados, também se reconhece que é improvável que as organizações podem fazer tudo de uma vez. Portanto, é recomendável que as áreas de maior de precisar de ser tratada primeiro. Uma avaliação detalhada precisa ser realizado para verificar os pontos fortes e fracos dos serviços de TI próvisão. Esta deve ser realizada através da realização de pesquisas de satisfação de clientes, falando com clientes, conversando com o pessoal de TI e analisar os processos em ação. Disto avaliação, De curto, estratégias de médio e longo prazo pode ser desenvolvida. Pode ser que a "progressos rápidos" devem ser implementadas a curto prazo para melhorar a situação actual, mas estes processos melhorados podem ter que ser descartado ou alterado, como parte das estratégias de médio ou longo prazo. Se "progressos rápidos" são implementadas, é importante que eles não devem ser realizados à custa do longo prazo objetivos, assim que estes devem ser considerados em todos os momentos. No entanto, cada organização terá que começar de algum lugar, eo ponto de partida será sempre que a organização está agora em termos de TI Serviço de Gestão de maturidade. Prioridades de implementação deve ser definido contra os objetivos de um SIP. Por exemplo, se disponibilidade de De serviços de TIs é uma questão crítica, concentrar-se nos processos que visam maximizar a disponibilidade (por exemplo, Gerenciamento de Incidentes, Gerenciamento de Problemas,Gestão da Mudança e Gerenciamento de Disponibilidade). Ao longo do processo de implementação, os principais atores devem estar envolvidos no processo de

ITIL V3 - Service Design - Página:

375 de 477

tomada de decisão. Estas incluem receptores, bem como fornecedores da serviço. Não pode haver uma tendência, ao analisar as áreas de maior necessidade, para ir direto para as ferramentas para melhorar a situação. Oficinas ou grupos de foco será benéfico na compreensão dos requisitos e do processo mais adequado para a aplicação que irá incluir pessoas, processos, produtos e parceiros. A primeira coisa a fazer é estabelecer um processo formal e método de implantação e melhoria de Design de Serviços, Com a apropriada governo no lugar. Este processo formal deve ser baseado em torno do processo de seis fases ilustrada na Figura 8.1. Mais informações também podem ser encontradas neste processo na publicação Melhoria de Serviço Continuada. É importante que aquando da aplicação ou a melhoria processoes um método estruturado de gestão de projeto é usado. O processo de melhoria pode ser resumido como, em primeiro lugar, compreender o visão determinando a alto nível objetivo de negócios. A "visão de definição de 'deve definir e alinhar negócios e estratégias de TI. Segundo, a avaliação da situação atual para identificar os pontos fortes que podem ser construídas sobre e fracos que precisam ser abordadas. Por isso, "Onde estamos agora? 'É uma análise da situação atual em termos do negócio, organização, Pessoas e processos. Terceiro, "Onde queremos ser?" É um desenvolvimento dos princípios definidos na visão de definição de, concordando as prioridades de melhoria, e quarta, detalhando o SIP para obter maior qualidade de serviço próvisão. Em seguida, medições e métricos precisam de ser postas em prática para mostrar que as metas foram alcançadas e que os objetivos de negócios e prioridades de negócios foram cumpridos. Finalmente, o processo deve assegurar que o ritmo de qualidade melhoria é mantida. A seguir, são elementos-chave para o alinhamento de TI com sucesso os objetivos de negócios: •

• • • • • • •

Visão e liderança na criação e manutenção de estratégico direção, objetivos claros, e medição de realização do objetivo em termos de estratégico direção Aceitação da inovação e novas formas de trabalho Profundo conhecimento do negócio, a sua das partes interessadass e seu ambiente A equipe de TI entender as necessidades do negócio O negócio compreender o potencial da TI Informação e comunicação disponíveis e íveis a todos que precisa Tempo alocado separadamente para se familiarizar com o material Acompanhamento contínuo de tecnologias para identificar oportunidades para o negócio.

ITIL V3 - Service Design - Página:

376 de 477

O ciclo de implementação / melhoria é útil para verificar o alinhamento entre o negócio ea TI, como mostrado na figura 8.1.

Figura 8.1 ciclo de implementação / melhoria

8.4.1 O que é a visão? O ponto de partida para todas essas atividades é o cultura e meio ambiente da provedor de serviços organização. As pessoas ea cultura tem que ser adequado e aceitável para a melhoria e mudança. Portanto, antes de tentar qualquer outra coisa, a cultura dentro do prestador de serviços precisa ser revista para garantir que ele irá aceitar e facilitar a implementação das mudanças requeridas e melhorias. As etapas seguintes devem ser preenchidos para alcançar esta fase do ciclo de: • • • • • •

Estabelecer um visão, Alinhado com a visão do negócio e objetivos Estabelecer a escopo do projecto /programa Estabelecer um conjunto de objetivos de alto nível Estabelecer governoE patrocínio orçamento Obter compromisso da alta istração Estabelecer um cultura focada em: • Qualidade • Cliente e foco dos negócios • Um ambiente de aprendizagem • Melhoria contínua • Compromisso com o 'ciclo de melhoria " • Propriedade e responsabilidade.

ITIL V3 - Service Design - Página:

377 de 477

8.4.2 Onde estamos agora? Uma vez que o visão e objetivos de alto nível foram definidos, o provedor de serviços então precisa analisar a situação actual, em termos do que processoes estão no lugar ea maturidade da organização. Os os e atividades que precisam ser concluídas aqui são: •

•

Arever,avaliação ou um mais formal auditar da situação atual, usando uma técnica preferida: • Uma revisão interna ou auditoria • Avaliação de maturidade • Uma avaliação externa ou referência • Um ISO / IEC 20000 auditoria • Uma auditoria contra COBIT • A Forças, Fraquezas, Oportunidades e Ameaças (SWOT) análise • Aavaliação de risco e gestão metodologia A revisão deve incluir: • A cultura e maturidade da provedor de serviços organização • Os processos em andamento e seus capacidade e maturidade • As habilidades e competências das pessoas • Os serviços e tecnologia • O fornecedors, contratos e a sua capacidade • O qualidade de serviço e as medidas atuais, métricos e KPIs • Um relatório que resume as conclusões e recomendações.

A revisão da cultura deve incluir a avaliação em termos de capacidade e maturidade da cultura dentro do Provedor de serviços de TI organização, como mostrado na figura 8.2.

Figura 8.2 avaliação de maturidade Cultural

ITIL V3 - Service Design - Página:

378 de 477

Este avaliação deve basear-se no facto de cada fase de crescimento representa uma transformação de TI e, como tal, é necessário: • • • • • •

Mudanças nas pessoas (habilidades e competências) Processos e formas de trabalho Tecnologia e ferramentas (para apoiar e habilitar as pessoas e processos) Direcção (as visões, objetivos e resultados) Atitude (os valores e crenças) O nível adequado eo grau de interação com o negócio,das partes interessadass, clientes e usuários.

A avaliação deve incluir também uma rever da capacidade e maturidade do Design de Serviços processos, como se mostra na figura 8.3.

Figura 8.3 estrutura de maturidade de processo

Esta avaliação e incluir todos os aspectos dos processos e da sua utilização, incluindo o: • • • • •

Visão: Direcção, objetivos e os planos Processo de maturidade, funcionalidade, utilização, aplicação, eficácia e eficiência juntamente com propriedade, gestão e documentação Pessoas: os papels, responsabilidades, competências e conhecimentos das pessoas Produtos, incluindo as ferramentas e tecnologias utilizadas para automatizar os processos Cultura: O foco, atitudes e crenças.

O quadro acima pode ser usado para fornecer a consistência do processo avaliação. Avaliando esses dois aspectos vão determinar o estado atual da organização e os seus Serviço de Gestão de capacidade e maturidade. Ao

ITIL V3 - Service Design - Página:

379 de 477

iniciar-se sobre a implementação ou melhoria de Design de Serviços, Ou qualquer conjunto de processos, é importante aproveitar os pontos fortes das culturas e processos existentes e rapidamente identificar e melhorar os pontos fracos. Uma explicação mais detalhada deste quadro está contida no Anexo H.

8.4.3 Onde é que nós queremos ser? Com base na avaliação do estado atual, eo visão e objetivos de alto nível, um estado futuro desejado pode ser definido. Isto deve ser expresso em termos de projecto resultados, incluindo parte ou a totalidade de: • • • • •

Melhorou o serviço de TI próvisão alinhamento com os requisitos de negócios total Melhoria da qualidade de Design de Serviços Melhorias na nível de serviços e qualidade Aumentos na satisfação do cliente Melhorias no processo atuação.

8.4.4 Como é que vamos chegar lá? Um conjunto de melhorias devem ser identificados para avançar a partir do estado atual para o estado futuro concordou. A plano para implementar essas melhorias devem ser desenvolvidas, incorporando Transição de Serviço e Operação de Serviço, E deve incluir: • • • • • • •

As ações de melhoria A abordagem a adoptar e os métodos a serem utilizados Atividades e os prazos Avaliação de risco e gestão Recursos e orçamentos Papels e responsabilidades Monitoramento, Medição e análise.

8.4.5 Como podemos dizer quando temos lá? Muitas vezes, as organizações instigar iniciativas de melhoria sem considerar ou projetar o sistema de medição desde o início. O sucesso da iniciativa não pode, portanto, ser determinado porque não temos referência antes, durante ou após a aplicação. É imperativo que as medidas são projetados antes da implementação. Um conjunto definido de métricos necessita de ser utilizada, a fim de assegurar que o estado futuro desejado seja alcançado. Este estado futuro desejado precisa de ser expressa em termos mensuráveis, tais como: • • •

X% de redução Design de Serviços não-conformidades X% de aumento na satisfação do cliente X% de aumento do serviço disponibilidade dos serviços críticos.

ITIL V3 - Service Design - Página:

380 de 477

Assim, uma vez que as ações de melhoria e planos foram concluídos, cheques e comentários devem ser concluídas no fim de determinar: • • •

Será que vamos alcançar nosso estado desejado novo e objetivos? Há lições aprendidas e poderíamos fazer melhor da próxima vez? Será que vamos identificar as ações de melhoria outros?

8.4.6 Como é que vamos continuar? Tendo melhorado, agora precisamos consolidar e seguir em frente. O organização e a cultura deve reconhecer que sempre podemos melhorar, e, portanto, deve estabelecer um ambiente de melhoria contínua. Assim, uma vez que conseguimos o novo estado desejado, temos de rever o visão e objetivos, identificar mais ações de melhoria e repetir o estágio de seis processo novamente. Assim, nesta fase, é tudo sobre: • • • •

Desenvolvimento de um ambiente de aprendizagem Estabelecer um desejo de melhorar toda a organização Reconhecer e reforçar a mensagem de que a qualidade ea melhoria são tarefa de todos Manter o ímpeto na melhoria e qualidade.

ITIL V3 - Service Design - Página:

381 de 477

8,5 Medição de Design de Serviços O sucesso do Design de Serviços e para o sucesso da melhoria dos processos de todo o Design de Serviços deve ser medido, os dados devem ser analisados e relatados. Onde o projeto ou processo não satisfaz os requisitos da negócio como um todo, as mudanças no processo podem ser necessários e os resultados de tais alterações devem também ser medidos. Medição contínua, análise e relatórios são requisitos obrigatórios, tanto para o Design de Serviços processo e os processos de ITSM. Existem métodos de medição disponíveis que permitem a análise de melhoria dos serviços. O Balanced Scorecard É um método desenvolvido por Robert Kaplan e David Norton como um conceito para medir as atividades de uma empresa em termos de sua visão e estratégias. Ele dá uma visão abrangente do desempenho de uma empresa. O sistema obriga os gestores a focar o desempenho importante métricoO sucesso da unidade que. Ele equilibra a perspectiva financeira com o processo do cliente, interna e aprendizado e perspectivas de crescimento. Mais informações podem ser encontradas no método Balanced Scorecard na publicação Melhoria de Serviço Continuada. Seis Sigma é uma metodologia desenvolvida por Bill Smith na Motorola Inc., em 1986, e foi originalmente projetado para gerenciar variações do processo que causam defeitos, definidos como desvio inaceitável da média ou de destino, e trabalhar sistematicamente para a gestão variação de eliminar os defeitos. Seis Sigma já cresceu além do controle de defeitos e é frequentemente utilizado para medir a melhoria em TI execução do processo. (Six Sigma é uma marca de serviço registrada e marca registrada da Motorola Inc.) Seis Sigma (DMADV) é um sistema de melhoria usado para desenvolver novos processos em seis níveis de qualidade Sigma e é definido como: • • • • •

Definir - Formalmente definir os objetivos do projeto atividade que estão de acordo com as demandas dos clientes e organização estratégia Medir - Identificar Fator Crítico de Sucessos, a capacidade do processo, capacidade e avaliação de riscos Analisar - Desenvolver e projetar alternativas, criar design de alto nível e avaliar a capacidade de projeto para selecionar o melhor projeto Projeto - Desenvolver o projeto detalhado, otimizar projeto e plano para o projeto verificação Verificar - Criar piloto corridas, implementar a produção processo e entregar a proprietário do processos.

O Seis Sigma processo (DMAIC) (definir, medir, analisar, melhorar, controlar) é um sistema de melhoria de processos existentes caindo abaixo especificação e olhando para a melhoria incremental.

ITIL V3 - Service Design - Página:

382 de 477

8.5.1 Pré-requisitos para o sucesso Há um número de pré-requisitos necessários para a Design de Serviços e a bem sucedida introdução de novos processos ou revisado. Muitas vezes, estes prérequisitos para o sucesso (PFSs) são elementos de um processo requerido por outro. Por exemplo, totalmente preenchido e up-to-date de Negócios Catálogo de Serviços e Catálogo de Serviço Técnico são necessários antes Gerenciamento de Nível de Serviço pode projetar o SLA e estrutura de e acordo, e antes SLM pode configurar e acordar o SLAs. Gerenciamento de Problemas dependerá de uma madura Gerenciamento de Incidentes processo. Os PFSs pode ser muito mais ampla do que apenas interdependências ITSM processo. Por exemplo, a projeto de disponibilidade e capacidade para um novo serviço não pode ser alcançado sem os detalhes do negócio plano para a utilização do novo serviço. O design do serviço será impossível sem a Portfólio de Serviços e Pacote de Desenho de Serviço. Há muitos mais exemplos destes PFSs que precisam ser consideradas e planejadas antes de níveis de maturidade elevados processo pode ser alcançado. Baixo maturidade num processo significa que altos níveis de maturidade não será possível em outros processos.

8.5.2 Fatores Críticos de Sucesso e Indicadores Chave de Desempenho Fator Crítico de Sucesso (CSF) é um termo para um elemento que é necessário para uma organização ou projeto para cumprir sua missão. FCS pode ser usada como um meio para a identificação dos elementos importantes para o sucesso. QCA são as coisas que têm de ser tem direito na Design de Serviços e dentro de cada processo de ITSM. Key Performance Indicators (KPIs) são medidas que quantificam objectivos e permitir a medição de atuação. KPIs devem ser ajustados e medidos em relação à concepção e para cada um dos processos para assegurar os CSFs são cumpridos. Juntos, os QCA e KPIs estabelecem o linha de base e mecanismos de monitoramento de desempenho. Recomenda-se que cada organização de TI se concentra em um pequeno subconjunto de QCA e KPIs a qualquer momento. Os QCA necessários e KPIs devem ser definidos no início do Plano de Melhoria de Serviço Continuada (CSIP). É importante que os QCA são acordados durante a fase de concepção de um serviço e dos processos, e que os indicadores chave de desempenho (KPIs) são definidos, medidos e relatados para indicar o qualidade do Design de Serviços e os processos de design de serviço. Há uma exigência de ser capaz de analisar o quão bem a infra-estrutura de serviços foi concebido. É possível chegar a um bom projeto de uma forma muito ineficiente de recursos, e vice-versa, por isso precisamos de olhar para a qualidade, bem como recursos exigido para obter a

ITIL V3 - Service Design - Página:

383 de 477

qualidade desejada. KPIs todo o sucesso da entrega do serviço indicam o eficácia do Service Design são aplicáveis - por exemplo, se o serviço de cumprir os requisitos (definido) de negócio de disponibilidade, confiança,rendimento,segurança,manutenção,manutenção, Etc funcionalidade? KPIs em torno das estimativas de recursos, no entanto, vai nos mostrar o quão eficiente estávamos no design. Estas devem ser definidas como parte de QA planejamento e liberação aceitação. Estes KPIs poderia ser apoiada por semelhante componente métricos. KPIs para o processo de Design de Serviços incluem: • • • • • • •

Percentagem de exigência Design de Serviços especificaçãos produzidas em tempo (e de orçamento) Percentagem de Design de Serviços planos produzidos no tempo Percentual de pacotes de design de serviço concluídas a tempo Porcentagem de controle de qualidade e critérios de aceitação planos produzidos no tempo Precisão de Design de Serviços - Por exemplo, se a infra-estrutura correta construída para ar o serviço? Precisão percentagem da estimativa de custo de toda a fase de Desenho de Serviço Precisão de SLA (s), OLA (s) e contrato(S) - eles realmente ar o nível de serviço requerido?

Para julgar serviço provisão e desempenho do processo de ITSM, claramente definida objetivos com metas mensuráveis deve ser definido. A confirmação precisa ser buscado que estes objectivos e as metas fixados no Melhoria de Serviço Continuada (CSI) fase do ciclo de vida foram alcançados e que o serviço desejado qualidade ou desejada melhoria de qualidade foi conseguida. É vital na concepção de serviços ou processoes que KPIs são projetados desde o início e recolhido regularmente e nos marcos importantes. Por exemplo, ao conceber a conclusão de cada fase significativa do programa, Uma Revisão Pósimplementação (PIR) devem ser realizados para garantir que os objectivos foram atingidos. O PIR incluirá um rever de documentação de apoio e da conscientização geral de entre o pessoal dos processos refinados. A comparação é necessária do que foi alcançado contra os objetivos originais estabelecidos no projeto. Uma vez que este tenha sido confirmado, novas metas de melhoria devem ser definidos. Para confirmar que as metas foram alcançadas, os KPIs devem ser constantemente monitorados. Estes KPIs incluir metas de satisfação do cliente, por isso não haverá a necessidade de levantamento clientes planejada em várias etapas para confirmar que mudars feitas são a melhoria da percepção do cliente da qualidade do serviço. É possível que os serviços têm maior disponibilidade, que existem menos incidentes e que tempo de respostas têm melhorado, mas ao mesmo tempo a

ITIL V3 - Service Design - Página:

384 de 477

percepção do cliente de qualidade de serviço não melhorou. É evidente que esta é tão importante, e terá de ser abordada por falar com os clientes para determinar suas preocupações. A confirmação deverá ser procurado CSIs que colocar no lugar estão abordando as necessidades primárias do cliente. Para mais informações sobre a melhoria dos serviços práticas, por favor, consulte a publicação Melhoria de Serviço Continuada.

ITIL V3 - Service Design - Página:

385 de 477

9 Desafios, Fatores Críticos de Sucesso e riscos 9,1 Desafios Com cada empresa haverá desafios ou dificuldades para enfrentar e superar. Isto será especialmente verdade quando tentando projetar novos serviços e processos que atendam as necessidades de todos os das partes interessadass no interior da negócio. A experiência tem mostrado que a seguir irá ajudar a superar os desafios: • •

• •

Compreender os requisitos de negócio e as prioridades de negócios e garantir que estes são em primeiro lugar em mente ao projetar os processos e os serviços. A comunicação será de vital importância tanto para explicar o que está acontecendo e como os indivíduos serão afetados e em ouvir as exigências e necessidades dos indivíduos. É de vital importância para se comunicar com as pessoas sobre questões que se relacionam com o seu trabalho diário. Envolver as pessoas como muitos como possível no projeto. Criação de grupos de foco ou grupos de orientação pode ser muito eficaz na obtenção da solução correta, bem como ganhar mais apoio. Ganhando o compromisso da gerência sênior, bem como de todos os níveis de pessoal.

Exemplos de desafios que podem ser enfrentados incluem: •

• • •

• •

A necessidade de garantir o alinhamento com as atuais direções arquitetônicos, estratégia e políticas. Um exemplo disto pode ser que a infra-estrutura pode ter obtido pobre monitoramento e recursos de controle. O uso de tecnologias diversas e díspares e aplicaçãos. Documentação e adesão às práticas e processos acordados. Claro ou mudança de requisitos do negócio. Este pode ser inevitável em alguns casos porque as necessidades de negócios são susceptíveis a alterações. O importante é assegurar que há uma estreita muito relação entre o Provedor de serviços de TI organização e do empresa cliente do serviço, Para que quaisquer mudanças de requisitos pode ser identificado como o mais rapidamente possível. A falta de consciência e conhecimento de serviços e empresas de objectivos e requisitos. Ligada ao ponto acima, pode ser que algumas instalações não são incorporadas ao projeto. Mais uma vez, é imperativo que os representantes de cada usuário do serviço concebido ou processo estão envolvidos em todo o processo para reduzir a chance de que isso

ITIL V3 - Service Design - Página:

386 de 477

• • • • • • • • • • • • • • • •

aconteça. Detalhes do ensaio em serviço (um elemento importante aqui) estão contidas dentro do Transição de Serviço publicação. A resistência aos planejamento, Ou uma falta de planejamento de liderança para iniciativas não planejadas e compras não planejadas. Uso ineficiente de recursoestá causando desperdício gastar e investimento. Como mencionado anteriormente, um bom conhecimento e apreciação dos impactos nos negócios e prioridades é imperativo. Relações ruins, comunicação ou falta de cooperação entre a TI provedor de serviços e a negócio pode resultar no projeto não alcançar os requisitos de negócios. Resistência ao trabalho no prazo acordado estratégia. O uso de, e, portanto, as limitações de, a tecnologia antiga e sistemas legados. Ferramentas necessárias são muito caros ou muito complexo de implementar ou manter com as habilidades dos funcionários atuais. Falta de informação, acompanhamento e medições. Metas razoáveis e prazos previamente acordados no SLA e OLA. Sobre o compromisso dos recursos disponíveis com uma incapacidade associada a entregar (por exemplo, projetos sempre atrasado ou acima do orçamento). Pobre Gestão de Fornecedores e / ou de má fornecedor atuação. A falta de foco no serviço disponibilidade. A falta de conscientização e adesão ao operacional aspectos segurança políticas e procedimentos. Garantir diária normal operação ou de negócios, como de costume é considerado como parte do projeto. Custo e restrições orçamentais. Determinar o retorno do investimento ea realização de benefício do negócio.

ITIL V3 - Service Design - Página:

387 de 477

9,2 Riscos Há um certo número de riscos directamente associada com a Design de Serviços fase do Ciclo de Vida do Serviço. Estes riscos devem ser identificados para assegurar que eles não são realizados. Eles incluem o seguinte: • • • • • • • • • • •

• •

Se algum dos PFSs para Design de serviço não forem satisfeitas, Desenho do Serviço ou Serviço de Gestão de processo não será bem sucedida. Se maturidade os níveis de um processo é baixo, será impossível atingir a plena maturidade em outros processos. Requisitos de negócio não estão claras para a equipe de TI. Prazos de negócios são tais que tempo suficiente é dada ao design de serviço adequada. Teste insuficiente, resultando em má concepção e implementação, portanto, pobres. Um equilíbrio incorreto é atingido entre inovação, risco e custar enquanto procura uma vantagem competitiva, onde desejado pela empresa. O ajuste entre as infra-estruturas, clientes e parceiros não é suficiente para atender os requisitos gerais de negócios. A interface não é fornecido coordenada entre os planejadores e planejadores de negócios. As políticas e estratégias, especialmente as Serviço de Gestão de estratégia, não estão disponíveis a partir de Estratégia de Serviço, Ou o seu conteúdo não é claramente compreendido. Há insuficiência de recursos e orçamento disponível para Design de Serviços actividades. O risco de os serviços desenvolvidos isoladamente usando seus próprios recursos e infra-estrutura ". Isso pode parecer mais barato em isolamento, mas pode ser muito mais caro no longo prazo por causa das economias financeiras de compra corporativa eo custo extra de apoio diferente arquitetura. Tempo insuficiente dada a fase de projeto, ou treinamento insuficiente dado ao pessoal encarregado da projeto. Engajamento insuficiente ou compromisso com a funcional do aplicativo desenvolvimento, Levando a atenção insuficiente às exigências de Design de Serviço.

ITIL V3 - Service Design - Página:

388 de 477

Posfácio Design de Serviços, Tal como descrito nesta publicação, abrange a concepção de apropriada e inovador De serviços de TIs para atender atuais e futuros requisitos de negócios acordados. Design de Serviços desenvolve um Pacote de Desenho de Serviço e olha para selecionar o Design de Serviços apropriado modelo. Nesta publicação, também examinaram os vários modelos de sourcing disponíveis e dado algumas vantagens e desvantagens de cada um. A publicação também aborda os fundamentos do projeto processoes e os cinco aspectos da projeto: • • • • •

O design do serviço As soluções, incluindo todos os requisitos funcionais, recursos e as capacidades necessárias e acordadas A concepção de Serviço de Gestão de sistemas e ferramentas, em especial os Portfólio de Serviços para a gestão e controlar de serviços através de seu ciclo de vida O design das arquiteturas de tecnologia e arquiteturas e ferramentas de gestão necessárias para fornecer os serviços O desenho ou especificação dos processos necessários para projetar, transição,operar e melhorar a atenção, os arquiteturas e os processos próprios O design dos sistemas de medição, métodos e métricos para os serviços, as arquitecturas e seus constituintes componentes e os processos.

A definição de Design de Serviços é a seguinte: "O projeto de adequadas e inovadoras de serviços de TI, incluindo suas arquiteturas, processos, políticas e documentação, para atender às atuais e futuros requisitos de negócios acordados. A publicação explicou que a melhor e mais cuidada do projeto, a melhor solução a ter em operação ao vivo. Também é muito provável que a melhor o projeto, menos tempo re-trabalho que terá de ser realizado durante a transição e as fases vivas. O escopo Esta publicação inclui a concepção de serviços, bem como a concepção de Serviço de Gestão de sistemas e processos. Design de Serviços não se limita a novos serviços, mas inclui mudar necessário aumentar ou manter o valor para os clientes sobre a ciclo de vida de serviços. Esta publicação explica que o pragmatismo às vezes substitui a solução perfeita onde sabemos que o que seria, mas a quantidade de esforço e custar não justifica a solução perfeita. Como sempre, vai depender das necessidades do negócio e os requisitos de negócio. Como sempre, é imperativo que o que é feito dentro de TI tem um benefício direto para o negócio global ITIL V3 - Service Design - Página:

389 de 477

Apêndice A: O Pacote de Desenho de Serviço A 'Pacote de Desenho de Serviço"Ou SDP deve ser produzido durante a fase de projeto, para cada novo serviço, grande alteração a um serviço ou a remoção de um serviço ou mudanças para o" Pacote de Desenho de Serviço "em si. Este pacote é então ado de Design de Serviços para Transição de Serviço e detalhes de todos os aspectos do serviço e seus requisitos através de todas as fases seguintes de sua vida útil. A SDP deverá conter: Categoria

Sub-categoria

Descrição do que está na SDP

Requisitos

Requisitos de negócio

As iniciais acordados e documentados os requisitos de negócios

Aplicabilidade serviço

Isto define como e onde o serviço seria utilizada. Isso poderia fazer referência a cliente de negócios, e usuário requisitos relativos aos serviços internos

Design de Serviços

Contatos de serviços

Os contatos de negócios, contatos de clientes e das partes interessadass no serviço

Requisitos funcionais de serviços

A funcionalidade alterada do serviço novo ou alterado, incluindo a sua planejada resultados e entregas, de um acordo formal Declaração de Requisitos (SOR)

Nível Requisitos de Serviço

O SLR, revista ou uma nova SLA, Incluindo o serviço e qualidade alvos

Serviço e operacional requisitos de gestão

Requisitos de gestão para gerenciar o serviço novo ou alterado e sua componentes, incluindo todos serviços de apoios e acordos, controlar,operação,monitoramento, Medir e informar

Design de Serviços e topologia

O projeto,transição e posterior implementação e operação do serviço solução e seus componentes de e, incluindo: • •

• • •

Avaliação de

Avaliação de

ITIL V3 - Service Design - Página:

A definição de serviço e modelo, para transição e operação Todos os serviços componentes e infra-estrutura (incluindo H / W, S / W, redes, ambientes de dados, aplicaçãos, tecnologia, ferramentas, documentação), incluindo versão números e relaçãos, de preferência dentro da CMS Todos usuário, Serviço, empresa, componente transição, e e documentação operacional Processos, procedimentos, as medições, métricos e relatórios Produtos de apoio, serviços, acordos e fornecedors

Relatório "Avaliação de Prontidão Organizacional" e plano,

390 de 477

prontidão organizacional

prontidão organizacional

Incluindo: o benefício do negócio, financeiro avaliaçãoTécnica, avaliação, avaliação de recursos e avaliação organizacional, juntamente com detalhes de todas as novas habilidades, competências, capacidades exigidas do provedor de serviços organização, A sua fornecedors, serviços de apoios e contratos

Plano de Serviço do Ciclo de Vida

Programa de serviço

Um total programa ou plano que abrange todas as fases do ciclo de vida do serviço, incluindo os prazos e faseamento, para o transição,operação e posterior aperfeiçoamento do novo serviço, incluindo: • • • • • • • • • • •

Plano de Transição de Serviço

Transição global estratégia, Objetivos, política,avaliação de risco e os planos incluindo: •

• •

ITIL V3 - Service Design - Página:

Coordenação, gestão e integração com qualquer outro projetoatividades s, ou novos ou modificados, serviços ou processoes Gestão de riscos e questões Escopo,objetivos e componentes do serviço Habilidades, competências, papels e responsabilidades Processos necessários Interfaces e dependências com outros serviços Gestão de equipes, recursos, ferramentas, tecnologia, orçamentos, instalações necessárias Gestão de fornecedors e contratos Relatórios de progresso, revisões e revisão do programa e planos Planos de comunicação e planos de formação Prazos, resultados, metas e metas de qualidade para cada etapa

391 de 477

Construir políticas, planos e exigências, incluindo o serviço e componente construir planos, especificaçãos, controlar e ambientes, tecnologia, ferramentas, processos, métodos e mecanismos, incluindo todas as plataformas Teste de políticas, planos e exigências, incluindo teste ambientes, tecnologia, ferramentas, processos, métodos e mecanismos O teste deve incluir: • Testes funcionais • Testes de componentes, incluindo todos os fornecedors, contratos e fornecidos externamente produtos e serviços de apoio • Usuário aceitação e usabilidade teste • Compatibilidade de sistemas e testes de integração • Serviço e o desempenho dos componentes e testes de capacidade • Testes de resiliência e continuidade

•

•

Serviço Plano de Aceitação Operacional

Global operacional estratégia, objectivos, a política, avaliação de risco e os planos incluindo: • •

•

Critérios de aceitação de serviços

Falha, Alarme e categorização evento, processamento e teste • Serviço e componente, segurança e integridade teste • Testes de liberação, logística e distribuição • Testes de Gestão, incluindo controlar, Monitorar, medir e informar, juntamente com apoio, A recuperação de toda a programação e processamento em lote e Política de implementação, liberar políticas, planos e exigências, incluindo logística, desenvolvimento, Roll-out, estadiamento, ambientes de implantação, a mudança cultural, mudança organizacional, tecnologia, ferramentas, processoes, a abordagem, métodos e mecanismos, incluindo todas as plataformas, habilidade, conhecimento e transferência de competências e de desenvolvimento, fornecedor e contrato transição, Migração de dados e conversão

Interface e dependência gestão e planejamento Eventos, relatórios, problemas no serviço, incluindo todos os mudars, lançamentos, incidentes resolvidos, problemas e erros conhecidos, incluídos dentro do serviço e quaisquer erros, problemas ou não-conformidades dentro do novo serviço Serviço final aceitação

Desenvolvimento e utilização de Critérios de aceitação de serviços (SAC) para a progressão através de cada estágio do ciclo de vida do serviço, incluindo: • •

Todos os ambientes Garantir e piloto critérios e períodos

Tabela A.1 conteúdo da embalagem Design de Serviços

ITIL V3 - Service Design - Página:

392 de 477

Apêndice B: Critérios de aceitação do serviço (exemplo) O Critérios de aceitação de serviços (SAC) é um conjunto de critérios usados para garantir que a serviço cumpre a sua funcionalidade esperada e qualidade e que o provedor de serviços está pronto para entregar o novo serviço, uma vez que tenha sido implantado. Critérios

Responsabilidade

Ter a data do "go-live" e do prazo de garantia acordado com todas as partes envolvidas, juntamente com os critérios de aceitação finais?

Alterar, Nível de serviço

Tem o desenvolvimento projeto e agendar sido documentado concordou e divulgada a todos os funcionários afetados?

Incidente mudança,

Tem o SLA / SLR sido analisados, revisados e acordados com todas as partes interessadas?

Nível de serviço

Tem o serviço foi inserido / atualizado no Catálogo de Serviços/Portfólio de Serviços dentro do CMS e apropriado relaçãos estabelecidas para todos apoiando componentes?

Nível de serviço de configuração,

Ter todos clientes e das partes interessadass foram identificados e registrados no CMS?

Nível de serviço, Relação Profissional

Ter todos os riscos operacionais associados à execução do novo serviço foi avaliado e ações de mitigação concluída quando apropriado?

Continuidade de Negócios, disponibilidade

Tem de contingência e fail-over medidas foi testado com sucesso e adicionado ao total resiliência testar horário?

Continuidade de Negócios, disponibilidade

Tudo pode SLA / alvos SLR ser monitorado, medido, relatados e revistos, incluindo disponibilidade e atuação?

Nível de serviço, Disponibilidade

Ter todos usuários foram identificados / aprovada e suas contas apropriadas criado por eles?

Gestão de Contas

Pode tudo carga de trabalho características de desempenho, e capacidade alvos ser medidos e incorporados Plano de capacidades?

Capacidade

Ter todos os processos operacionais, horários e procedimentos foi acordado, documentação do site testadas, documentadas e aceitas (por exemplo, apoios, limpeza, arquivamento, retenção)?

Operações de Continuidade de Negócios,

Ter todos os trabalhos de grupo e requisitos de impressão foi acordado, testado, documentado e aceito?

Operações

Ter todos os planos de teste foi completado com sucesso?

Test Manager

Ter todos segurança verificações e testes foram competiu com sucesso?

Cumprimento de Segurança

ITIL V3 - Service Design - Página:

393 de 477

São apropriadas monitoramento e ferramentas de medição e procedimentos para monitorar o novo serviço, Juntamente com um fora-de-hora o apoio Rota?

Sistemas de Gestão

Tenha tudo operacional contínuo carga de trabalhos e custars foi identificado e aprovado?

Operações, TI Finanças

São todos os serviços e componentes custo operacionals entendidos e incorporados financeiro processoes e o custo modelo?

TI Finanças

Ter incidente e categorias de problemas e processos foram analisados e revistos para o novo serviço, juntamente com os erros conhecidos e deficiências?

Incidente Relatórios de Problemas,

Ter todos os novos fornecedors foram identificados e seus associados contratos elaborado em conformidade?

Contrato e Gestão de Fornecedores

Ter todos os mecanismos de apoio foram revistos e revisados SLAs, SLRs, OLAs e contratos acordados, com documentação aceita por todas as equipes (incluindo fornecedors, equipes de apoio, Gestão de Fornecedores, Equipes de desenvolvimento e e de aplicações)?

Gerente de Projeto

Tem apropriado e técnico documentação foi apresentada e aceita por incidentes, problemas e todas as equipes de e de TI?

Problema incidente,

Ter todos os RFCs e Registro de Lançamentos foi autorizado e atualizado?

Mudar

Ter todos os serviços, SLA, SLR, OLA e detalhes do contrato, juntamente com toda a aplicaçãos infra-estrutura e componente detalhes, sido inscrita na CMS?

Gerenciamento de Projetos, Configuração de equipes de e

Já apropriadas S / W licenças foram compradas ou realocados licenças usado?

Configuração

Algum novos H / W componentes foi armazenado no DL com detalhes gravados na CMS?

Configuração

Ter todos os novos S / W componentes foi apresentado no DL com detalhes gravados na CMS?

Configuração

Ter todos os planos de manutenção e atualização foi acordado, juntamente com liberar políticas, freqüências e mecanismos?

Liberação e Implantação

Ter todos os usuários foram treinados, e tem usuário documentação foi aceita e fornecido para todos os usuários?

Gerente de Projeto

São todos relaçãos, interfaces e dependências com todos os outros sistemas internos e externos e serviços documentado, concordou e apoiou?

Gerente de Projeto

Já os gerentes de negócio apropriados assinado aceitação do novo serviço?

Gerente de Projeto

Tabela B.1 critérios de aceitação de serviço

ITIL V3 - Service Design - Página:

394 de 477

Anexo C: modelos de processo de documentação (exemplo) C1 Process Framework Ao projetar uma nova ou revista processo para qualquer um dos Serviço de Gestão de processos, recomenda-se que um processo de especificação ou quadro ser produzido. A especificação deve ser mantida a um nível bastante elevado, mas precisa de detalhe do escopo e interfaces do processo. Mais detalhada e procedimentos instrução de trabalhos também serão necessários para garantir a consistência do processo e sua aplicação. Os conteúdos típicos de uma estrutura de processo ou especificação são: • • • • •

•

• •

• •

•

Nome do processo, descrição e istração (istração documentação: versão, Controle de alterações, autor, etc) Visão e declarações de missão Objetivos Escopo e termos de referência Visão geral do processo: o Descrição e panorâmica o Entradas o Procedimentos o Atividades o Saídas o Desencadeia o Ferramentas e outros entregas o Comunicação Papels e responsabilidades: o Operacional responsabilidades o Proprietário do processo o Membros de processo o Processo usuários o Outros papéis Documentação associada e referências Interfaces e dependências para: o Outros processos de SM o Outros processos de TI o Processo de negócioes Medições do processo e métricos: comentários, avaliaçãos e auditars Entregas e relatórios produzidos pelo processo: o Freqüência o Conteúdo o Distribuição Glossário, siglas e referências.

ITIL V3 - Service Design - Página:

395 de 477

Anexo D: Design e Planejamento documentos e seus conteúdos Este anexo contém detalhes sugeridos dos tipos de documentos de design, planos e documentos padrões que devem ser produzidos e mantidos por ela, e também descreve os conteúdos mínimos de arquiteturas de TI e planos. No entanto, deve-se ressaltar mais uma vez que todos estes documentos devem ser frequente e regularmente revisto e revisado e deve ser usada ativamente dentro de processos de TI e diárias procedimentos. Têm também de ser mantida em alinhamento com todos os documentos semelhantes em uso no interior da negócio e o conjunto organização.

ITIL V3 - Service Design - Página:

396 de 477

D1 Design e documentos de arquitetura e padrões Os documentos de projeto e padrões desenvolvidos e mantidos pela TI deve incluir: • • • • • •

• •

•

• • • • • • • • • • • • • • •

Design e planejamento normas, políticas, processos e procedimentos Arquiteturas de aplicações, métodos e padrões de projeto Requisitos de negócios, avaliação de impacto nos negócios e priorização e caso de negócio métodos e normas Funcionais padrões requisitos Sor e padrões da ITT e os métodos para a sua avaliação Arquiteturas de TI de tecnologia, padrões de projeto e políticas, que abrangem todas as áreas de tecnologia, incluindo mainframe, servidor, Desktop, laptop, aparelhos portáteis e móveis, sistemas de telefonia, armazenamento, apoio, Rede e endereçamento de rede Sistemas operacionais, software de sistemas, serviços públicos e de firmware arquiteturas, projeto de políticas e normas Dados, informações e banco de dados arquiteturas, políticas e padrões de projeto, incluindo os fluxos de informação, Gestão do Conhecimento, Informações segurança e de o, gerenciamento de dados, armazenamento de dados, armazenamento de dados, análise de dados e mineração de dados Sistema de gestãos, plataformas, ferramentas e agentes e suas arquiteturas e políticas e padrões de projeto, incluindo a funcionalidade, domínios, interfaces, protocolos de gestão, evento e tratamento de alarmes e automação, categorização e escalada Cabeamento arquiteturas, desenhos e padrões Desenvolvimento de padrões, métodos e políticas Métodos de ensaio, políticas e padrões Entrega, aceitação e sign-off normas e métodos Partners, fornecedor e as normas contratuais e políticas Políticas de comunicação e padrões Documento e documento padrões de biblioteca e políticas Internet e intranet arquiteturas, padrões de projeto e políticas, incluindo e-commerce e e-business E-mail e groupware arquiteturas, padrões de projeto e políticas Exigências ambientais, políticas e padrões de projeto TI segurança políticas e padrões de projeto, incluindo walling incêndio, verificação de vírus, serviço e níveis de o ao sistema, métodos e políticas, o remoto, usuário conta e gerenciamento de senhas Normas de contratação e políticas Programa normas e políticas, métodos de projeto e projeto planejamento e avaliação de políticas e normas Qualidade normas e políticas Usuário interfaces e padrões.

ITIL V3 - Service Design - Página:

397 de 477

D2 planos de TI TI deve produzir e manter uma série de planos, a fim de coordenar e gerir a geral desenvolvimento e qualidade dos De serviços de TIs. Estes devem incluir: • • • • • • •

•

•

Planos de negócios de TI: Os planos de negócios para o desenvolvimento de serviços de TI Estratégico planos: Fornecer planos para a realização do longo prazo visão, Missão e objetivos de TI Tático planos: Fornecer planos para a realização do curto e médio prazo, a visão, missão e objectivos das TIC Planos funcionais: Fornecer planos para a realização da missão, visão e objetivos das principais funções de TI Planos operacionais: Fornecimento de planos para o desenvolvimento e aperfeiçoamento de operacional processos, procedimentos e métodos Planos de projetos e programas: o TI e negócios programas o Projetos de TI Processos de planos e programas: o Objetivos e metas o Melhoria de processos o Papels e responsabilidades Transição planos: o Construir planos e horários o Testes e liberar horários o Ambientes de desenvolvimento e teste o Transição horários Serviço de Gestão de planos: o Plano de Qualidade de Serviço (s) o Planos de Melhoria de serviços e programas o Planos Financeiros e orçamentos o Continuidade do Serviço de TI e Planos de Recuperação e Planos de Continuidade de Negócios o Plano de capacidade o Plano de disponibilidade o Planos de Serviço de Apoio o Planos de Lançamento e horários o Os planos de gestão de configuração o Alterar planos de gestão e os Alterar agendamento o Service Desk, Gerenciamento de Incidentes e Gerenciamento de Problemas Planos o Fornecedor e planos de contrato.

Todos planos de TI deve ser desenvolvido, mantido e revisto em linha dentro da negócio e o conjunto organização. Isso deve ser feito usando o estudo de impacto processo de um sistema adequado Gestão da Mudança. As ITIL V3 - Service Design - Página:

398 de 477

organizações devem tomar os requisitos legais para sistemas em consideração e também olhar para as normas internacionais e nacionais de regulação ea necessidade de corporativo governo.

ITIL V3 - Service Design - Página:

399 de 477

Apêndice E: arquiteturas e padrões ambientais Este anexo contém detalhes de arquiteturas e padrões ambientais. Toda organização deve produzir um ambiente política para a localização de equipamentos, com o mínimo de normas acordadas para as concentrações particulares de equipamentos. Além disso, os padrões mínimos devem ser acordados para a protecção de edifícios que contêm equipamentos e conchas sala de equipamentos. As tabelas que se seguem cobrem os principais aspectos que precisam ser considerados, com características de exemplo.

Edifício tabela E.1 / site o

Perímetros de segurança, entradas seguras, pista de auditoria

Construção e proteção de site

Segurança cercas, câmeras de vídeo, movimento e detectores de intrusão portas e janelas, alarmes, protetores de raios, bom ambiente de trabalho (padrão)

Entrada

Múltiplos pontos controlados de entrada

Ambiente externo

Minimizar riscos externos

Serviços

Sempre que possível e justificável, rotas alternativas e fornecedors para todos os serviços essenciais, incluindo serviços de rede

Tabela E.2 quarto equipamento principal o

Entrada controlado e seguro, combinação, cartão magnético, câmera de vídeo (se o negócio crítica e autônoma)

Localização

Primeiro andar, sempre que possível, sem riscos de água, gás, químicos, ou de fogo nas imediações, acima, abaixo ou ao lado

Visibilidade

Sem sinalização, sem janelas externas

Concha

Casca externa: impermeável, hermético, à prova de som, resistente ao fogo (0,5 horas a 4 horas, dependendo da criticidade)

Entrega de equipamentos

Pró adequadavisão deve ser feito para a entrega e posicionamento dos equipamentos delicados grande

Piso interno

Selado

Sala de planta separado

Uninterruptible Power Supply (UPS). Alimentação eléctrica e de comutação, unidades de tratamento de ar, duas unidades e quartos se o negócio crítico

Externo

Gerador para grandes centros de dados e sistemas críticos de negócio

ITIL V3 - Service Design - Página:

400 de 477

Tabela E.3 grandes centros de dados o

Entrada controlado e seguro, combinação, cartão magnético, câmera de vídeo (se o negócio crítica e autônoma)

Temperatura

Controle rigoroso, 22 ° (± 3 °). Fornecer para até 550W/m2. 6 ° variação ao longo do quarto e um máximo de 6 graus por hora

Controle de umidade

Rigoroso controle: 50% (± 10%)

A qualidade do ar

Pressão positiva, filtrada ingestão de poluição gasosa baixo (por exemplo, o dióxido de enxofre 0,14 ppm), os níveis de pó de partículas de 1 micron>, menos do que 5 x 106 particles/m3. Desactivação automática de fumaça ou de detecção de incêndio

Poder

Unidade de Distribuição de Energia (PDU), com a oferta de três fases para não-switched caixas, uma por parte de equipamento, com as devidas classificados disjuntores para cada oferta. Em alternativa, as tiras de distribuição aprovados potência pode ser utilizada. Equilibradas cargas trifásicas. UPS (online ou linha interativa com Simple Network Management Protocol (SNMP) Management) para garantir a tensão fornecida é de ± 5% da classificação com o impulso mínimo, quedas, picos e mais / sob condições de tensão

Pisos falsos

Antiestática, ladrilhos elevável 600 x 600 milímetros em pedestais, com pedestais alternativas aparafusado ao chão sólido. Mínimo de folga 600 milímetros para o chão sólido. Cargas no chão de até 5kN/m2 com um mínimo recomendado de 3 m entre o piso eo teto falso

Paredes internas

Do chão ao teto falso, resistente ao fogo, mas com o fluxo de ar acima e abaixo do nível do chão

Detecção de incêndio / prevenção

HSSD ou VESDA alarme multi-nível com auto FM200 (ou substituição halon alternativa) a liberação de 'duplo-knock "detecção

Detectores ambientais

Para fumaça, temperatura, potência, umidade, água e intrusão com alarme automático capacidade. Locais painéis de alarme com painéis repetidores e capacidade de alarme também remoto

Iluminação

Normal níveis de iluminação de teto com iluminação de emergência em caso de falha de energia

Segurança da energia

Terra limpa deve ser fornecido no PDU e para todos os equipamentos. Com claramente marcado remotas de desligamento botões em cada saída. Tomadas de energia suja, claramente marcado, também deve ser fornecido

Extintores de incêndio

Elétrica suficiente extintores com sinalização adequada e procedimentos

Vibração

Vibrações deve ser mínima dentro da área completa

ITIL V3 - Service Design - Página:

401 de 477

Interferência eletromagnética

Interferência mínima deve estar presente (1,5 V / m de intensidade de campo ambiente)

Instalações

Todos os equipamentos devem ser fornecidos e instalados por pessoal qualificado fornecedors e instaladores apropriados para padrões elétricos e de saúde e segurança

As conexões de rede

O espaço de equipamento deve ser ligado com inundações adequada capacidade para crescimento razoável. Todos os cabos devem ser colocados e fixados a es de cabos adequados

Desastre recuperação

Planos de recuperação totalmente testados devem ser desenvolvidos para todos os centros de dados importantes, incluindo o uso de sites de standby e equipamentos

Tabela E.4 centros de dados regionais e centros de equipamento principal o

Entrada controlado e seguro, combinação, cartão magnético, câmera de vídeo (se o negócio crítica e autônoma)

Temperatura

O controlo da temperatura, 22 ° (± 5 °), preferível

Controle de umidade

Rigoroso controle: 50% (± 10%), de preferência

A qualidade do ar

Pressão positiva, filtrada ingestão de poluição gasosa baixo (por exemplo, o dióxido de enxofre 0,14 ppm), os níveis de pó de partículas de 1 micron>, menos do que 5 x 106 particles/m3. Desactivação automática de fumaça ou de detecção de incêndio

Poder

PDU com alimentação trifásica não-switched caixas, uma por parte de equipamento, com as devidas classificados disjuntores para cada oferta. Em alternativa, as tiras de distribuição aprovados potência pode ser utilizada. Equilibradas cargas trifásicas. Sala de UPS para garantir a tensão fornecida é de ± 5% da classificação com o impulso mínimo, quedas, picos e mais / sob condições de tensão

Pisos falsos

Antiestática, ladrilhos elevável 600 x 600 milímetros em pedestais, com pedestais alternativas aparafusado ao chão sólido. Mínimo de folga 600 milímetros para o chão sólido. Cargas no chão de até 5kN/m2 com um mínimo recomendado de 3 m entre o piso eo teto falso

Paredes internas

Do chão ao teto falso, resistente ao fogo, mas com o fluxo de ar acima e abaixo do nível do chão

Detecção de incêndio / prevenção

Geralmente detecção de incêndio, mas não a supressão, embora HSSD ou VESDA alarme multi-nível com auto FM200 (ou substituição halon alternativa) a liberação de 'duplo-knock' detecção pode ser incluído se sistemas críticos de negócio estão contidas

Detectores ambientais

Para fumaça, temperatura, potência, umidade, água e intruso com capacidade de alarme automático

Iluminação

Normal níveis de iluminação de teto com iluminação de emergência em

ITIL V3 - Service Design - Página:

402 de 477

caso de falha de energia Segurança da energia

Terra limpa deve ser fornecido no PDU e para todos os equipamentos. Com claramente marcado remotas de desligamento botões em cada saída. Tomadas de energia suja, claramente marcado, também deve ser fornecido

Extintores de incêndio

Elétrica suficiente extintores com sinalização adequada e procedimentos

Vibração

Vibrações deve ser mínima dentro da área completa

Interferência eletromagnética

Interferência mínima deve estar presente (1,5 V / m de intensidade de campo ambiente)

Instalações

Todos os equipamentos devem ser fornecidos e instalados por pessoal qualificado fornecedors e instaladores apropriados para padrões elétricos e de saúde e segurança

As conexões de rede

O espaço de equipamento deve ser cheias com fio com capacidade adequada para um crescimento razoável. Todos os cabos devem ser colocados e fixados a es de cabos adequados

A recuperação de desastres

Planos de recuperação totalmente testados devem ser desenvolvidos para todos os centros de dados regionais, incluindo o uso de sites de stand-by e equipamentos sempre que necessário

Servidor Tabela E.5 ou salas de equipamentos de rede o

Entrada controlado e seguro, pelo fechamento de combinação, cartão magnético ou chave e fechadura. Em alguns casos, o equipamento pode ser contido em escritórios abertos em prateleiras ou armários fechados

Temperatura

Ambiente de escritório normal, mas se em quartos fechados / bloqueado ventilação adequada deve ser fornecida

Controle de umidade

Ambiente de escritório normal

A qualidade do ar

Ambiente de escritório normal

Poder

Fonte de energia limpa, com uma potência fornecida pela UPS para o rack completo

Pisos falsos

Mínimo recomendado de 3 m entre o piso eo teto com todos os cabos fixados no compartimento multi-trunking

Paredes internas

Sempre que possível todas as paredes devem ser resistentes ao fogo

Detecção de incêndio / prevenção

Normais de escritório de fumaça / incêndio sistemas de detecção, a menos que grandes concentrações de equipamentos

Detectores ambientais

Para o fumo, o poder intruso, com capacidade de alarme sonoro

Iluminação

Normal níveis de iluminação de teto com iluminação de emergência em caso de falha de energia

ITIL V3 - Service Design - Página:

403 de 477

Segurança da energia

Terra limpa devem ser fornecidos para todos os equipamentos. Com claramente marcadas poder-off botões

Extintores de incêndio

Elétrica suficiente extintores com sinalização adequada e procedimentos

Vibração

Vibrações deve ser mínima dentro da área completa

Interferência eletromagnética

Interferência mínima deve estar presente (1,5 V / m de intensidade de campo ambiente)

Instalações

Todos os equipamentos devem ser fornecidos e instalados por pessoal qualificado fornecedors e instaladores apropriados para padrões elétricos e de saúde e segurança

As conexões de rede

O espaço de equipamento deve ser ligado com inundações adequada capacidade para crescimento razoável. Todos os cabos devem ser colocados e fixados a es de cabos adequados

A recuperação de desastres

Planos de recuperação totalmente testados deve ser desenvolvida se for o caso

Tabela E.6 ambientes de escritório o

Todos os escritórios devem ter o o adequado seguro dependendo do negócio, a informação e os equipamentos neles contidas

Qualidade de iluminação, temperatura, umidade e ar

Um ambiente de escritório normal limpo, confortável e bem organizado, em conformidade com os requisitos da organização de saúde, segurança e meio ambiente

Poder

Fonte de energia limpa para todos os equipamentos de informática, com instalações UPS se for o caso

Pisos falsos

Preferido, se possível, mas todos os cabos devem estar contidos dentro de trunking apropriado

Detecção de incêndio / prevenção e extintores

Normais de escritório sistemas de fumaça / incêndio de detecção de intrusão e sistemas de alerta, a menos que haja grandes concentrações de equipamento. Suficientes extintores de incêndio do tipo apropriado, com sinalização adequada e procedimentos

As conexões de rede

O espaço de escritório deve ser preferencialmente inundações fios com capacidade adequada para um crescimento razoável. Todos os cabos devem ser colocados e fixados a es de cabos apropriados. Todos os equipamentos de rede deve ser fixada em armários ou gabinetes seguras

Desastre recuperação

Planos de recuperação totalmente testados deve ser desenvolvida se for o caso

ITIL V3 - Service Design - Página:

404 de 477

Apêndice F: Amostra SLA e OLA Este anexo contém exemplos de SLAs e OLAs e seus conteúdos. Não é recomendável que todo SLA ou OLA deve necessariamente conter todas as seções listadas nos documentos de exemplo a seguir. Sugere-se que estas áreas são considerados na preparação documento modelos, mas que eles só estão incorporados nos documentos reais próprios onde eles são apropriados e relevantes. Assim, as linhas a seguir devem ser considerados apenas como diretrizs ou listas de verificação.

Acordo de nível (SLA - Amostra) Este acordo é feito entre ............................................. .................... e .................................................. ........................ O acordo abrange o próvisão e apoio dos serviços do ABC, que ..... (Breve serviço descrição). Este acordo é válido por 12 meses a partir da (data) até (data). O acordo será revisto anualmente. Pequenas mudanças podem ser registrados no formulário, no final do contrato, desde que sejam mutuamente aprovado pelos dois partidos e gerida através do Gestão da Mudança processo. Signatários:

Descrição do serviço: O Serviço de ABC consiste .... (Uma descrição mais completa para incluir funções de negócio, entregas e todas as informações relevantes para descrever o serviço e sua escala, impacto e prioridade para a negócio).

Âmbito do acordo: O que é coberto no contrato e que está excluído?

ITIL V3 - Service Design - Página:

405 de 477

Horas de serviço: Uma descrição das horas que o clientes pode esperar que o serviço esteja disponível (por exemplo, 7 × 24 × 365, das 08:00 às 18:00 - de segunda a sextafeira). Condições especiais para exceções (por exemplo, fins de semana, feriados) e procedimentos para solicitar extensões de serviço (que para entrar em contato normalmente o Serviço de Recepção - e que períodos de aviso prévio são necessários). Isto pode incluir um calendário de serviço ou referência a um calendário serviço. Detalhes de qualquer slots pré-acordados de manutenção ou limpeza, se estes impacto sobre as horas de serviço, juntamente com detalhes de como as interrupções de outros potenciais devem ser negociadas e acordadas - por quem e períodos de aviso prévio etc Procedimentos para solicitar alterações permanentes horas de serviço.

Disponibilidade do serviço: O alvo disponibilidade níveis que o Provedor de serviços de TI vai procurar para entregar dentro do horário de serviço acordados. Metas de disponibilidade dentro de horas de serviço acordados, normalmente expressa em percentagem (por exemplo, 99,5%), os períodos de medição, método e cálculos devem ser estipuladas. Este valor pode ser expresso para o geral serviço, Serviços que sustentam e críticas componentes ou todos os três. No entanto, é difícil relacionar essas figuras disponibilidade simplistas percentuais de serviço qualidade, Ou para atividades de negócios dos clientes. É, portanto, muitas vezes melhor do que tentar medir indisponibilidade do serviço em termos de incapacidade do cliente para realizar suas atividades de negócios. Por exemplo, "as vendas são imediatamente afetados por uma falha de TI para fornecer um serviço de apoio adequado POS '. Esta forte ligação entre o De serviços de TI e do cliente processo de negócioes é um sinal de maturidade em ambos SLM eo Gerenciamento de Disponibilidade processos. Detalhes acordados de como e em que ponto isso vai ser medido e indicado, e sobre o que concordou período também deve ser documentada.

Confiabilidade: O número máximo de quebras de serviço que podem ser tolerados dentro de um certo período (pode ser definido como o número de intervalos, por exemplo, quatro por ano, ou como um Tempo médio entre falhas (MTBF) ou Tempo Médio Entre Incidentes Sistemas (TMEIS)).

ITIL V3 - Service Design - Página:

406 de 477

Definição do que constitui um 'break' e como estes serão monitoradas e registradas.

Atendimento ao cliente: Detalhes de como entrar em contato com a Central de Serviço, as horas que vai estar disponível, o apoio está disponível e horas o que fazer fora do horário de obter assistência (por exemplo, chamada de apoio, assistência de terceiros, etc) devem ser documentados. O SLA também podem incluir referência a Internet / Intranet Auto-ajuda e / ou registro de incidentes. Métricos e medidas devem ser incluídos, tais como metas de telefone de chamada de resposta (número de toques, chamadas não atendidas, etc) Metas para Incidente tempos de resposta (quanto tempo será antes que alguém começa a atender o cliente - pode incluir o tempo de viagem, etc) A definição é necessária de "resposta" - É uma chamada telefônica de volta para a cliente ou uma visita ao local? - Se for caso disso. Arranjos para solicitar extensões de apoio, incluindo os períodos de aviso prévio (pedido por exemplo, deve ser feito para a Central de Serviço 12 horas para uma extensão da noite, até às 12 horas de quinta-feira para uma extensão final de semana) Nota. Tanto a resposta de incidentes e resolução vezes será baseado em qualquer impacto incidente /prioridade códigos são usados - detalhes da classificação de Incidentes também devem ser incluídos aqui. Nota. Em alguns casos, pode ser apropriado para fazer referência para terceiros os e contratos e OLAs - mas não como uma forma de desviar a responsabilidade.

Pontos de o e de escalação: Detalhes dos contatos dentro de cada uma das partes envolvidas no acordo e que a escalada processoes e pontos de o. Isto também deve incluir a definição de uma denúncia e procedimento para o gerenciamento de reclamações.

Desempenho do serviço: Detalhes da esperada capacidade de resposta da estação de trabalho IT alvo de serviço (por exemplo, tempo de respostas para a média, ou o tempo de resposta máximo de estações de trabalho, às vezes expressas como um percentual - por exemplo, 95% dentro de dois segundos), detalhes do serviço esperado

ITIL V3 - Service Design - Página:

407 de 477

rendimento em que as metas são baseadas, e qualquer limiars que possam invalidar as metas). Isto deve incluir a indicação dos volumes de tráfego prováveis, a atividade de transferência, restrições e dependências (por exemplo, o número de transaçãos para serem processados, número de concorrente usuários, e quantidade de dados a serem transmitidos através da rede). Isto é importante de modo a que atuação questões que foram causados pela excessiva rendimento fora dos termos do acordo podem ser identificados.

Turnaround vezes lote: Se necessário, a indicação de qualquer lote tempos de resposta, tempo de conclusão e chave entregas, incluindo os tempos de entrega de entrada e horário e local para a entrega do produto se for o caso.

Funcionalidade (se for o caso): Detalhes da funcionalidade mínima a ser fornecido e do número de erros de tipos específicos que podem ser tolerados antes da SLA é violada. Deverá incluir os níveis de severidade e período de referência.

Gestão da Mudança: Breve menção e / ou referência para a organização do Gestão da Mudança procedimentos que devem ser seguidas - apenas para reforçar observância. Também tem como alvo para a aprovação, a manipulação e aplicação de RFCs, geralmente com base no categoria ou urgência/ Prioridade do alterar, também devem ser incluídos e os detalhes de todas as alterações conhecidas que terão impacto sobre o acordo, se houver.

Continuidade de serviço: Breve menção e / ou referência para os planos da organização de continuidade de serviço, juntamente com detalhes de como o SLA pode ser afetado ou referência a um SLA Continuidade separado, contendo detalhes de quaisquer metas de diminuição ou alteração deve ocorrer uma situação de desastre. Detalhes de quaisquer responsabilidades específicas de ambos os lados (por exemplo, dados apoio, Fora do local de armazenamento). Também detalhes da invocação de planos e cobertura de todos segurança questões, particularmente as responsabilidades do cliente (por exemplo, a coordenação de atividades de negócios, documentação de negócios, backup de PCs independentes, alterações de senha).

ITIL V3 - Service Design - Página:

408 de 477

Segurança: Uma breve referência e / ou de referência para o organização'S Política de Segurança (Abrangendo questões como controles de senha, segurança violações, de software não autorizado, vírus etc.) Pormenores de quaisquer responsabilidades específicas de ambos os lados (por exemplo, proteção contra vírus, firewalls).

Impressão: Pormenores de quaisquer condições especiais de impressão ou impressoras (por exemplo, imprimir detalhes de distribuição, a notificação de grandes tiragens centralizados, ou manipulação de qualquer papelaria de alto valor especial).

Responsabilidades: Detalhes das responsabilidades das partes envolvidas no âmbito do serviço e suas responsabilidades acordadas, incluindo a provedor de serviços, O cliente e o usuários.

Carregamento (se aplicável): Detalhes de quaisquer carregamento fórmulas utilizadas, cobrando períodos, ou de referência para cobrança política documentos, junto com a facturação procedimentos e as condições de pagamento, etc devem ser incluídos. Isto também deve incluir detalhes de quaisquer sanções financeiras ou bônus que serão pagos se as metas de serviço não atender às expectativas. Quais serão as penalidades / bônus ser e como serão calculados, concordou e recolhidos / pago (mais apropriado para terceiros situações). Se o SLA abrange uma terceirização relação, As taxas devem ser detalhados em um apêndice, como são frequentemente cobertos por comerciais em-confiança disposições. Note-se que as cláusulas de penalização podem criar suas próprias dificuldades. Eles podem constituir um obstáculo para parcerias se injustamente invocado por um detalhe técnico e também pode fazer provedor de serviços funcionários dispostos a itir erros, por medo de sanções sendo impostas. Isso pode, a menos que usado corretamente, ser uma barreira para o desenvolvimento de relações eficazes e de resolução de problemas.

Serviço de relatórios e analisar: O conteúdo, freqüência, conteúdo, o calendário e distribuição de relatórios de serviços, ea frequência de reuniões de avaliação associados serviços. Também

ITIL V3 - Service Design - Página:

409 de 477

detalhes de como e quando os SLAs e as metas de associados será analisada e possivelmente revistas, incluindo quem estará envolvido e em que capacidade.

Glossário: Explicação de eventuais abreviações inevitáveis ou terminologia utilizada, para auxiliar a compreensão do cliente.

Folha de alteração: Para incluir um registro de todas as alterações acordadas, com detalhes de emendas, as datas e os signatários. Também deve conter detalhes de uma completa mudar a história do documento e sua revisãos. Deve notar-se que o SLA conteúdo dadas acima são apenas exemplos. Eles não devem ser consideradas exaustivas ou obrigatória, mas eles fornecem um bom ponto de partida.

Acordo de Nível Operacional (ANO - Amostra) Este acordo é feito entre ............................................. .................... e .................................................. ....................... O acordo abrange o próvisão do serviço de e proporcionando ..... (Descrição breve serviço). Este acordo é válido por 12 meses a partir da (data) até (data). O acordo será revisto anualmente. Pequenas mudanças podem ser registrados no formulário, no final do contrato, desde que sejam mutuamente aprovado pelos dois partidos e gerida através do Gestão da Mudança processo. Signatários:

Detalhes de alterações anteriores: e Descrição do serviço: Explicação completa e detalhes do apoio serviço sendo prestado.

ITIL V3 - Service Design - Página:

410 de 477

Âmbito do acordo: O que é coberto no contrato e que está excluído?

Horas de serviço: Uma descrição das horas para que o serviço seja prestado apoio.

Metas de serviço: Os objectivos para o provisão do serviço de e e prestação de informações e revisão processoes e frequência.

Pontos de o e de escalação: Detalhes dos contatos dentro de cada uma das partes envolvidas no acordo e que a escalada processos e pontos de contato.

Posto de serviço e tempos de resposta a incidentes e responsabilidades: As responsabilidades e as metas acordadas para o progresso e resolução de incidentes e de apoio do Service Desk.

Problema tempos de resposta e responsabilidades: As responsabilidades e as metas acordadas para o progresso e resolução de problemas.

Gestão da Mudança: As responsabilidades e as metas acordadas para o progresso e implementação de mudars.

Gerenciamento de lançamento: As responsabilidades e as metas acordadas para o progresso e implementação de lançamentos.

Gerenciamento de Configuração: As responsabilidades para a propriedade, provisão e manutenção de informações precisas Gerenciamento da Configuração informação.

ITIL V3 - Service Design - Página:

411 de 477

Gestão de Segurança da Informação: As responsabilidades e as metas acordadas para o apoio da Política de Segurança(S) e o Gestão de Segurança da Informação processo.

Gerenciamento de Disponibilidade: A responsabilidade por garantir que todos os componentes dentro do seu domínio de apoio são dirigidos e apoiados para atender e continuar a atender todos os serviços e metas de disponibilidade de componentes.

Gestão da Continuidade de serviço: A responsabilidade por garantir que todos os componentes dentro de seu domínio de apoio têm up-to-date e testado recuperação planos que am os requisitos de negócios acordados e documentados. Isto deve incluir a assistência com o técnico avaliação de risco e sua posterior gestão e mitigação.

Gerenciamento da Capacidade: Responsabilidade para ar as necessidades da Gerenciamento da Capacidade processo dentro do escopo acordado de seu domínio técnico.

Gerenciamento de Nível de Serviço: Assistência com a definição e acordo de metas adequadas dentro de SLAs, SLRs e Olas, sobre os componentes dentro da escopo do seu domínio técnico.

Gestão de Fornecedores: Assistência com a gestão de contratos e fornecedors, uma vez mais, principalmente no âmbito do seu domínio técnico.

Próvisão de informações: O próvisão e manutenção de informações precisas, incluindo dados financeiros para todos os componentes dentro do escopo acordado de seu domínio técnico.

Glossário: Explicação de eventuais abreviações inevitáveis ou terminologia utilizada, para auxiliar a compreensão dos termos contidos no acordo.

ITIL V3 - Service Design - Página:

412 de 477

Folha de alteração: Para incluir um registro de todas as alterações acordadas, com detalhes de emendas, as datas e os signatários. Também deve conter detalhes de uma completa mudar a história do documento e sua revisãos.

ITIL V3 - Service Design - Página:

413 de 477

Anexo G: Catálogo de Serviço Exemplo O Catálogo de Serviços é documento-chave que contém informações valiosas sobre o conjunto completo de serviços oferecidos. Ele deve preferencialmente ser armazenados como um conjunto de "serviço" CIs dentro de um CMS, mantida sob Gestão da Mudança. Como se trata de um conjunto tão valiosa de informação deve estar disponível a qualquer um dentro da organização. Cada novo serviço deve ser imediatamente entrou no Catálogo de Serviços uma vez que sua definição inicial dos requisitos foi documentado e acordado. Assim, bem como os dados abaixo, a Catálogo de Serviços deve registrar o estado de cada serviço, através dos estágios de seu ciclo de vida definido.

No me do serv iço

Des criçã o de Serv iço

Tip o de ser viç o

Ser viço s de apoi o

Propr ietári o da empr esa (s)

Unid ade de Neg ócio s (s)

Ser vice Man age r (s)

Imp acto nos Neg ócio s

Ser viç o1 Ser viç o2 Ser viç o3 Ser viç o4

Tabela G.1 Catálogo de Serviço Exemplo

ITIL V3 - Service Design - Página:

414 de 477

Prior idad e de negó cios

S L A

Ho ras de ser viç o

Cont atos Com erciai s

Esca lada Cont acto s

Rela tório s de servi ços

Come ntário s de serviç os

Segur ança Classi ficaçã o

Anexo H: O Serviço de Gerenciamento quadro maturidade do processo A estrutura de maturidade de processo (PMF) pode ser usado tanto como um quadro para avaliar a maturidade de cada um dos processos de gerenciamento de serviços, individualmente, ou para medir a maturidade da Serviço de Gestão de processo como um todo. Esta é uma abordagem que tem sido largamente utilizado na indústria de TI de um certo número de anos, com muitos proprietários modelos a ser usado por um certo número de organizaçãos. Este PMF especial foi desenvolvida para trazer uma abordagem comum e melhores práticas para a revisão e avaliação Serviço de maturidade do processo de Gestão. Esse quadro, que é mostrado na Figura H.1, pode ser utilizado pelas organizações para avaliar internamente seus processos de gestão de serviços próprios, bem como de terceiros organizações trazidos como revisores externos, avaliadores ou auditores.

Figura H.1 estrutura de maturidade de processo

O uso do FPP na avaliação de Serviço de Gestão de processos depende de uma apreciação do modelo de TI Organização Crescimento. A maturidade dos processos de gestão de serviços é fortemente dependente da fase de crescimento da organização de TI como um todo. É difícil, se não impossível, para desenvolver a maturidade dos processos de gerenciamento de serviços para além da maturidade e capacidade da organização de TI em geral. A

ITIL V3 - Service Design - Página:

415 de 477

maturidade da organização de TI não é apenas dependente da maturidade dos processos de gerenciamento de serviços. Cada nível requer uma mudança de uma combinação de elementos, a fim de ser completamente eficazes. Por conseguinte, uma rever de processos exige uma avaliação para ser concluída contra as cinco áreas de: • • • • •

Visão e direção Processo Pessoas Tecnologia Cultura.

Estas são as cinco áreas descritas no PMF para avaliar a maturidade do processo. As características principais de cada nível do FPP são como se segue.

ITIL V3 - Service Design - Página:

416 de 477

Inicial (Nível 1) O processo foi reconhecida, mas não há actividade de gestão pouco ou nenhum processo e é atribuído nenhuma importância, recursos ou foco dentro da organização. Este nível também pode ser descrito como "ad hoc" ou ocasionalmente até mesmo 'caótico'. Visão e direção

Fundos mínimos e recursos, com pouca atividade Resultados não temporária, mantida Relatos esporádicos e comentários

Processo

Processos vagamente definidas e procedimentos, usado de forma reativa, quando ocorrem problemas Processos totalmente reativas Irregulares, atividades não planejadas

Pessoas

Vagamente definido papels ou responsabilidades

Tecnologia

Processos manuais ou alguns específicos, ferramentas discretas (bolsas / ilhas)

Cultura

Ferramenta e de base tecnológica e conduzido com um foco forte atividade

Nível Tabela H.1 PMF 1: inicial

ITIL V3 - Service Design - Página:

417 de 477

Repetitivo (Nível 2) O processo tem sido reconhecido e é atribuído pouca importância dos recursos, ou o foco dentro da operação. Geralmente as atividades relacionadas ao processo são descoordenados, irregular, sem direção e estão orientados para processo eficácia. Visão e direção

Claro não objetivos ou metas formais Fundos e recursos disponíveis Irregular, não planejada actividades, relatórios e opiniões

Processo

Processos e procedimentos definidos Processo em grande parte reativa Irregulares, atividades não planejadas

Pessoas

Independente papels e responsabilidades

Tecnologia

Muitas ferramentas discretas, mas a falta de controle Os dados armazenados em locais separados

Cultura

Produtos e serviços de base e conduzido

Nível Tabela H.2 PMF 2: repetível

ITIL V3 - Service Design - Página:

418 de 477

Definido (Nível 3) O processo foi reconhecido e está documentado, mas não há nenhum acordo formal, aceitação ou o reconhecimento de sua papel dentro da operação de TI como um todo. No entanto, o processo tem um proprietário do processo, Objetivos formais e metas com recursos alocados, e está focada no eficiência , bem como a eficácia do processo. Relatórios e resultados são armazenados para referência futura. Visão e direção

Documentados e acordados objetivos formais e metas Planos publicado formalmente, monitorados e revisados Bem financiado e dotada dos recursos necessários Reporte regular, planejada e opiniões

Processo

Processos claramente definidos e bem divulgadas e procedimentos Regulares, atividades planejadas Boa documentação Ocasionalmente processo proativo

Pessoas

Claramente definidos e acordados papels e responsabilidades Objetivos e metas formais Planos de formação formalizados processos

Tecnologia

Coleta de dados contínua com alarme e limiar monitoramento Dados consolidados retidos e utilizados para formais planejamento, Previsão e tendências

Cultura

Serviço e orientada ao cliente com uma abordagem formal

Tabela H.3 3 Nível PMF: definido

ITIL V3 - Service Design - Página:

419 de 477

Gerenciado (Nível 4) O processo já foi plenamente reconhecido e aceito em todo TI. É o serviço focado e tem objetivos e metas que são baseados em objetivos de negócios e objetivos. O processo está totalmente definido, gerenciado e tornou-se pró-ativa, com documentados, interfaces estabelecidas e dependências com processo de TI outra. Visão e direção

Direção clara, com os objetivos de negócio, objetivos e metas formais, o progresso medido Relatórios de gestão eficazes usados ativamente Planos de processo integradas ligadas ao negócio e planos de TI Melhorias regulares, planejado e revisado

Processo

Processos bem definidos, procedimentos e padrões, incluído em todos os funcionários de TI descrição do trabalhos Claramente definidas as interfaces do processo e dependências Integrado Serviço de Gestão de e sistemas desenvolvimento processos Principalmente proativo processo

Pessoas

Inter e intra equipe de processo de trabalho Responsabilidades claramente definidas em todas as descrições de trabalho de TI

Tecnologia

Medição de monitoramento contínuo e relatórios limiar alertando para um conjunto centralizado de conjuntos de ferramentas integradas, bancos de dados e processos

Cultura

Negócios focada com a compreensão das questões mais amplas

Nível tabela H.4 PMF 4: conseguiu

ITIL V3 - Service Design - Página:

420 de 477

Otimização (Nível 5) O processo foi plenamente reconhecidas e tem estratégico objetivos e metas alinhadas com total estratégico objetivos de negócio e de TI. Estes tornaram-se agora 'institucionalizada' como parte da atividade diária para todos os envolvidos com o processo. Um processo auto-contido contínua de melhoria é estabelecido como parte do processo, que está agora a desenvolver um preventivo capacidade. Visão e direção

Integrado estratégico planos intimamente ligado com os planos gerais de negócios, metas e objetivos A monitorização contínua, medição, relatórios alertando e comentários ligados a um processo contínuo de melhoria Revisões regulares e / ou auditars para eficácia, A eficiência e observância

Processo

Parte processos bem definidos e procedimentos da cultura corporativa Processo pró-ativo e preventivo

Pessoas

Empresas alinhado objetivos e metas formais ativamente monitorado, como parte da atividade diária Funções e responsabilidades parte de uma cultura corporativa global

Tecnologia

Bem documentado ferramenta global arquitetura com integração completa em todas as áreas de pessoas, processos e tecnologia

Cultura

Uma atitude de melhoria contínua, juntamente com um estratégico foco de negócios. A compreensão do valor da TI para o negócio e os seus papel dentro da empresa cadeia de valor

Nível tabela H.5 PMF 5: otimização

Esta estrutura de maturidade está alinhado com o Instituto de Engenharia de Software Capability Maturity Model ® Integration (CMMI SEI) e sua maturidade vários modelos, incluindo a evolução CMMI-SVC, que incide sobre a prestação de serviços.

ITIL V3 - Service Design - Página:

421 de 477

Apêndice I: conteúdo exemplo de uma declaração de Necessidade (SOR) e / ou concurso (ITT) O seguinte é um exemplo de um conjunto mínimo de conteúdo que devem ser incluídos em uma ou ITT SOR: • • • • • • • • • • • • • • • • • •

• • •

A descrição dos serviços, produtos e / ou componentes exigido Todos técnica relevante especificaçãos, detalhes e requisitos Uma SLR quando aplicável Disponibilidade,confiança,manutenção e manutenção requisitos Detalhes de propriedade de hardware, software, edifícios, instalações, etc Detalhes da atuação critérios a serem atendidos pelo equipamento e do fornecedor(S) Detalhes de todas as normas a serem cumpridas (interna, externa, nacional e internacional) Requisitos legais e regulamentares (indústria, nacional, comunitário e internacional) Detalhes de critérios de qualidade Prazos contratuais, detalhes e requisitos, termos e condições Todas as considerações comerciais: custars, acusações, bônus e sanções pecuniárias e horários Interfaces e contatos necessários Métodos de gestão de projetos a serem utilizados Relatório, monitoramento e revisão de procedimentos e critérios a serem utilizados durante e depois da implementação Fornecedor requisitos e condições Sub-contratante requisitos Detalhes de quaisquer termos e condições Descrição do fornecedor requisitos de resposta: o Formato o Critérios o Condições o Prazos o Variaçãos e omissões o Responsabilidades e exigências do cliente Detalhes de crescimento planejado e possível Procedimentos para a manipulação mudars Detalhes do conteúdo e estrutura das respostas necessárias.

ITIL V3 - Service Design - Página:

422 de 477

Anexo J: Os conteúdos típicos de um plano de capacidade Os teores típicos de um Plano de capacidade são como se segue.

1 Introdução Esta seção explica brevemente o pano de fundo desta questão do plano de capacidade, como foi produzido eo que ele contém. Por exemplo: • • • • •

A corrente serviços, tecnologia e recursos O organizaçãoNíveis atuais "s de capacidade Problemas vivenciados ou previstas devido a mais ou a menos de capacidade O grau em que nível de serviços estão a ser alcançados O que mudou desde a última edição do plano.

2 Resumo de Gestão Grande parte do plano de capacidade, por necessidade, contém detalhes técnicos que não é de interesse para todos os leitores do plano. O resumo de gestão deve destacar as principais questões, opções, recomendações e custars. Pode ser necessário para produzir um resumo separado documento que contém os pontos principais de cada uma das seções do plano principal

3 cenários de negócios É necessário colocar o plano em contexto da atual e previsto negócio ambiente. Por exemplo, uma companhia aérea britânica planejado para mover um grande número de funcionários em seu edifício-sede. Um rácio de 1,7 pessoas por terminal desktop foi previsto. Gerenciamento da Capacidade foi alertado e foi capaz de calcular o tráfego de rede extra que seria o resultado. É importante mencionar explicitamente todas as previsões conhecidas de negócios, de modo que os leitores possam determinar o que está dentro eo que está fora do escopo do plano. Ela deve incluir o crescimento previsto nos serviços existentes, os serviços de potenciais novos e serviços existentes programados para o encerramento.

4 Âmbito e termos de referência do plano de

ITIL V3 - Service Design - Página:

423 de 477

Idealmente, o Plano de capacidade deve abranger todos os recursos de TI. Esta seção deve nomear explicitamente os elementos do Infra-estrutura de TI que são incluídos e aqueles que são excluídos, se houver

5 Os métodos utilizados O Plano de Capacidade utiliza informações recolhidas pelos sub-processos. Esta sub-seção, portanto, deve conter detalhes de como e quando esta informação foi obtida - por exemplo, previsões de negócios obtido a partir de planos de negócios, carga de trabalho previsões obtidas a partir de clientes, nível de serviço previsões obtidas pelo uso de modelagem ferramentas

6 suposições feitas É importante que todas as suposições feitas, particularmente as relativas aos drivers de negócio para a TI de Capacidade, são destaque no início do plano. Se eles são os pilares sobre os quais cálculos mais detalhados são construídos, então é vital que todos os interessados entender isso

7 resumo Serviço A seção de resumo de serviço deve incluir: •

•

Pro serviço atual e recentevisão: Para cada serviço que é entregue, fornecer um perfil de serviço. Isto deve incluir rendimento taxas e da utilização de recursos resultante - por exemplo, de memória, espaço de armazenamento, taxas de transferência, o uso do processador e uso de rede. Curto, as tendências de médio e longo prazo devem ser apresentados aqui. Previsões de serviços: Os planos de negócios devem fornecer Gerenciamento da Capacidade com detalhes dos novos serviços planejados e do crescimento ou contração no uso dos serviços existentes. Esta sub-seção deve informar sobre novos serviços ea morte de sistemas legados

ITIL V3 - Service Design - Página:

424 de 477

8 resumo de Recursos A seção de resumo de recursos deve incluir: •

•

O uso de recursos atual e recente: Esta secção sub-concentra-se na utilização de recursos resultantes dos serviços. Ele informa, ainda, sobre as tendências de curto, médio e longo prazo no uso de recursos, discriminadas por plataforma de hardware. Esta informação foi recolhida e analisada pelos sub-processos de Gerenciamento da Capacidade de serviço e Gerenciamento da Capacidade componente e assim devem estar prontamente disponíveis. Previsões de recursos: Esta sub-seção prevê o uso de recursos provavelmente resultante das previsões de serviços. Cada cenário de negócios acima mencionadas devem ser tratadas aqui. Por exemplo, uma empresa de carpete atacado no norte da Inglaterra pode prever com precisão o que o uso do processador de pico e média seria antes que eles decidiram assumir um negócio rival. Ficou provado que uma atualização não seria necessário. Isto foi alimentado para o modelo de custo, levando a uma tomada de controlo bem sucedido

9 Opções para melhoria do serviço Com base nos resultados da seção anterior, esta seção apresenta as opções possíveis para a melhoria da eficácia e eficiência de prestação de serviços. Ele pode conter opções para mesclar diferentes serviços em um único processador, a atualização da rede para aproveitar os avanços tecnológicos, afinação a utilização do recurso ou serviço atuação, Reescrevendo sistemas legados, a compra de novo hardware ou software, etc

10 Custos previstos O custars associados com estas opções devem ser documentadas aqui. Além disso, o custo actual e prevista de fornecimento De serviços de TIs devem ser incluídas. Na prática, Gerenciamento da Capacidade obtém grande parte desta informação a partir da Gestão Financeira processo e do Plano Financeiro de TI.

ITIL V3 - Service Design - Página:

425 de 477

11 Recomendações A seção final do plano deve conter um resumo das recomendações feitas no ano anterior plano e seus estado - Por exemplo, rejeitada, planejada, implementada e qualquer variaçãos a partir do plano. Quaisquer novas recomendações devem ser feitas aqui, ou seja, qual das opções mencionadas no plano é a preferida, e as implicações se o plano e as suas recomendações não são implementados também devem ser incluídos. As recomendações devem ser quantificados em termos de: • • • • •

Benefícios de negócios que podem ser esperados Potencial impacto de levar a cabo as recomendações Riscos envolvidos Recursos exigido Custo, tanto de set-up e em curso.

ITIL V3 - Service Design - Página:

426 de 477

Apêndice K: Os conteúdos típicos de um plano de recuperação Os teores típicos de um plano de recuperação ITSCM são como se segue. PLANO DE RECUPERAÇÃO GENÉRICO 1 CONTROLE DOCUMENTO Este documento deve ser mantida para assegurar que os sistemas de infraestrutura e instalações incluídos, apropriadamente, apoiar as empresas recuperação requisitos. 1,1 Distribuição de documentos Copiar Emitido para Data Posição 1. 2. 3. 4.

1,2 re Documentovisão Este documento será revisto a cada X meses. Revisão atual: data Próxima revisão: data Data de revisão Nenhuma versão Resumo das alterações

ITIL V3 - Service Design - Página:

427 de 477

ITIL V3 - Service Design - Página:

428 de 477

1,3 aprovação de documentos Este documento deve ser aprovada pelo pessoal seguinte: Nome Título

2 INFORMAÇÕES DE APOIO 2.1 Introdução Este documento detalha as instruções e procedimentos que são necessários a serem seguidos para recuperar ou manter a operação de sistemas, infraestrutura, serviços ou instalações para manter a continuidade de serviço para o nível definido ou acordado com o negócio.2.2 A estratégia de recuperação O sistemas,Infra-estrutura,serviços ou instalações serão recuperados alternativa sistemas, Infra-estrutura,serviços ou instalações. Levará cerca de X horas para recuperar o sistemas,Infra-estrutura,serviços ou instalações. O sistema será recuperado para o último ponto conhecido de estabilidade / dados integridade, Que é ponto no dia / momento. O tempo de recuperação necessário para este sistema, Infra-estrutura, serviço ou instalação é: O tempo de recuperação e os procedimentos para este sistema, Infraestrutura,serviço ou facilidade foi testado em último:

ITIL V3 - Service Design - Página:

429 de 477

2,3 Invocação O seguinte pessoal está autorizado a invocar esta plano: 1. 2. 2,4 Interfaces e dependências de outros planos Detalhes das inter-relações e referências com toda continuidade e outros planos de recuperação e de como as interfaces são ativados. 2,5 orientação geral Todos os pedidos de informação dos meios de comunicação ou de outras fontes devem ser encaminhados para o Procedimento da empresa. Ao notificar o pessoal de um desastre potencial ou real, siga o definido operacional escalada procedimentos, e em particular: • • • •

Tenha calma e evitar longa conversa Aconselhá-los da necessidade de se referir pedidos de informação a ponto de escalação Aconselhá-los de expectativas e ações (evitar dar-lhes detalhes do incidente menos que seja absolutamente necessário) Se a chamada é atendida por outra pessoa: o Pergunte se o contato está disponível em outros lugares o Se não pode ser ado, deixe uma mensagem para contatá-lo em um determinado número o Não forneça detalhes do incidente o Sempre documentar chamadas detalhes de tempo, respostas e ações.

Todas as actividades e de o / escalada deve ser clara e devidamente registada. Para facilitar isso, as ações devem estar em um formato lista de verificação e não deve haver espaço para registrar a data ea hora do atividade foi iniciado e concluído, e que realizou a atividade.

ITIL V3 - Service Design - Página:

430 de 477

2,6 Dependências Sistema,Infra-estrutura,serviço,facilidade ou interface dependências devem ser documentadas (por ordem de prioridade) para que os planos de recuperação relacionados ou procedimentos que precisam ser invocado em conjunto com o plano de recuperação pode ser identificado e acionadas. O responsável pela chamada deve garantir recuperação atividades são coordenadas com esses outros planos. Sistema Documento de referência Contato

2,7 listas de contato Listas de todos os nomes de contatos, organizaçãos e detalhes de contato e mecanismos: Nome Organização / Papel Título o

2,8 equipe de recuperação O seguinte pessoal / funções são responsáveis por estes actioning procedimentos ou assegurar os procedimentos são acionadas e registrando quaisquer problemas ou problemas encontrados. Contato será feito através do normal escalada procedimentos. Nome Título o

ITIL V3 - Service Design - Página:

431 de 477

ITIL V3 - Service Design - Página:

432 de 477

2,9 lista da equipe de recuperação Para facilitar a execução de atividades-chave em tempo hábil, uma lista semelhante à seguinte deve ser usada. Tarefa Confirme invocação Iniciar uma chamada de três procedimentos e escalada Instigar e interface com outros planos de qualquer recuperação necessária (por exemplo, B, Gerenciamento de Crise, Plano de Resposta de Emergência) Organizar para a mídia de backup e documentação a ser enviada para o site de recuperação (s) Criar equipas de recuperação Iniciar ações de recuperação Confirme relatório de progresso Informe equipe de recuperação das obrigações de informação Confirme requisitos de ligação com todas as equipes de recuperação Aconselhar clientes e gestão de conclusão estimado de recuperação

ITIL V3 - Service Design - Página:

433 de 477

Conclusão alvo

Conclusão real

3 processo de recuperação Digite instruções de recuperação /procedimentos ou referências a todos recuperação procedimentos aqui. Conteúdo / formato deve ser de acordo com as normas da empresa para os procedimentos. Se não houver nenhum, a orientação deve ser emitido pelo Líder Manager ou da equipe para a área responsável pelo sistema, de infra-estrutura, serviços ou instalações. A única orientação é que as instruções devem ser capazes de ser executado por um profissional experiente, sem confiança indevida em conhecimento local. Sempre que necessário, as referências devem ser feitas à documentação de apoio (e sua localização), diagramas e outras fontes de informação. Isto deve incluir o número de referência do documento (se existir). É da responsabilidade do autor plano para assegurar que esta informação é mantida com este plano. Se existe apenas uma quantidade limitada de informação de e, pode ser mais fácil para que isso seja incluído no plano, e este plano continua a ser fácil de ler / seguir e não se torne demasiado complexo.

ITIL V3 - Service Design - Página:

434 de 477

Outras informações Referências 1. Estratégia de Serviço 2. Transição de Serviço 3. Operação de Serviço 4. Melhoria de Serviço Continuada 5. Peter Drucker 6. COBIT - ISACA 7. CMMI - CMU 8. eSCM-Portfólio de Serviço - CMU 9. PRINCE2 - OGC 10. ISO 9000 11. ISO / IEC 20000 12. ISO 27001 13. Empresa Arquitetura - Gartner 14. Planeje fazer verificar Act - W Edwards Deming 15. Balanced Scorecard - Kaplan / Norton 16. Arquitetura Orientada a Serviços - OASIS 17. Gestão de Risco - OGC 18. Prática Recomendada para Especificação de Requisitos de Software (IEEE 830) 19. O Corpo de Engenharia de Software do Conhecimento (SWEBOK) 20. Object Management Architecture - OMG 21. Common Information Model (CIM) - DMTF 22. Web-Based Empresa Gestão (WEBM) - DMTF 23. Aplicação de Gestão de Especificação - IBM 24. Windows Management Instrumentation - Microsoft 25. Desktop Management Instrumentation - Windows 26. Seis Sigma - Motorola 27. Dinâmica de desenvolvimento de software - Jim McCarthy 28. Engenharia de requisitos, exemplos de conhecimento tácito e explícito (Maiden & Rugg, 1995) 29. Análise de Negócios - Deborah Paulo e Donald Yeates 30. Princípios de Gestão de Dados - Keith Gordon 31. Prática de Migração de Dados - John Morris

ITIL V3 - Service Design - Página:

435 de 477

Glossário

Lista de siglas ACD

Distribuição Automática de Chamadas

AM

Gerenciamento de Disponibilidade

AMIS

Disponibilidade do Sistema de Informação de Gestão

ASP

Application Service Provider

BCM

Gerenciamento da Capacidade de negócios

BCM

Gestão de Continuidade de Negócios

B

Plano de Continuidade de Negócios

BIA

Análise de Impacto no Negócio

BRM

Gerente de Relacionamento de Negócios

BSI

British Standards Institution

BSM

Business Service Management

CAB

Alterar Conselho Consultivo

CAB / CE

Alterar Conselho Consultivo / Comitê de Emergência

CAPEX

Despesas de Capital

CCM

Gerenciamento da Capacidade componente

CFIA

Componente Análise de Impacto falha

CI

Item de Configuração

CMDB

Configuration Management Database

CMIS

Capacidade do Sistema de Informação de Gestão

CMM

Capability Maturity Model

CMMI

Capability Maturity Model Integration

CMS

Sistema de Gerenciamento da Configuração

COTS

Comercial da Prateleira

CSF

Fator Crítico de Sucesso

CSI

Melhoria de Serviço Continuada

ITIL V3 - Service Design - Página:

436 de 477

CSIP

Plano de Melhoria de Serviço Continuada

CSP

Pacote de serviços do núcleo

CTI

Computer Telephony Integration

DIKW

Dados para-Informação-para-Conhecimento-para-Sabedoria

ELS

Life cedo

eSCM-CL

eSourcing Capability modelo para organizações clientes

eSCM-SP

eSourcing Modelo de Capacidade para prestadores de serviços

FMEA

Modos de Falha e Análise de Efeitos

FTA

Análise da Árvore de Falhas

IRR

Taxa Interna de Retorno

ISG

Grupo de Coordenação de TI

ISM

Gestão de Segurança da Informação

ISMS

Sistema de Gestão da Segurança

ISO

Organização Internacional para Padronização

ISP

Provedor de serviços de Internet

TI

Tecnologia da Informação

ITSCM

Gerenciamento da Continuidade do Serviço

ITSM

IT Service Management

itSMF

IT Service Management Forum

IVR

Interactive Voice Response

BDEC

Banco de Dados de erro conhecido

KPI

Key Performance Indicator

LOS

Linha de Serviço

M_o_R

Gestão de Risco

MTBF

Tempo médio entre falhas

TMEIS

Tempo médio entre Incidentes de Serviço

MTRS

Tempo médio para restaurar o serviço

MTTR

Mean Time To Repair

VPL

Valor Presente Líquido

OGC

Office of Government Commerce

ITIL V3 - Service Design - Página:

437 de 477

OLA

Acordo de Nível Operacional

OPEX

Despesas operacionais

OPSI

Escritório de Informação do Sector Público

PBA

Padrão de Atividade de Negócios

PIR

Pós-Implementação comentário

PFS

Pré-requisito para o sucesso

PSO

Interrupção do serviço projetado

QA

Garantia de Qualidade

SGQ

Sistema de Gestão da Qualidade

RCA

Análise de causa raiz

RFC

Requisição de Mudança

ROI

Retorno sobre Investimento

RPO

Objetivo do ponto de recuperação

RTO

Objetivo Tempo de recuperação

SoC

Separação de preocupações

SAC

Critérios de aceitação de serviços

SACM

Ativos de Serviços e Gerenciamento de Configuração

SCD

Fornecedor e banco de dados contrato

SCM

Gerenciamento da Capacidade de serviço

SDP

Pacote de Desenho de Serviço

SFA

Análise de falha de serviço

SIP

Plano de Melhoria de Serviço

SKMS

Serviço do Sistema de Gestão do Conhecimento

SLA

Acordo de Nível de Serviço

SLM

Gerenciamento de Nível de Serviço

SLP

Pacote de nível de serviço

SLR

Exigência de Nível de Serviço

SMO

Objetivo de manutenção do serviço

SOP

Procedimentos Operacionais Padrão

SOR

Declaração de requisitos

ITIL V3 - Service Design - Página:

438 de 477

SPI

Interface do provedor de serviços

SPM

Gestão de Portfólio de Serviços

SPO

Otimização de provisionamento de serviços

SPOF

Ponto único de falha

TO

Observation técnica

TOR

Termos de referência

TCO

Custo Total de Propriedade

TCU

Custo Total de Utilização

TQM

Gestão da Qualidade Total

UC

Subjacente Contrato

UP

Perfil do Usuário

VBF

Função de Negócios Vital

VOI

Valor do Investimento

WIP

Work in Progress

ITIL V3 - Service Design - Página:

439 de 477

Lista de definições Os nomes incluídos na publicação parênteses após o nome de um termo de identificar onde o leitor pode encontrar mais informações sobre esse termo. Isto é porque o termo é usado principalmente por que a publicação ou porque informações adicionais úteis sobre esse termo pode ser encontrado lá. Termos sem um nome de publicação que lhes estão associados podem ser utilizados geralmente por várias publicações, ou não pode ser definida em maior detalhe do que pode ser encontrado no glossário, ou seja, nós apenas leitores apontam para algures que podem esperar para expandir o seu conhecimento ou a ver um contexto maior. Termos com nomes de publicação múltiplas são expandidas em em várias publicações. Quando a definição de um termo inclui outro termo, os termos relacionados são destacadas em uma segunda cor. Isto é projetado para ajudar o leitor com a sua compreensão, apontando-os a definições adicionais que são todos parte do termo original que eles estavam interessados dentro A forma 'Ver também X, Y prazo Term "é utilizada no fim de uma definição em que um termo importante relacionado não é utilizado com o texto da própria definição. Aceitação

Acordo formal que um serviço de TI, Processo, Plano ou Deliverable outro é completa, precisa, confiável e cumpre os seus requisitos especificados. A aceitação é geralmente precedido por avaliação ou teste e é muitas vezes necessária antes de prosseguir para a próxima fase de um projeto ou processo. Ver também Critérios de aceitação de serviços.

Contabilidade

(Estratégia de Serviço) O Processo responsável por identificar os custos reais de fornecimento de serviços de TI, comparando-os com os custos orçados e gerenciamento de variância do Orçamento.

Atividade

Um conjunto de ações destinadas a alcançar um determinado resultado. Atividades são geralmente definidas como parte de processos ou planos, e estão documentadas em procedimentos.

Tempo de serviço acordado

(Desenho de Serviço) Um sinônimo de horas de serviço, comumente utilizadas em cálculos formais de Disponibilidade. Veja também Downtime.

Acordo

Um documento que descreve um entendimento formal entre duas ou mais partes. Um acordo não é juridicamente vinculativo, a menos que ele faz parte de um contrato. Ver também Acordo de Nível de Serviço, Acordo de Nível Operacional.

Alertar

(Operação de Serviço) Um aviso de que um limite foi atingido, algo mudou ou uma falha ocorreu. Alertas são muitas vezes criados e gerenciados por ferramentas de gerenciamento do sistema e são gerenciados pelo Processo de Gestão de Eventos.

Modelagem analítica

(Estratégia de Serviço) (Desenho de Serviço) (Melhoria de Serviço

ITIL V3 - Service Design - Página:

440 de 477

Continuada) Uma técnica que utiliza modelos matemáticos para prever o comportamento de um Item de Configuração ou Serviço de TI. Modelos analíticos são comumente usados em Gestão de Capacidade e Gerenciamento da Disponibilidade. Veja também Modelagem. Aplicação

Software que fornece funções que são exigidas por um serviço de TI. Cada aplicação pode ser parte de mais do que um serviço de TI. Um aplicativo é executado em um ou mais servidores ou clientes. Veja também Gerenciamento de Aplicativos, Application Portfolio.

Aplicação de Gestão de

(Desenho de Serviço) (Operação de Serviço) A Função responsável por gerenciar aplicativos durante todo seu ciclo de vida.

Application Portfolio

(Desenho de Serviço) Um banco de dados de documentos ou estruturado usado para gerenciar aplicativos em todo o seu ciclo de vida. O portfólio de aplicativos contém atributos-chave de todas as aplicações. O portfólio de aplicativos às vezes é implementada como parte do portfólio de serviços, ou como parte do Sistema de Gestão de Configuração.

Application Service Provider

(Desenho de Serviço) Um provedor de serviço externo que fornece serviços de TI utilizando aplicativos executados nas instalações do prestador de serviços. Os usuários am os aplicativos por conexões de rede para o provedor de serviço.

Aplicação de Dimensionamento

(Desenho de Serviço) A Atividade responsável por entender as necessidades de recursos necessários para ar um aplicativo novo, ou uma grande mudança para um aplicativo existente. Dimensionamento aplicação ajuda a garantir que o Serviço de TI pode cumprir as suas metas de serviço acordadas a nível de desempenho e capacidade.

Arquitetura

(Desenho de Serviço) A estrutura de um sistema ou serviço de TI, incluindo as relações de componentes para o outro e para o meio ambiente que estão dentro Arquitetura também inclui as normas e diretrizes que orientam a concepção e evolução do sistema.

Avaliação

Inspeção e análise para verificar se um padrão ou conjunto de orientações está sendo seguido, que os registros são precisos, ou que os objectivos de eficiência e eficácia estão sendo atendidas. Veja também auditoria.

Ativos

(Estratégia de Serviço) qualquer recurso ou capacidade. Activos de um provedor de serviço, incluindo tudo o que poderia contribuir para a prestação de um serviço. Os ativos podem ser um dos seguintes tipos: Gestão, Organização, Conhecimento, Processo, Pessoas, informações, aplicações, infra-estrutura e do capital financeiro.

Gestão de Ativos

(Transição de Serviço) Asset Management é o processo responsável por acompanhar e relatar o valor ea propriedade de ativos financeiros em todo o seu ciclo de vida. Asset Management é parte de um activo Serviço geral e processo de gestão de configuração.

Atributo

(Transição de Serviço) Um pedaço de informações sobre um item de configuração. Exemplos são: nome, localização, número da versão e Custo. Atributos de ICs são registrados no Configuration Management

ITIL V3 - Service Design - Página:

441 de 477

Database (CMDB). Veja também Relacionamento. Auditar

Inspeção formal e verificação para verificar se um padrão ou conjunto de orientações está sendo seguido, que os registros são precisos, ou que os objectivos de eficiência e eficácia estão sendo atendidas. Uma auditoria pode ser efectuada por grupos internos ou externos. Veja também avaliação, certificação.

Distribuição Automática de Chamadas

(Operação de Serviço) O uso da Tecnologia da Informação para direcionar uma chamada telefónica para a pessoa mais adequada no menor tempo possível. ACD é às vezes chamado de distribuição automática de chamadas.

Disponibilidade

(Desenho de Serviço) Capacidade de um item de configuração ou serviço de TI para executar sua função acordada quando necessário. A disponibilidade é determinada pela Confiabilidade, Manutenção, manutenção, desempenho e segurança. A disponibilidade é normalmente calculada como uma percentagem. Este cálculo é muitas vezes baseadas em tempo de serviço acordado e tempo de inatividade. Ela é a melhor prática para calcular a disponibilidade usando medições da saída de Negócios do Serviço de TI.

Gerenciamento de Disponibilidade

(Desenho de Serviço) O Processo responsável pela definição, análise, planejamento, medir e melhorar todos os aspectos da disponibilidade dos serviços de TI. Gerenciamento de Disponibilidade é responsável por garantir que todas as infra-estruturas de TI, Processos, Ferramentas, Funções, etc são apropriados para as metas de serviço acordado nível de disponibilidade.

Disponibilidade do Sistema de Informação de Gestão

(Desenho de Serviço) Um repositório virtual de todos os dados de gerenciamento de disponibilidade, normalmente armazenados em vários locais físicos. Veja também Serviço de Sistema de Gestão do Conhecimento.

Plano de disponibilidade

(Desenho de Serviço) Um plano para garantir que os requisitos de disponibilidade existentes e futuras por serviços de TI pode ser fornecido de maneira rentável.

Voltar-out

Veja Remediação.

Faça backup

(Desenho de Serviço) (Operação de Serviço) Copiar dados para proteger contra a perda de integridade ou disponibilidade do original.

Balanced Scorecard

(Melhoria de Serviço Continuada) Uma ferramenta de gestão desenvolvido pelos drs. Robert Kaplan (Harvard Negócio Escola) E David Norton. O Balanced Scorecard permite uma estratégia a ser dividido em indicadores de desempenho. Desempenho em relação ao KPIs são usados para demonstrar o quão bem a estratégia está sendo alcançado. O Balanced Scorecard tem quatro áreas principais, cada um dos quais tem um pequeno número de KPIs. As mesmas quatro áreas são consideradas em diferentes níveis de detalhe em toda a Organização.

Linha de base

(Melhoria de Serviço Continuada) Uma referência usada como um ponto de referência. Por exemplo:

ITIL V3 - Service Design - Página:

442 de 477

• •

•

Referência

Uma linha de base ITSM pode ser usada como um ponto de partida para medir o efeito de um Plano de Melhoria de Serviço Um parâmetro de desempenho pode ser usado para medir as mudanças no desempenho sobre o tempo de vida de um serviço de TI A linha de base do Gerenciamento da Configuração pode ser usado para permitir que a infra-estrutura de TI para ser restaurado para uma configuração de sabe se uma Alterar ou lançamento falhar.

(Melhoria de Serviço Continuada) O estado de algo gravado em um ponto específico no tempo. A referência pode ser criado para uma configuração, um processo, ou qualquer outro conjunto de dados. Por exemplo, um valor de referência pode ser utilizada em: • •

Melhoria de Serviço Continuada, para estabelecer o estado atual para o gerenciamento de melhorias Gerenciamento da Capacidade, para documentar as características de desempenho durante as operações normais.

Veja também Base de Benchmarking. Aferição

(Melhoria de Serviço Continuada) Comparando-se uma referência com uma linha de base ou com a Melhor Prática. A avaliação do desempenho termo também é utilizado para significar a criação de uma série de parâmetros de referência ao longo do tempo, e comparando os resultados para medir o progresso ou melhoria.

Melhores Práticas

Atividades comprovadas ou processos que têm sido utilizados com sucesso por várias organizações. ITIL é um exemplo de boas práticas.

Brainstorming

(Desenho de Serviço) Uma técnica que ajuda uma equipe a gerar idéias. As idéias não são revisados durante a sessão de brainstorming, mas numa fase posterior. Brainstorming é muitas vezes usado pelo Gerenciamento de Problemas para identificar as possíveis causas.

Orçamento

Uma lista de todo o dinheiro que uma unidade organizacional ou planos de negócios para receber, e planeja pagar, durante um período de tempo especificado. Veja também Planejamento, Orçamento.

Orçamento

A Atividade de prever e controlar o gasto de dinheiro. Consiste de um ciclo de negociação periódica para definir orçamentos futuros (geralmente anual) eo acompanhamento do dia-a-dia e de ajuste de Orçamentos atuais.

Construir

(Transição de Serviço) a actividade de montagem de uma série de itens de configuração para criar parte de um Serviço de TI. Construir o termo é também usado para se referir a uma versão que está autorizado para distribuição. Por exemplo Build Server ou laptop

ITIL V3 - Service Design - Página:

443 de 477

Construir. Veja também linha de base de configuração. Negócio

(Estratégia de Serviço) Uma entidade corporativa geral ou Organização formada por um número de Unidades de Negócios. No contexto do ITSM, o termo Business inclui setor público e sem fins lucrativos, bem como empresas. Um provedor de serviço de TI fornece serviços de TI para um cliente dentro de uma empresa. O prestador de serviço de TI pode ser parte do negócio mesmo que o seu cliente (prestador de serviços interno), ou parte de outro negócio (prestador de serviços externo).

Gerenciamento da Capacidade de negócios

(Desenho de Serviço) No contexto do ITSM, Negócios Gerenciamento da Capacidade é a Atividade responsável por entender Requisitos de Negócio de futuro para utilização no Plano de Capacidade. Ver também Gerenciamento da Capacidade de serviço.

Business Case

(Estratégia de Serviço) Justificação para um item significativo das despesas. Inclui informações sobre custos, benefícios, opções, problemas, riscos e possíveis problemas. Veja também Análise de Custo-Benefício.

Gestão de Continuidade de Negócios

(Desenho de Serviço) O processo de negócio responsável pela gestão de riscos que podem afectar gravemente o negócio. BCM salvaguardas os interesses dos principais interessados, marca, reputação e atividades que criam valor. O processo de BCM envolve a redução dos riscos para um nível aceitável e planejamento para a recuperação de Processos de Negócios deve uma interrupção dos negócios ocorrem. BCM estabelece os objectivos, âmbito e Requisitos para Gerenciamento de Continuidade de Serviço.

Plano de Continuidade de Negócios

(Desenho de Serviço) Um Plano que define os os necessários para restaurar os processos de negócios após uma interrupção. O Plano também vai identificar os gatilhos para Invocação, pessoas a serem envolvidas, comunicações, etc TI planos de continuidade de serviço formam uma parte significativa dos Planos de Continuidade de Negócios.

Cliente negócio

(Estratégia de Serviço) Um destinatário de um produto ou um serviço do negócio. Por exemplo, se a empresa é uma fabricante de automóveis, então o cliente de negócios é alguém que compra um carro.

Análise de Impacto no Negócio

(Estratégia de Serviço) BIA é a atividade em Gestão de Continuidade de Negócios que identifica funções vitais do negócio e suas dependências. Estas dependências podem incluir fornecedores, pessoas, outros processos de negócios, serviços de TI, etc BIA define os requisitos de recuperação de serviços de TI. Estes requisitos são: Objetivos tempo de recuperação, os objetivos de ponto de recuperação e metas de serviço mínimo para cada nível de serviço de TI.

Objetivo do Negócio

(Estratégia de Serviço) O objectivo de um processo de negócio, ou da empresa como um todo. Objetivos do Negócio apoiar a visão de negócios, fornecer orientações para a Estratégia de TI, e são muitas vezes apoiados por serviços de TI.

ITIL V3 - Service Design - Página:

444 de 477

Operações comerciais

(Estratégia de Serviço) O dia-a-dia de execução, monitoramento e gerenciamento de processos de negócios.

Perspectiva de Negócios

(Melhoria de Serviço Continuada) Uma compreensão do prestador de serviços e serviços de TI a partir do ponto de vista do negócio, e uma compreensão do negócio do ponto de vista do provedor de serviço.

Business Process

Um processo que é de propriedade e realizada pelo Negócios. A Business Process contribui para a entrega de um produto ou serviço a um cliente de Negócios. Por exemplo, um varejista pode ter um processo de compras que ajuda a fornecer serviços a seus clientes corporativos. Muitos processos de negócio dependem de serviços de TI.

Gestão de Relacionamento com Empresas

(Estratégia de Serviço) O Processo ou Função responsável por manter um relacionamento com a empresa. Gestão de Relacionamento de Negócios geralmente inclui: • • •

Gerenciamento de relacionamentos pessoais com gerentes de negócios Fornecer subsídios para Gerenciamento de Portfólio de serviço Assegurando que o prestador de serviço de TI é satisfazer as necessidades de negócios dos clientes

Este processo tem fortes ligações com Service Level Management. Business Service

Um serviço de TI que a diretamente um processo de negócio, ao contrário de um Serviço de Infra-estrutura, que é utilizado internamente pelo provedor de serviço de TI e normalmente não é visível para o negócio. O Business Service termo também é usado para significar um serviço que é entregue aos clientes empresariais por Unidades de Negócio. Por exemplo, a prestação de serviços financeiros para clientes de um banco, ou de mercadorias para os clientes de uma loja de varejo. Entrega bem sucedida de serviços de negócios, muitas vezes depende de um ou mais serviços de TI.

Business Service Management

(Estratégia de Serviço) (Desenho de Serviço) Uma abordagem para o gerenciamento de serviços de TI que considera a processos de negócio ados eo valor de negócio fornecida. Este termo também significa a gestão de serviços de negócios entregues a clientes empresariais.

Unidade de Negócios

(Estratégia de Serviço) Um segmento do negócio que tem seus próprios planos, métricas, proveitos e custos. Cada Unidade de Negócio possui ativos e usa-os para criar valor para os clientes na forma de bens e serviços.

Chamar

(Operação de Serviço) Uma chamada telefónica para o Posto de Serviço de um Usuário. Uma chamada pode resultar em um incidente ou uma solicitação de serviço sendo registrado.

ITIL V3 - Service Design - Página:

445 de 477

Call Center

(Operação de Serviço) Uma Unidade de organização ou empresa que lida com um grande número de chamadas telefónicas de entrada e saída. Veja também Service Desk.

Capacidade

(Estratégia de Serviço) A capacidade de uma organização, pessoa, item de processo, configuração do aplicativo, ou serviço de TI para realizar uma atividade. Recursos são os ativos intangíveis de uma organização. Veja também de recursos.

Capacidade

(Desenho de Serviço) a vazão máxima que um Item de Configuração ou Serviço de TI pode entregar reunião enquanto acordaram metas de nível de serviço. Para alguns tipos de CI, A capacidade pode ser do tamanho ou do volume, por exemplo, uma unidade de disco.

Gerenciamento da Capacidade

(Desenho de Serviço) O Processo responsável por garantir que a capacidade dos serviços de TI ea infra-estrutura de TI é capaz de entregar as metas de nível de serviço acordado de forma eficaz e atempada. Gerenciamento da Capacidade considera todos os recursos necessários para oferecer o serviço de TI e planos para curto, Requisitos de Negócio de médio e longo prazo.

Capacidade do Sistema de Informação de Gestão

(Desenho de Serviço) Um repositório virtual de todos os dados de gerenciamento de capacidade, normalmente armazenados em vários locais físicos. Veja também Serviço de Sistema de Gestão do Conhecimento.

Plano de capacidade

(Desenho de Serviço) Um Plano de Capacidade é usado para gerenciar os recursos necessários para entregar serviços de TI. O Plano contém cenários para as previsões de demanda de negócios diferentes e opções orçamentados para entregar os objetivos de nível de serviço acordado.

Planejamento de Capacidade

(Desenho de Serviço) a atividade dentro de Gerenciamento da Capacidade responsável pela criação de um plano de capacidade.

Categoria

Um grupo nomeado de coisas que têm algo em comum. Categorias são usadas para agrupar coisas semelhantes. Por exemplo, os tipos de custos são usadas para agrupar tipos similares de custo. Categorias incidentes são usadas para agrupar tipos semelhantes de Incidentes, Tipos de CI são usadas para agrupar tipos semelhantes de item de configuração.

Certificado

Emissão de um certificado para confirmar a conformidade a um padrão. Certificação inclui uma auditoria formal por um organismo independente e credenciada. A Certificação termo também é usado para significar a atribuição de um certificado para verificar se uma pessoa tem alcançado uma qualificação.

Mudar

(Transição de Serviço) A adição, modificação ou remoção de tudo o que poderia ter um efeito sobre serviços de TI. O escopo deve incluir todos os Serviços de TI, itens de configuração, processos, documentação, etc

Alterar Conselho Consultivo

(Transição de Serviço) Um grupo de pessoas que aconselha o Gerente de Mudança na avaliação, priorização e agendamento de alterações. Esta placa é geralmente composto por representantes de todas as

ITIL V3 - Service Design - Página:

446 de 477

áreas dentro do provedor de serviço de TI, representantes do negócio e terceiros, como fornecedores. Mudar a História

(Transição de Serviço) Informações sobre todas as alterações feitas em um Item de Configuração durante a sua vida. História mudança consiste de todos esses registros de mudança que se aplicam ao CI.

Gestão da Mudança

(Transição de Serviço) O Processo responsável por controlar o ciclo de vida de todas as alterações. O principal objectivo da Gestão da Mudança é permitir que mudanças benéficas para ser feita, com o mínimo de perturbação para serviços de TI.

Solicitação de Mudança

Veja Requisição de Mudança.

Alterar agendamento

(Transição de Serviço) um documento que lista todas as alterações aprovadas e as respectivas datas de execução previstos. Um programa de troca é às vezes chamado de Programação Futura de Mudanças, mesmo que também contém informações sobre as mudanças que já foram implementadas.

Janela Alterar

(Transição de Serviço) Um regular, concordou momento Alterações ou Releases podem ser implementadas com o mínimo impacto sobre Serviços. O Windows mudança normalmente são documentados em SLAs.

Carregamento

(Estratégia de Serviço) exigência de pagamento por serviços de TI. Cobrança de Serviços de TI é opcional, e muitas organizações escolha para tratar o seu fornecedor de serviço de TI como um Centro de Custo.

Classificação

O ato de atribuir uma categoria para algo. A classificação é usada para garantir uma gestão coerente e de relatórios. CIs, incidentes, problemas, mudanças, etc, são geralmente classificados.

Cliente

Um termo genérico que significa um cliente, a empresa ou um cliente de negócios. Por exemplo, Client Manager pode ser usado como sinônimo de Gerente de Contas. O cliente termo também é utilizado para significar: • •

Um computador que é usado diretamente por um usuário, por exemplo, um PC, computador portátil, estação de trabalho ou A parte de uma aplicação cliente-servidor que o usuário diretamente a interface com. Por exemplo, um cliente de e-mail.

Fechado

(Operação de Serviço) O status final no Ciclo de Vida de um Incidente, Problema, Mudança, etc Quando o Estado está fechada, nenhuma outra ação será tomada.

Fecho

(Operação de Serviço) O ato de mudar o status de um incidente, problemas, mudanças, etc, para Fechado.

ITIL V3 - Service Design - Página:

447 de 477

COBIT

(Melhoria de Serviço Continuada) Objetivos de Controle para Informações e Tecnologia relacionada (COBIT) fornece orientação prática e melhor para a gestão de processos de TI. COBIT é publicado pelo Instituto de Governança de TI. Veja www.isaca.org para mais informações.

Espera frio

Ver recuperação gradual.

Commercial Off-theshelf

(Desenho de Serviço) O software aplicativo ou Middleware que pode ser comprado de uma terceira parte.

Observância

A garantia de que uma norma ou conjunto de orientações é seguida, ou que as práticas adequada, contabilidade consistente ou outra estão sendo empregados.

Componente

Um termo geral que é utilizado para significar uma parte de algo mais complexo. Por exemplo, um sistema de computador pode ser um componente de um Serviço de TI, um aplicativo pode ser um componente de uma Unidade de lançamento. Os componentes que precisam ser gerenciados deve ser Itens de Configuração.

Gerenciamento da Capacidade componente

(Desenho de Serviço) (Melhoria de Serviço Continuada) O processo responsável por entender a capacidade de utilização e desempenho dos itens de configuração. Os dados são recolhidos, registados e analisados para o uso no Plano de Capacidade. Ver também Gerenciamento da Capacidade de serviço.

Componente CI

(Transição de Serviço) Um item de configuração que é parte de um conjunto. Por exemplo, um IC U ou de memória pode fazer parte de um CI Server.

Componente Análise de Impacto falha

(Desenho de Serviço) Uma técnica que ajuda a identificar o impacto da falha CI em serviços de TI. A matriz é criada com TI em uma extremidade e IC, por outro. Isso permite a identificação de itens de configuração crítica (que poderia causar o fracasso de múltiplos serviços de TI) e de Serviços de TI (frágeis que têm vários pontos únicos de falha).

Simultaneidade

Uma medida do número de utilizadores que efectuam a mesma operação ao mesmo tempo.

Confidencialidade

(Desenho de Serviço) Um princípio de segurança que requer que os dados devem ser ados somente por pessoas autorizadas.

Configuração

(Transição de Serviço) Um termo genérico, usado para descrever um grupo de itens de configuração que trabalham em conjunto para oferecer um serviço de TI ou uma parte reconhecível de um Serviço de TI. Configuração também é utilizada para descrever as configurações de parâmetros para um ou mais itens de configuração.

Base de configuração

(Transição de Serviço) Uma linha de base de uma configuração que tenha sido formalmente aceite e é gerido através do processo de Gerenciamento de Mudança. A linha de base de configuração é usado como base para futuras Builds, Releases e alterações.

Controle de

(Transição de Serviço) A Atividade responsável por garantir que

ITIL V3 - Service Design - Página:

448 de 477

Configuração

adicionar, alterar ou remover um CI é adequadamente gerida, por exemplo através da apresentação de um pedido de alteração ou solicitação de serviço.

Identificação da Configuração

(Transição de Serviço) A Atividade responsável por coletar informações sobre itens de configuração e seus relacionamentos, e carregar essa informação na CMDB. Identificação configuração também é responsável para rotular o IC-se, de modo que os registos de configuração correspondente pode ser encontrada.

Item de Configuração

(Transição de Serviço) qualquer componente que precisa de ser gerida de forma a oferecer um serviço de TI. As informações sobre cada IC é registrada em um registro de configuração dentro do Sistema de Gestão de Configuração e é mantido durante todo seu ciclo de vida pelo Configuration Management. CIs estão sob o controle de Gerenciamento de Mudança. ICs tipicamente incluem serviços de TI, hardware, software, prédios, pessoas e documentação formal, como a documentação do processo e SLAs.

Gerenciamento da Configuração

(Transição de Serviço) O Processo responsável por manter informações sobre Itens de Configuração necessários para entregar um serviço de TI, incluindo seus relacionamentos. Esta informação é gerenciada durante todo o ciclo de vida do CI. Gerenciamento de Configuração é parte de um activo Serviço geral e processo de gestão de configuração.

Sistema de Gerenciamento da Configuração

(Transição de Serviço) Um conjunto de ferramentas e bases de dados que são usados para gerenciar dados de um provedor de serviços de TI de configuração. O CMS também inclui informações sobre incidentes, problemas, erros conhecidos, mudanças e lançamentos, e podem conter dados sobre os funcionários, fornecedores, locais, unidades de negócios, clientes e usuários. O CMS inclui ferramentas para coletar, armazenar, gerenciar, atualizar e apresentar dados sobre todos os itens de configuração e seus relacionamentos. O CMS é mantida pela Gerência de Configuração e é utilizado por todos os processos de gerenciamento de serviços. Veja também Serviço de Sistema de Gestão do Conhecimento.

Melhoria de Serviço Continuada

(Melhoria de Serviço Continuada) Uma fase no Ciclo de Vida de um Serviço de TI eo título de uma das ITIL Núcleo publicações. Melhoria de Serviço Continuada é responsável pela gestão de melhorias para os processos de gerenciamento de serviços de TI e Serviços. O desempenho do prestador de serviço de TI é continuamente medido e melhorias são feitas para Processos, Serviços de TI e infraestrutura de TI, a fim de aumentar a eficiência, eficácia e rentabilidade. Veja também Plan-Do-Check-Act.

Disponibilidade contínua

(Desenho de Serviço) Uma abordagem ou desenho para atingir 100% de disponibilidade. Um continuamente disponível de Serviços de TI não tem tempo de inatividade planejado ou não.

Operação Contínua

(Desenho de Serviço) Uma abordagem ou desenho para eliminar tempo de inatividade planejado de um Serviço de TI. Note-se que itens de configuração individuais podem ser baixo, embora o serviço esteja disponível.

ITIL V3 - Service Design - Página:

449 de 477

Contrato

Um acordo legalmente vinculativo entre duas ou mais partes.

Controlar

Um meio de gestão de um risco, garantindo que um objectivo de negócio é alcançado, ou garantir que um processo é seguido. Controles de exemplo incluem políticas, procedimentos, funções RAID, fechaduras, etc Um controle às vezes é chamado de contramedidas ou de salvaguarda. Controle também significa gerenciar a utilização ou o comportamento de um sistema de configuração do item, ou Serviço de TI.

Controle de perspectiva

(Estratégia de Serviço) Uma abordagem para a gestão de serviços de TI, processos, funções, bens, etc Pode haver várias perspectivas diferentes sobre o Controle de Serviços de TI mesmo, processo, etc, permitindo que diferentes indivíduos ou equipes a concentrar-se no que é importante e relevantes para a sua função específica. Perspectivas de Controle de exemplo incluem gestão reativa e proativa dentro de Operações de TI, ou uma visão do ciclo de vida de uma equipe de projeto de aplicação.

Custar

A quantidade de dinheiro gasto em uma atividade específica, de Serviços de TI, ou Unidade de Negócios. Custos consistem de custo real (dinheiro), custo teórico, como o tempo das pessoas, e de depreciação.

Análise de CustoBenefício

Uma atividade que analisa e compara os custos e os benefícios envolvidos em um ou mais cursos alternativos de ação. Ver também Processo de Negócios, Retorno sobre o Investimento.

Eficácia de Custo

Uma medida do equilíbrio entre a eficácia eo custo de um serviço, processo ou atividade. Um processo de custo eficaz é aquele que atinge os seus objectivos a um custo mínimo. Veja também KPI, Retorno sobre o Investimento, Value for Money.

Contramedida

Pode ser usado para se referir a qualquer tipo de controlo. O termo de contramedidas é mais frequentemente usado quando se refere a medidas que aumentar a resiliência, tolerância a falhas ou a confiabilidade de um serviço de TI.

Gestão de Crises

(Gerenciamento de Continuidade de Serviços) de Gestão de Crise é o processo responsável por gerenciar as implicações mais amplas de Continuidade de Negócios. Uma equipe de Gestão de Crise é responsável por questões estratégicas como a gestão de relações com a mídia e confiança dos acionistas, e decide quando invocar Planos de Continuidade de Negócios.

Fator Crítico de Sucesso

Algo que deve acontecer se um processo, projeto, plano ou Serviço de TI é ter sucesso. KPIs são usados para medir a realização de cada CSF. Por exemplo, uma LCR de "proteger Serviços de TI ao fazer alterações" poderiam ser medidos por KPIs como "redução percentual de alterações mal sucedidas", "percentagem de redução Alterações causando incidentes", etc

Cultura

Um conjunto de valores que são compartilhados por um grupo de pessoas, incluindo expectativas sobre como as pessoas devem se comportar, as suas ideias, crenças e práticas. Ver também Visão.

ITIL V3 - Service Design - Página:

450 de 477

Cliente

Alguém que compra produtos ou serviços. O cliente de um provedor de serviço de TI é a pessoa ou grupo que define e aprova as metas de nível de serviço. Os Clientes prazo também é por vezes usado informalmente para significar Usuários, por exemplo, 'Esta é uma organização focada no cliente ".

de instrumentos

(Operação de Serviço) Uma representação gráfica do desempenho geral do serviço de TI e disponibilidade. Imagens do podem ser atualizados em tempo real, e podem também ser incluídos nos relatórios de gestão e páginas web. Painéis podem ser utilizados para apoiar Gestão de Nível de Serviço, Gestão de Eventos ou Diagnóstico de Incidentes.

Deliverable

Algo que deve ser fornecida para cumprir um compromisso em um Acordo de Nível de Serviço ou um contrato. Deliverable também é usado de uma forma mais informal de significar uma saída prevista de qualquer processo.

Gerenciamento da Demanda

Atividades que compreendem e influenciar a demanda de clientes por serviços e na oferta de capacidade para atender a essas demandas. Em uma Gestão Estratégica nível de demanda pode envolver análise de padrões de atividade de negócio e perfis de usuário. Em um nível tático que pode envolver o uso de taxas diferenciadas para incentivar os clientes a usar serviços de TI em momentos de menor movimento. Veja também Gerenciamento da Capacidade.

Dependência

A dependência directa ou indirecta de um processo ou atividade em outro.

Desenvolvimento

(Transição de Serviço) A Atividade responsável pelo movimento de hardware novo ou alterado, software, documentação, processos, etc, para o ambiente ao vivo. A implantação é parte do lançamento e Processo de Gestão de Implantação.

Projeto

(Desenho de Serviço) uma atividade ou processo que identifica os requisitos e depois define uma solução que é capaz de atender a esses requisitos. Ver também Design de Serviços.

Detecção

(Operação de Serviço) Uma fase no Ciclo de Vida de Incidentes. Resultados de detecção no incidente se tornar conhecido para o provedor de serviço. A detecção pode ser automática, ou pode ser o resultado de um utilizador iniciar sessão um incidente.

Desenvolvimento

(Desenho de Serviço) O Processo responsável pela criação ou modificação de um serviço de TI ou de aplicativos. Também é usado para significar a função ou grupo que realiza trabalho de desenvolvimento.

Ambiente de Desenvolvimento

(Desenho de Serviço) Um Ambiente utilizada para criar ou modificar serviços de TI ou Aplicações. Ambientes de Desenvolvimento não são normalmente sujeitas ao mesmo grau de controle como ambientes de teste ou ambientes vivos. Veja também Desenvolvimento.

Diagnóstico

(Operação de Serviço) no estádio A de os ciclos de vida de incidentes e problemas. O objetivo do diagnóstico é identificar uma solução para um incidente ou a causa raiz de um problema.

ITIL V3 - Service Design - Página:

451 de 477

Diferencial de carregamento

Uma técnica usada para apoiar Gestão de Demanda cobrando valores diferentes para a mesma função de Serviços de TI em momentos diferentes.

Documento

Informações de forma legível. Um documento pode ser papel ou eletrônico. Por exemplo, uma declaração política, Acordo de Nível de Serviço, Registro de Incidentes, diagrama do layout da sala de computador. Veja também Record.

Tempo de inatividade

(Desenho de Serviço) (Operação de Serviço) O momento em que um Item de Configuração ou Serviço de TI não está disponível durante o seu tempo de serviço acordado. A disponibilidade de um serviço muitas vezes é calculado a partir de tempo de serviço acordado e tempo de inatividade.

Motorista

Algo que influencia estratégia, objectivos ou exigências. Por exemplo, a nova legislação ou as ações dos concorrentes.

Economias de escala

(Estratégia de Serviço) A redução do custo médio que é possível de aumentar o uso de um serviço de TI ou de Ativos.

Eficácia

(Melhoria de Serviço Continuada) Uma medida se os objectivos do Processo de um serviço ou atividade foram alcançados. Um processo efetivo ou atividade é aquele que atinge os seus objectivos acordados. Veja também KPI.

Eficiência

(Melhoria de Serviço Continuada) Uma medida de se o direito quantidade de recursos foi utilizada para fornecer um processo, serviço ou atividade. Um processo eficiente alcança seus objetivos com o mínimo de tempo, dinheiro, pessoas ou outros recursos. Veja também KPI.

Ambiente

(Transição de Serviço) Um subconjunto da infra-estrutura de TI que é usado para um propósito particular. Por exemplo: Ambiente Live, Test Environment, ambiente de construção. É possível para vários ambientes para compartilhar um item de configuração, por exemplo, ambientes de teste e ao vivo pode usar partições diferentes em um computador único mainframe. Também é usado no ambiente de prazo Física para significar a acomodação, ar condicionado, sistema de energia, etc Ambiente também é usado como um termo genérico para designar as condições externas que influenciam ou afetam algo.

Erro

(Operação de Serviço) falha ou mau funcionamento Um projeto que faz com que uma falha de um ou mais itens de configuração ou serviços de TI. Um erro cometido por uma pessoa ou um processo deficiente que afeta um serviço IC ou também é um erro.

Escalada

(Operação de Serviço) Uma Atividade que obtém recursos adicionais, quando estes são necessários para cumprir as metas de nível de serviço ou expectativas dos clientes. Escalada pode ser necessária dentro de qualquer Processo de Gestão de Serviços de TI, mas é mais comumente associado com a Gestão de Incidentes, Gestão de Problemas e gestão de reclamações de clientes. Existem dois tipos de escalada escalada, funcional e escalonamento hierárquico.

ITIL V3 - Service Design - Página:

452 de 477

eSourcing Modelo de Capacidade para prestadores de serviços

(Estratégia de Serviço) Uma estrutura para ajudar os provedores de serviços desenvolvem as suas capacidades de gestão de serviços de TI a partir de uma perspectiva de serviço de sourcing. eSCM-SP foi desenvolvido pela Carnegie Mellon University,EUA.

Estimativa

O uso da experiência para fornecer um valor aproximado para uma Métrica ou Custo. Estimativa é usado também em capacidade e gestão de disponibilidade como o método mais barato e Modelagem menos preciso.

Avaliação

(Transição de Serviço) O Processo responsável por avaliar um novo ou alterado Serviço de TI para garantir que os riscos foram gerenciados e para ajudar a determinar se deseja prosseguir com a mudança. Avaliação também é usada para significar comparar um resultado real com o resultado pretendido, ou comparar uma alternativa com outra.

Evento

(Operação de Serviço) Uma mudança de estado que tem importância para a gestão de um Item de Configuração ou Serviço de TI. O Evento termo também é usado para significar um Alerta ou notificação criada por qualquer TI item Configuração do serviço, ou a ferramenta de monitoramento. Eventos geralmente requerem pessoal de operações de TI tomar medidas, e muitas vezes levam a Incidentes sendo registrados.

Gestão de Eventos

(Operação de Serviço) O Processo responsável por gerenciar eventos durante todo seu ciclo de vida. Gestão de Eventos é uma das principais atividades das operações de TI.

Relatório de Exceção

Um documento contendo detalhes de um ou mais KPIs ou outros alvos importantes que tenham ultraado os limites definidos. Exemplos incluem SLA alvos sendo perdidas ou prestes a ser perdida, e uma métrica de desempenho que indica um problema de capacidade potencial.

Ciclo de Vida do Incidente Expandido

(Gerenciamento de Disponibilidade) etapas detalhadas no ciclo de vida de um incidente. Os estágios são detecção, diagnóstico, reparação, restauração, reconstrução. O Ciclo de Vida do Incidente Expandido é usado para ajudar a compreender todas as contribuições para o impacto dos incidentes e planejar como esses poderiam ser controlados ou reduzidos.

Prestador de serviços externo

(Estratégia de Serviço) Um provedor de serviço de TI que faz parte de uma organização diferente ao seu cliente. Um provedor de serviço de TI pode ter clientes internos e clientes externos.

Externa de Sourcing

Veja Outsourcing.

Gestão de Instalações (Operação de Serviço) A Função responsável por gerenciar o ambiente físico onde a infra-estrutura de TI está localizado. Facilities Management inclui todos os aspectos de gestão do ambiente físico, para poder exemplo e refrigeração, construção de o, gestão e monitoramento ambiental.

ITIL V3 - Service Design - Página:

453 de 477

Falha

(Operação de Serviço) Perda de capacidade de operar com a especificação, ou para entregar a saída necessária. A falha termo pode ser usado quando se refere a serviços de TI, processos, atividades, itens de configuração, etc Uma falha muitas vezes causa um Incidente.

Recuperação rápida

(Desenho de Serviço) Uma opção de recuperação que também é conhecido como Hot Standby. A provisão é feita para recuperar o serviço que num curto espaço de tempo: geralmente menos do que 24 horas. Recuperação rápida geralmente usa uma instalação dedicada fixo com sistemas de computadores, software e configurado pronto para executar os serviços de TI. Recuperação rápida pode levar até 24 horas, se há a necessidade de restaurar os dados a partir de backups.

Culpa

Veja erro.

Tolerância a Falhas

(Desenho de Serviço) A capacidade de um serviço de TI ou Item de Configuração para continuar a funcionar corretamente após falha de um componente. Veja também Resiliência, de contramedidas.

Análise da Árvore de Falhas

(Desenho de Serviço) (Melhoria de Serviço Continuada) Uma técnica que pode ser usada para determinar a cadeia de acontecimentos que conduz a um problema. Análise da Árvore de Falhas representa uma cadeia de eventos usando a notação booleana em um diagrama.

Gestão Financeira

(Estratégia de Serviço) A função e os processos responsáveis pela gestão de Orçamento de um provedor de serviço de TI, contabilidade e carregamento de Requisitos.

Apto para o efeito

Um termo informal usado para descrever um processo, Item de Configuração, Serviço de TI, etc, que é capaz de cumprir os seus objectivos ou níveis de serviço. Estar apto para o efeito requer um projeto adequado, implementação, controle e manutenção.

Cumprimento

Realizar atividades para atender a uma necessidade ou exigência. Por exemplo, através de um Serviço de TI novo, ou satisfazer um pedido de serviço.

Função

Uma equipe ou grupo de pessoas e as ferramentas que eles usam para realizar um ou mais processos ou atividades. Por exemplo, o Service Desk. A Função termo também tem dois outros significados: •

•

ITIL V3 - Service Design - Página:

454 de 477

Um destino de um item de configuração, Pessoa, equipe, Processo, ou Serviço de TI. Por exemplo, uma função de um serviço de email pode ser a de armazenar e encaminhar emails de saída, uma função de um processo de negócio pode ser a expedição de mercadorias aos clientes. Para realizar a finalidade pretendida corretamente, "O computador está funcionando".

Governo

Assegurar que as políticas e estratégia são realmente implementadas, e que os processos necessários são corretamente seguidas. Governança inclui a definição de papéis e responsabilidades, medir e comunicar, e tomar medidas para resolver os problemas identificados.

Recuperação gradual

(Desenho de Serviço) Uma opção de recuperação que também é conhecido como espera Fria. Provisão é feita para Recuperar o Serviço de TI em um período de tempo superior a 72 horas. Recuperação gradual geralmente usa um mecanismo portátil ou fixo que tem e ambiental e cabeamento de rede, mas não há sistemas de computador. O hardware e software são instalados como parte do Plano de Continuidade dos Serviços de.

Diretriz

Um documento que descreve Melhores Práticas, que recomenda que deve ser feito. Cumprimento de uma diretriz não é normalmente aplicada. Veja também Standard.

Alta Disponibilidade

(Desenho de Serviço) Uma abordagem ou desenho que minimiza ou esconde os efeitos da falha Item de Configuração sobre os utilizadores de um serviço de TI. Soluções de alta disponibilidade são projetados para atingir um nível acordado de Disponibilidade e fazer uso de técnicas como a Tolerância a Falhas, Resiliência e Recuperação rápida para reduzir o número de incidentes, eo impacto dos incidentes.

Hot Standby

Veja a rápida recuperação ou recuperação imediata.

Recuperação imediata

(Desenho de Serviço) Uma opção de recuperação que também é conhecido como Hot Standby. Provisão é feita para Recuperar o Serviço de TI, sem perda de serviço. Recuperação imediata geralmente usa espelhamento de balanceamento de carga e tecnologias do site Split.

Impacto

(Operação de Serviço) (Transição de Serviço) Uma medida do efeito de um incidente, problema ou mudança nos processos de negócio. Impacto é muitas vezes baseada em como os níveis de serviço serão afetados. Impacto e Urgência são usados para atribuir prioridade.

Incidente

(Operação de Serviço) Uma interrupção não planejada de um serviço de TI ou a redução da qualidade de um serviço de TI. Falha de um item de configuração que ainda não afetou serviço é também um Incidente. Por exemplo, a falha de um disco a partir de um conjunto de espelho.

Gerenciamento de Incidentes

(Operação de Serviço) O Processo responsável por gerenciar o ciclo de vida de todos os incidentes. O objetivo principal do Gerenciamento de Incidentes é retornar o Serviço de TI para clientes o mais rápido possível.

Grave incidente

(Operação de Serviço) Um Registro contendo os detalhes de um incidente. Cada registro Incidente documenta o ciclo de vida de um único incidente.

Custos Indiretos

(Estratégia de Serviço) Um Custo de prestação de um serviço de TI, o que não pode ser alocado integralmente para um cliente específico. Por exemplo, o custo da prestação de servidores compartilhados ou licenças de software. Também conhecido como sobrecarga.

ITIL V3 - Service Design - Página:

455 de 477

Gestão de Segurança da Informação

(Desenho de Serviço) O Processo que garante a confidencialidade, integridade e disponibilidade dos ativos de uma organização, informações, dados e serviços de TI. Gestão de Segurança da Informação geralmente faz parte de uma abordagem organizacional para gerenciamento de segurança que tem um escopo mais amplo do que o provedor de serviço de TI, e inclui a manipulação de papel, construção de o, telefonemas, etc, para toda a Organização.

Sistema de Gestão da Segurança

(Desenho de Serviço) O quadro de políticas, processos, normas, orientações e ferramentas que garantem uma organização pode atingir os seus objectivos de gestão de segurança de informação.

Política de Segurança da Informação

(Desenho de Serviço) A política que governa abordagem da Organização de Gestão de Segurança da Informação.

Tecnologia da Informação

O uso da tecnologia para o armazenamento, comunicação ou processamento de informações. A tecnologia normalmente inclui computadores, telecomunicações, aplicativos e outros softwares. A informação pode incluir dados de negócios, voz, imagens, vídeos, etc Tecnologia da Informação é muitas vezes utilizados para apoiar processos de negócios através de serviços de TI.

Serviço de Infraestrutura

Um serviço de TI que não é usado diretamente pela empresa, mas é exigido pelo provedor de serviço de TI para que eles possam oferecer outros serviços de TI. Por exemplo, serviços de diretório, serviços de identificação, ou serviços de comunicação.

Insourcing

Veja Interna Sourcing.

Integridade

(Desenho de Serviço) Um princípio de segurança que garante que os dados e itens de configuração são modificados somente por pessoas autorizadas e Atividades. Integridade considera todas as possíveis causas de modificação, incluindo software e hardware falha, eventos ambientais e intervenção humana.

Recuperação Intermediário

(Desenho de Serviço) Uma opção de recuperação que também é conhecido como espera iva. Provisão é feita para Recuperar o Serviço de TI em um período de tempo entre 24 e 72 horas. Recuperação intermediário geralmente usa um mecanismo comum portátil ou fixo que tem sistemas de computadores e componentes de rede. O hardware e software precisa ser configurado, e os dados precisam ser restaurados, como parte do Plano de Continuidade dos Serviços de.

Provedor de serviço interno

(Estratégia de Serviço) Um provedor de serviço de TI que faz parte da Organização mesmo que o seu cliente. Um provedor de serviço de TI pode ter clientes internos e clientes externos.

Interna de Sourcing

(Estratégia de Serviço) Usando um provedor de serviço interno para gerenciar serviços de TI.

Organização Internacional para Padronização

A Organização Internacional de Normalização (ISO) é a maior desenvolvedora mundial de Normas. ISO é uma organização nãogovernamental que é uma rede de institutos de padrões nacionais de 156 países. Veja www.iso.org para obter mais informações sobre a ISO.

ITIL V3 - Service Design - Página:

456 de 477

ISO 9000

Um termo genérico que se refere a uma série de normas e diretrizes internacionais para Sistemas de Gestão da Qualidade. Veja www.iso.org para mais informações. Veja também ISO.

ISO 9001

Uma norma internacional para Sistemas de Gestão da Qualidade. Veja também ISO 9000, Norma.

ISO / IEC 20000

ISO Especificação e Código de Boas Práticas para o Gerenciamento de Serviços. ISO / IEC 20000 está alinhado com ITIL Best Practice.

ISO / IEC 27001

(Desenho de Serviço) (Melhoria de Serviço Continuada) Especificação ISO de Gestão de Segurança da Informação. O Código correspondente da prática é a norma ISO / IEC 17799. Veja também Standard.

Infraestrutura de TI

Todo o hardware, software, redes, instalações, etc, que são necessários para desenvolver, testar, entregar, monitorar, controlar ou apoiar serviços de TI. O termo infra-estrutura de TI inclui toda a Tecnologia da Informação, mas não as pessoas associadas, processos e documentação.

Operações de TI

(Operação de Serviço) Atividades realizadas pela TI Controle de Operações, incluindo Management Console, Job Scheduling, Backup e Restauração, e impressão e Gestão de Produção. Operações de TI também é usado como sinônimo de Operação de Serviço.

Serviços de TI

Um serviço prestado a um ou mais clientes por um fornecedor de serviços de TI. Um serviço de TI é baseado no uso de Tecnologia da Informação e Processos de e de negócio do cliente. Um serviço de TI é feita a partir de uma combinação de pessoas, processos e tecnologia e deve ser definido em um Acordo de Nível de Serviço.

Gerenciamento da Continuidade do Serviço

(Desenho de Serviço) O Processo responsável por gerenciar os riscos que poderiam afetar seriamente Serviços de TI. ITSCM garante que o provedor de serviço de TI pode sempre fornecer níveis mínimos de serviço acordado, reduzindo o risco a um nível aceitável e Planejamento de Recuperação de Serviços de TI. ITSCM deve ser projetado para ar Gestão de Continuidade de Negócios.

TI Plano de Continuidade do Serviço

(Desenho de Serviço) Um Plano que define os os necessários para recuperar um ou mais serviços de TI. O Plano também vai identificar os gatilhos para Invocação, pessoas a serem envolvidas, comunicações, etc O Plano de Continuidade de Serviços de TI devem fazer parte de um Plano de Continuidade de Negócios.

IT Service Management

A implementação e gestão da Qualidade de Serviços de TI que atendam as necessidades do negócio. IT Service Management é realizada por serviços de TI através de uma combinação adequada de Tecnologia de pessoas, processos e informação. Ver também Serviço de Gestão de.

Provedor de serviço de TI

(Estratégia de Serviço) Um prestador de serviços que fornece serviços de TI para clientes internos ou clientes externos.

Grupo de Coordenação de TI

Um grupo formal, que é responsável por garantir que as empresas e as estratégias de TI prestadoras de serviços e planos estão alinhados.

ITIL V3 - Service Design - Página:

457 de 477

Um Grupo de Coordenação de TI inclui representantes de alto nível do negócio e do provedor de serviços de TI. ITIL

Um conjunto de orientações de Melhores Práticas para o Gerenciamento de Serviços. ITIL é de propriedade do OGC e consiste de uma série de publicações com orientações sobre a prestação de Qualidade de Serviços de TI, e sobre os processos e instalações necessários para apoiá-los. Veja www.itil.co.uk para mais informações.

Descrição trabalho

Um documento que define os papéis, responsabilidades, habilidades e conhecimentos necessários por uma pessoa em particular. Uma descrição do trabalho pode incluir várias funções, por exemplo, os papéis do Configuration Manager e Change Manager pode ser realizada por uma pessoa.

Job Scheduling

(Operação de Serviço) Planejamento e gerenciamento da execução de tarefas de software que são requeridos como parte de um serviço de TI. Job Scheduling é realizado pela IT Operations Management, e muitas vezes é automatizado usando ferramentas de software que rodam em lote ou tarefas on-line em horários específicos do dia, semana, mês ou ano.

Key Performance Indicator

(Desenho de Serviço) (Melhoria de Serviço Continuada) Uma métrica que é usado para ajudar a gerenciar um processo, serviço ou actividade. Muitas métricas podem ser medidos, mas só o mais importante deles são definidos como KPIs e usado para gerenciar ativamente e informar sobre o processo, serviço ou actividade. KPIs devem ser selecionados para garantir que eficiência, eficácia e custoeficácia são geridos. Veja como Fator de Sucesso também Crítica.

Base de Conhecimento

(Transição de Serviço) Um banco de dados lógico que contém os dados utilizados pelo Sistema de Gerenciamento de Serviços de Conhecimento.

Gestão do Conhecimento

(Transição de Serviço) O Processo responsável pela coleta, análise, armazenamento e compartilhamento de conhecimento e informação dentro de uma organização. O principal objetivo da Gestão do Conhecimento é melhorar a eficiência, reduzindo a necessidade de redescobrir o conhecimento. Veja também Serviço de Sistema de Gestão do Conhecimento.

Erro Conhecido

(Operação de Serviço) Um problema que tem uma causa raiz documentada e uma solução alternativa. Erros Conhecidos são criados e gerenciados durante todo seu ciclo de vida pelo Gerenciamento de Problemas. Erros conhecidos também pode ser identificado por Desenvolvimento ou Fornecedores.

Ciclo de Vida

As várias fases na vida de um Serviço de TI, Item de Configuração, Incidentes, Problemas, Mudanças, etc O ciclo de vida define as categorias para Estado e as transições de estado que são permitidos. Por exemplo: • •

ITIL V3 - Service Design - Página:

458 de 477

O Ciclo de Vida de uma Aplicação inclui Requisitos, projetar, construir, implantar, operar, Otimizar O Ciclo de Vida do Incidente Expandido inclui

•

detectar, responder, Diagnosticar, reparar, recuperar, restaurar O ciclo de vida de um servidor podem incluir: Pedido, recebeu, em teste, vivo, disposto, etc

Linha de Serviço

(Estratégia de Serviço) Um Core Service ou serviço de apoio que tem pacotes de múltiplos níveis de serviço. Uma linha de serviço é gerenciado por um gerente de produto e cada pacote de nível de serviço é projetado para ar um determinado segmento de mercado.

Viver

(Transição de Serviço) Refere-se a um item de serviço ou de configuração de TI que está sendo usado para fornecer serviço a um cliente.

Viver Ambiente

(Transição de Serviço) Um Ambiente controlado contendo itens de configuração ao vivo usados para fornecer serviços de TI para clientes.

Manutenibilidade

(Desenho de Serviço) Uma medida de como o serviço de forma rápida e eficazmente um Item de Configuração ou pode ser restaurado ao funcionamento normal após uma falha. Manutenibilidade é frequentemente medido e relatado como MTRS. Manutenibilidade é também usado no contexto de Software ou IT Development Service para significar capacidade de ser alterado ou reparado facilmente.

Incidente grave

(Operação de Serviço) Categoria mais alto de Impacto de um Incidente. A Principais resultados incidente em perturbação significativa para o negócio.

Serviços Gerenciados

(Estratégia de Serviço) Uma perspectiva em serviços de TI que enfatiza o fato de que eles são geridos. Os Serviços Gerenciados prazo também é usado como sinônimo de serviços de TI terceirizados.

Gestão da Informação

Informações que são usadas para apoiar a tomada de decisão pelos gestores. Gestão da informação é muitas vezes gerado automaticamente por ferramentas que am os diversos processos de Gerenciamento de Serviços. Gestão da Informação, muitas vezes inclui os valores de KPIs como "porcentagem de alterações que levam a incidentes", ou "taxa de correção pela primeira vez".

Gestão de Risco

A metodologia de gerenciamento de riscos OGC. M_o_R inclui todas as atividades necessárias para identificar e controlar a exposição ao risco, o que pode ter um impacto sobre a realização dos objetivos de uma organização de negócios. Veja www.m-o-r.org para mais detalhes.

Sistema de Gestão

O quadro de políticas, processos e funções que garante uma organização pode alcançar seus objetivos.

Solução manual

Uma solução que requer a intervenção manual. Solução manual também é usado como o nome de uma opção de recuperação em que o Business Process Funciona sem o uso de serviços de TI. Esta é uma medida temporária e é normalmente combinada com outra opção de

ITIL V3 - Service Design - Página:

459 de 477

recuperação. Maturidade

(Melhoria de Serviço Continuada) Uma medida da, Organização Função confiabilidade, eficiência e eficácia de um processo, etc Os processos mais maduros e funções são formalmente alinhados aos objetivos de negócio e estratégia, e são apoiados por um quadro de melhoria contínua.

Tempo médio entre falhas

(Desenho de Serviço) Uma Métrica para medir e relatar Confiabilidade. MTBF é o tempo médio que um Item de Configuração ou Serviço de TI pode desempenhar sua função acordada sem interrupção. Este é medido a partir de quando o serviço de CI ou ele começa a trabalhar, até que próximo falhar.

Tempo médio entre Incidentes de Serviço

(Desenho de Serviço) A métrica usada para medir e informar Confiabilidade. TMEIS é o tempo médio de quando um sistema ou serviço de TI falhar, até que próximo falhar. TMEIS é igual ao MTBF + MTRS.

Mean Time To Repair

O tempo médio para reparar um Item de Configuração ou Serviço de TI após uma falha. MTTR é medido a partir de quando o serviço de CI ou falhar até que seja consertado. MTTR não inclui o tempo necessário para recuperar ou restaurar. MTTR é por vezes incorretamente usado para significar tempo médio para restaurar o serviço.

Tempo médio para restaurar o serviço

O tempo médio para restaurar um Item de Configuração ou Serviço de TI após uma falha. MTRS é medido a partir de quando o serviço de CI ou falhar até que seja totalmente restaurado e entregar a sua funcionalidade normal. Veja também Manutenibilidade, Tempo médio para reparo.

Métrico

(Melhoria de Serviço Continuada) Algo que é medido e relatado para ajudar a gerenciar um processo, serviço ou actividade. Veja também KPI.

Middleware

(Desenho de Serviço) O software que conecta duas ou mais componentes de software ou aplicativos. Middleware é geralmente comprado de um Fornecedor, Em vez de desenvolver dentro do IT Provedor de serviços. Veja também fora da prateleira.

Modelo

Uma representação de um sistema, processo, serviços de TI, Item de Configuração, etc, que é usado para ajudar a compreender e prever o comportamento futuro.

Modelagem

Uma técnica que é usada para prever o comportamento futuro de um sistema, processo, serviços de TI, item de configuração, etc Modelagem é comumente usado em Gestão Financeira, Gestão de Capacidade e Gerenciamento da Disponibilidade.

Monitoramento

(Operação de Serviço) a observação repetida de um item de configuração, serviço ou processo para detectar eventos e para garantir que a situação atual é conhecido.

Objetivo

O objetivo definido ou fim de um processo, uma atividade ou de uma Organização como um todo. Os objetivos são geralmente expressa

ITIL V3 - Service Design - Página:

460 de 477

como metas mensuráveis. O Objetivo termo também é usado informalmente para significar uma exigência. Veja também Resultado. Off-the-shelf

Veja Commercial Off-the-shelf.

Office of Government Commerce

OGC é dona da marca ITIL (direitos autorais e marca registrada). OGC é um departamento do Governo do Reino Unido que a a entrega da agenda do governo de aquisições por meio de seu trabalho nos contratos de colaboração e no aumento dos níveis de habilidades e capacidade de aquisição dentro dos departamentos. Ele também fornece e para complexos projetos do setor público.

Off-shore

(Estratégia de Serviço) Provisão de Serviços a partir de um local fora do país onde o cliente baseia-se, muitas vezes em um continente diferente. Esta pode ser a prestação de um serviço de TI, ou de funções de e, como um Service Desk. Veja também on-shore.

Em terra

(Estratégia de Serviço) Provisão de serviços de um local dentro do país, onde o cliente é baseada. Veja também off-shore.

Operar

Para o desempenho esperado. Um processo ou Item de Configuração é dito para operar se está entregando os resultados desejados. Operar também significa executar uma ou mais operações. Por exemplo, para operar um computador é fazer as operações do dia-a-dia necessários para que o desempenho esperado.

Operação

(Operação de Serviço) a gestão do dia-a-dia de um serviço de TI, Sistema ou Item de Configuração outro. Operação também é usada para significar qualquer atividade pré-definido ou transação. Por exemplo carregar uma fita magnética, aceitando dinheiro em um ponto de venda, ou leitura de dados a partir de uma unidade de disco.

Operacional

O mais baixo dos três níveis de Planejamento e de entrega (Estratégico, Tático, Operacional). Atividades operacionais incluem o dia-a-dia de Planejamento ou de curto prazo ou entrega de um processo de negócio ou de TI Processo de Gestão de Serviço. O termo operacional é também um sinônimo para Live.

Custo Operacional

Custo resultante da execução dos serviços de TI. Muitas vezes, repetindo pagamentos. Por exemplo os custos de pessoal, manutenção de hardware e eletricidade (também conhecido como "despesas correntes" ou "despesas receitas»).

Acordo de Nível Operacional

(Desenho de Serviço) (Melhoria de Serviço Continuada) um acordo entre um provedor de serviço de TI e outra parte da mesma organização. Um OLA a a entrega do provedor de serviço de TI, serviços de TI para clientes. O OLA define os bens ou serviços a serem prestados e as responsabilidades de ambas as partes. Por exemplo, poderia haver um OLA: • •

ITIL V3 - Service Design - Página:

461 de 477

Entre o prestador de serviço de TI e um departamento de compras para obter hardware em tempos acordados Entre o Service Desk e um grupo de apoio para fornecer a resolução de incidentes em

tempos acordados. Ver também Acordo de Nível de Serviço. Otimizar

Plano de Revisão e solicitar alterações, a fim de obter a máxima eficiência e eficácia de um processo, item de configuração, aplicação, etc

Organização

A empresa, pessoa jurídica ou outra instituição. Exemplos de organizações que não são empresas incluem International Standards Organization ou itSMF. A Organização termo é por vezes utilizado para se referir a qualquer entidade que tenha pessoas, recursos e orçamentos. Por exemplo, um projeto ou unidade de negócios.

Resultado

O resultado do exercício de uma actividade, na sequência de um processo; entregar um serviço de TI, etc O Resultado termo é usado para se referir a resultados pretendidos, bem como os resultados reais. Veja também Objetivo.

Terceirização

(Estratégia de Serviço) Utilizando um prestador de serviços externo para gerenciar serviços de TI.

Despesas gerais

Veja custo indireto.

Parceria

A relação entre duas organizações que envolve o trabalho em conjunto de objetivos comuns ou benefício mútuo. O prestador de serviços de TI deve ter uma parceria com a empresa, e com terceiros, que são críticos para a entrega de serviços de TI. Ver também Rede de Valor.

Monitoramento ivo

(Operação de Serviço) O monitoramento de um item de configuração, um serviço de TI ou de um processo que depende de um alerta ou notificação para descobrir o status atual.

Padrão de Atividade de Negócios

(Estratégia de Serviço) Um perfil de carga de trabalho de uma ou mais atividades empresariais. Padrões de atividade de negócio são usados para ajudar o prestador de serviço de TI compreender e planejar para os diferentes níveis de atividade comercial.

Atuação

Uma medida que é alcançado ou entregue por um sistema, pessoa, equipe, Processo, ou Serviço de TI.

Gestão de Desempenho

(Melhoria de Serviço Continuada) O Processo responsável pelo dia-adia de gerenciamento de capacidade. Estes incluem monitoramento, limiar de detecção, análise e ajuste de desempenho e alterações de execução relativas ao desempenho e capacidade.

Piloto

(Transição de Serviço) Implantação A limitada de um Serviço de TI, um lançamento ou um processo para o ambiente ao vivo. Um piloto é usado para reduzir o risco e para obter do usuário e aceitação. Veja também Avaliação de Testes.

Plano

Uma proposta detalhada que descreve as atividades e recursos necessários para atingir um objetivo. Por exemplo, um plano para implementar um novo serviço de TI ou processo. ISO / IEC 20000 requer um plano de gestão de cada um Processo de Gestão de Serviços de TI.

ITIL V3 - Service Design - Página:

462 de 477

Plan-Do-Check-Act

(Melhoria de Serviço Continuada) Um ciclo de quatro fases para a gestão de processos, atribuída a Edward Deming. Plan-Do-Check-Act também é chamado de Ciclo de Deming. PLANO: Desenho ou revisar processos que am os serviços de TI. DO: Implementar o Plano e gerenciar os processos. VERIFICAÇÃO: medir os processos e serviços de TI, compare com objetivos e produzir relatórios. ACT: Planejar e implementar mudanças para melhorar os processos.

Tempo de inatividade planejado

(Desenho de Serviço) Acordado momento em que um serviço de TI não estará disponível. Tempo de inatividade planejado é frequentemente usado para manutenção, atualizações e testes. Veja também Alterar Janela, O tempo de inatividade.

Planejamento

Uma Atividade responsável pela criação de um ou mais planos. Por exemplo, planejamento de capacidade.

PMBOK

Um padrão de gerenciamento do Projeto mantida e publicada pelo Project Management Institute. PMBOK significa Corpo de Gerenciamento de Projetos do Conhecimento. Veja www.pmi.org para mais informações. Veja também PRINCE2.

Política

Formalmente documentado expectativas da istração e intenções. Políticas são usados para decisões diretas, e para garantir o desenvolvimento coerente e adequado e implementação de processos, padrões, papéis, atividades, infra-estrutura de TI, etc

Facilidade portátil

(Desenho de Serviço) Um edifício pré-fabricado, ou um veículo de grande porte, fornecido por um terceiro e se mudou para um local quando necessário por um Plano de Continuidade de Serviço de TI. Veja também opção de recuperação.

Pós-Implementação comentário

Uma revisão que ocorre depois de uma mudança ou um projeto foi implementado. A PIR determina se a alteração ou projeto foi bem sucedido, e identifica oportunidades de melhoria.

Prática

A maneira de trabalhar, ou uma maneira em que o trabalho deve ser feito. Práticas podem incluir atividades, processos, funções, normas e orientações. Veja também Best Practice.

Pré-requisito para o sucesso

Uma atividade que precisa ser concluída, ou uma condição que precisa ser cumprida, para permitir a implementação bem sucedida de um Plano ou processo. A PFS é frequentemente uma saída de um processo que é uma entrada necessária para outro processo.

Preços

(Estratégia de Serviço) A Atividade para estabelecer o quanto os clientes serão cobrados.

PRINCE2

O padrão Reino Unido metodologia de governo para a gestão do projeto. Veja www.ogc.gov.uk/prince2 para mais informações. Veja

ITIL V3 - Service Design - Página:

463 de 477

também PMBOK. Prioridade

(Transição de Serviço) (Operação de Serviço) Uma Categoria usada para identificar a importância relativa de um incidente, problema ou mudança. Prioridade é baseada em impacto e urgência, e é usado para identificar os tempos necessários para as ações a serem tomadas. Por exemplo, a SLA pode-se afirmar que a prioridade de dois incidentes devem ser resolvidos dentro de 12 horas.

Problema

(Operação de Serviço) Uma causa de um ou mais incidentes. A causa geralmente não é conhecido no momento um registro de problema é criado, eo processo de Gerenciamento de Problema é responsável por uma investigação mais aprofundada.

Gerenciamento de Problemas

(Operação de Serviço) O Processo responsável por gerenciar o ciclo de vida de todos os problemas. Os principais objetivos do Gerenciamento de Problemas são para evitar incidentes de acontecer, e para minimizar o impacto dos incidentes que não podem ser evitados.

Procedimento

Um documento contendo os os que especificam como realizar uma atividade. Procedimentos são definidos como parte de Processos. Ver também Instrução de Trabalho.

Processo

Um conjunto estruturado de atividades destinadas a alcançar um objetivo específico. Um processo leva uma ou mais entradas definidas e as transforma em saídas definidas. Um processo pode incluir qualquer um dos papéis, responsabilidades, ferramentas e gestão de controlos necessários para entregar de forma confiável as saídas. Um processo pode definir políticas, normas, orientações, atividades e Instruções de Trabalho, se eles são necessários.

Controle de Processo

A atividade de planejamento e regulação de um processo, com o objetivo de realizar o processo de forma eficaz, eficiente e consistente.

Proprietário do Processo

Um papel responsável por garantir que um processo está apto para o efeito. As responsabilidades do proprietário do processo incluem patrocínio, Design, Gestão de Mudança e melhoria contínua do processo e suas métricas. Este papel é muitas vezes atribuída a mesma pessoa que exerce a função de Gerente de Processo, mas as duas funções pode ser separado em organizações maiores.

Proforma

Um documento de modelo, ou exemplo contendo dados de exemplo que serão substituídos pelos valores reais quando estes estão disponíveis.

Programa

Uma série de projetos e atividades que são planejadas e gerenciadas em conjunto para alcançar um conjunto global de objectivos relacionados e outros resultados.

Projeto

A Organização temporária, com pessoas e outros Ativos necessários para atingir um resultado objetivo ou outro. Cada projeto tem um ciclo de vida que normalmente inclui iniciação, planejamento, execução, encerramento, projetos etc geralmente são gerenciados usando uma metodologia formal, como PRINCE2.

ITIL V3 - Service Design - Página:

464 de 477

Qualidade

A capacidade de um produto, serviço ou processo para fornecer o valor pretendido. Por exemplo, um componente de hardware pode ser considerado de elevada qualidade, se o desempenho esperado e oferece a confiabilidade necessária. Qualidade processo também exige uma capacidade de monitorar a eficácia e eficiência, e para melhorá-los, se necessário. Veja também Sistema de Gestão da Qualidade.

Sistema de Gestão da Qualidade

(Melhoria de Serviço Continuada) O conjunto de processos responsáveis por garantir que todo o trabalho realizado por uma organização é de qualidade adequada para atender de forma confiável Objetivos de negócios ou Nível de serviços. Veja também ISO 9000.

RACI

(Desenho de Serviço) (Melhoria de Serviço Continuada) Um modelo usado para ajudar a definir papéis e responsabilidades. RACI significa Responsável, responsável, consultado e informado.

Acordo de reciprocidade

(Desenho de Serviço) uma opção de recuperação. Um acordo entre duas organizações para compartilhar recursos em uma emergência. Por exemplo, o espaço Sala de Informática ou o uso de um mainframe.

Registro

Um documento contendo os resultados ou outra saída a partir de um processo ou atividade. Os registros são a prova de que uma atividade ocorreu e pode ser papel ou eletrônico. Por exemplo, um relatório de auditoria, um registro de incidentes, ou as atas de uma reunião.

Recuperação

(Desenho de Serviço) (Operação de Serviço) Retornar um Item de Configuração ou um Serviço de TI para um estado de funcionamento. Recuperação de um serviço de TI, muitas vezes inclui a recuperação de dados em um estado conhecido consistente. Após a recuperação, medidas adicionais podem ser necessárias antes de o serviço que pode ser disponibilizado para os Usuários (Restauração).

Opção de recuperação

(Desenho de Serviço) Uma estratégia para responder a uma interrupção de serviço. Estratégias comumente usados são não fazer nada, solução manual, acordo de reciprocidade, recuperação gradual, recuperação intermediária, rápida recuperação, recuperação imediata. Opções de recuperação podem fazer uso de instalações específicas ou instalações de terceiros compartilhados por várias empresas.

Redundância

Veja tolerância a falhas. O termo redundante também tem um significado genérico de obsoleto, ou deixaram de ser necessários.

Relação

Uma conexão ou interação entre duas pessoas ou coisas. Em Gestão de Relacionamento de Negócios é a interação entre o prestador de serviço de TI e de Negócios. Em Gerenciamento de Configuração, é um elo entre dois itens de configuração que identifica uma dependência ou conexão entre eles. Por exemplo candidaturas podem ser ligados aos servidores são executadas. Serviços de TI tem muitos links para todos os itens de configuração que contribuam com eles.

Processos de Relacionamento

A ISO / IEC 20000 Processo de grupo que inclui Gestão de Negócios e Gestão de Relacionamento Fornecedor.

ITIL V3 - Service Design - Página:

465 de 477

Solte

(Transição de Serviço) Uma coleção de hardware, software, documentação, processos ou outros componentes necessários para implementar uma ou mais aprovou alterações aos serviços de TI. O conteúdo de cada lançamento são geridos, testado e implantado como uma única entidade.

Gerenciamento de Liberação e Implantação

(Transição de Serviço) O Processo responsável tanto Gerenciamento de Liberação e Implantação.

Gerenciamento de Liberação

(Transição de Serviço) O Processo responsável por planejar, programar e controlar o movimento de lançamentos para testar e Live Ambientes. O objetivo primário do Gerenciamento de Liberação é garantir que a integridade do ambiente vivo está protegido e que os componentes corretos são liberados. Gerenciamento de Liberação é parte do lançamento e Processo de Gestão de Implantação.

Registro de Lançamento

(Transição de Serviço) A Record no CMDB que define o conteúdo de um comunicado. A Record Lançamento tem relações com todos os itens de configuração que são afectados pela libertação.

Confiança

(Desenho de Serviço) (Melhoria de Serviço Continuada) Uma medida de quanto tempo um item de configuração ou serviço de TI pode desempenhar sua função acordada sem interrupção. Normalmente medida como MTBF ou TMEIS. A Confiabilidade termo também pode ser usado para indicar como provável é que um processo, função, etc vai entregar suas saídas exigidas. Veja também disponibilidade.

Reparar

(Operação de Serviço) A substituição ou correção de um item de configuração falhou.

Requisição de Mudança

(Transição de Serviço) Uma proposta formal de alteração a ser feita. Uma RFC inclui detalhes da mudança proposta, e pode ser registrada em papel ou eletronicamente. O RFC termo é freqüentemente mal utilizada para significar um registro de mudança, ou a mudança em si.

Cumprimento de Requisição

(Operação de Serviço) O Processo responsável por gerenciar o ciclo de vida de todas as solicitações de serviço.

Exigência

(Desenho de Serviço) Uma declaração formal de que é necessário. Por exemplo, um requisito de nível de serviço, uma exigência do projeto ou das entregas necessárias para um processo. Ver também Declaração de requisitos.

Resiliência

(Desenho de Serviço) A capacidade de um item de configuração ou serviço de TI para resistir à falha ou recuperar rapidamente após uma falha. Por exemplo, um cabo blindado irá resistir falha quando colocado sob estresse. Veja também tolerância a falhas.

Resolução

(Operação de Serviço) Ação tomada para reparar a causa raiz de um incidente ou problema, ou para implementar uma solução alternativa. Na norma ISO / IEC 20000, os processos de resolução é o grupo que inclui Processo de Incidentes e Gestão de Problemas.

Recurso

(Estratégia de Serviço) Um termo genérico que inclui infraestrutura de TI, pessoas, dinheiro ou qualquer outra coisa que possa ajudar a

ITIL V3 - Service Design - Página:

466 de 477

proporcionar um serviço de TI. Os recursos são considerados ativos de uma organização. Veja também a capacidade, Serviço de ativos. Tempo de Resposta

Uma medida do tempo necessário para completar uma operação ou transação. Usado em Gerenciamento da Capacidade como uma medida do desempenho de TI Infra-estrutura, e em Gerenciamento de Incidentes como uma medida do tempo necessário para atender o telefone, ou para iniciar Diagnóstico.

Capacidade de resposta

A medição do tempo necessário para responder a qualquer coisa. Este poderia ser tempo de resposta de uma transação, ou a velocidade com que um fornecedor de serviços de TI responde a um incidente ou solicitação de mudança, etc

Restauração de Serviço

Veja Restaurar.

Restaurar

(Operação de Serviço) Tomar medidas para devolver um serviço de TI aos Usuários após reparação e recuperação de um incidente. Este é o principal objetivo do Gerenciamento de Incidentes.

Aposentar

(Transição de Serviço) a remoção permanente de um serviço de TI ou Item de Configuração outro, do ambiente ao vivo. Aposentado é uma fase do ciclo de vida de muitos itens de configuração.

Retorno sobre Investimento

(Estratégia de Serviço) (Melhoria de Serviço Continuada) Uma medida do benefício esperado de um investimento. No sentido mais simples é o lucro líquido de um investimento dividido pelo patrimônio líquido dos ativos investidos.

Retornar para Normal

(Desenho de Serviço) A fase de um Plano de Continuidade dos Serviços de completos durante o qual as operações normais são retomadas. Por exemplo, se um centro de dados alternativo está em uso, então essa fase vai trazer o centro de dados primário de volta em operação, e restaurar a capacidade de invocar TI Continuidade do Serviço de planos novamente.

Comente

A avaliação de uma Mudança, Problema, Processo, Project, etc Comentários são normalmente realizadas em pontos pré-definidos no Ciclo de Vida e, especialmente, após o encerramento. O propósito de um comentário é garantir que todos os resultados foram fornecidos, e identificar oportunidades de melhoria. Veja também Revisão pósimplementação.

Direitos

(Operação de Serviço) direitos ou permissões, concedidas a um usuário ou função. Por exemplo, o direito de modificar os dados particulares, ou autorizar uma mudança.

Risco

Um evento possível que possa causar danos ou perda, ou afetar a capacidade de alcançar os objetivos. Um risco é medido pela probabilidade de uma ameaça, a vulnerabilidade do Activo a essa ameaça, e do impacto que teria se ele ocorreu.

Avaliação de Risco

Os os iniciais da gestão de risco. Analisando o valor dos ativos para o negócio, identificando ameaças a esses ativos, e avaliar como cada ativo é vulnerável a essas ameaças. Avaliação de Risco pode ser

ITIL V3 - Service Design - Página:

467 de 477

quantitativa (com base em dados numéricos) ou qualitativa. Gestão de risco

O Processo responsável pela identificação, avaliação e controle de riscos. Veja também Avaliação de Risco.

Papel

Um conjunto de responsabilidades, atividades e autoridades concedidas a uma pessoa ou equipe. Um papel é definido em um processo. Uma pessoa ou equipe pode ter várias funções, por exemplo, os papéis do Configuration Manager e Change Manager pode ser realizada por uma única pessoa.

Causa raiz

(Operação de Serviço) A causa subjacente ou original de um incidente ou problema.

Custos de funcionamento

Veja Custo Operacional.

Escalabilidade

A capacidade de um Serviço de TI, Processo, Item de Configuração, etc, para executar sua função acordada quando as mudanças de carga de trabalho ou de escopo.

Escopo

O limite, ou extensão, para que um processo, procedimento contrato de certificação, etc se aplica. Por exemplo, o escopo de Gerenciamento de Mudança pode incluir todos ao vivo Serviços de TI e itens de configuração relacionados, o escopo de uma norma ISO / IEC 20000 Certificado pode incluir todos os serviços de TI entregues fora de um centro de dados chamado.

Segurança

Consulte Informações Gestão de Segurança.

Gestão de Segurança

Consulte Informações Gestão de Segurança.

Política de segurança

Consulte Informações Política de Segurança.

Separação de preocupações

(Estratégia de Serviço) Uma abordagem para a criação de uma solução ou serviço de TI que divide o problema em partes que podem ser resolvidos de forma independente. Essa abordagem separa "o que" está a ser feito a partir de "como" é para ser feito.

Servidor

(Operação de Serviço) Um computador que esteja conectado a uma rede e fornece funções de software que são utilizados por outros computadores.

Serviço

Um meio de entregar valor aos clientes, facilitando Resultados clientes querem alcançar, sem a posse de Custos e riscos específicos.

Critérios de aceitação de serviços

(Transição de Serviço) Um conjunto de critérios utilizados para garantir que um serviço de TI cumpre a sua funcionalidade e requisitos de qualidade e que o provedor de serviço de TI está pronta para operar o serviço de TI novo quando foi implantado. Veja também Aceitação.

Serviço de ativos

Qualquer capacidade ou recurso de um Provedor de serviços. Veja também Ativos.

Gerenciamento da Capacidade de serviço

(Desenho de Serviço) (Melhoria de Serviço Continuada) A Atividade responsável por entender o desempenho ea capacidade de serviços de TI. Os recursos usados por cada Serviço de TI e o padrão de uso

ITIL V3 - Service Design - Página:

468 de 477

ao longo do tempo são coletados, registrados e analisados para uso no Plano de Capacidade. Veja também Negócios Capacidade, Gerenciamento de Capacidade de componentes. Catálogo de Serviços

(Desenho de Serviço) Um banco de dados de documentos ou estruturado com informações sobre todos os serviços de TI ao vivo, incluindo os disponíveis para a implantação. O Catálogo de Serviços é a única parte do portfólio de serviços publicado aos Clientes, e é usado para apoiar a venda e entrega de serviços de TI. O Catálogo de Serviço inclui informações sobre entregas, preços, pontos de o, ordenação e processos de solicitação.

Gestão da Continuidade do Serviço

Veja TI Gestão da Continuidade do Serviço.

Cultura de serviço

Uma cultura orientada ao cliente. Os principais objectivos de uma cultura de serviço são a satisfação do cliente e ajudando os clientes a atingir seus objetivos de negócios.

Design de Serviços

(Desenho de Serviço) Uma fase no Ciclo de Vida de um Serviço de TI. Design de Serviços inclui uma série de processos e funções e é o título de um dos ITIL Núcleo publicações. Veja também Design.

Pacote de Desenho de Serviço

(Desenho de Serviço) documento (s) a definição de todos os aspectos de um serviço de TI e seus requisitos através de cada estágio de seu ciclo de vida. Um Pacote de Desenho de Serviço é produzido para cada Serviço de TI novo, grande mudança, ou TI Aposentadoria Serviço.

Service Desk

(Operação de Serviço) O ponto único de contato entre o prestador de serviços e os usuários. Uma Central de Serviços típico gerencia incidentes e solicitações de serviços, e também lida com a comunicação com os usuários.

Análise de falha de serviço

(Desenho de Serviço) Uma Atividade que identifica as causas subjacentes de uma ou mais interrupções do serviço de TI. SFA identifica oportunidades para melhorar os processos de o prestador de serviços de TI e ferramentas, e não apenas a infraestrutura de TI. SFA é um tempo limitado, a atividade de projeto semelhante, em vez de um processo contínuo de análise.

Horas de serviço

(Desenho de Serviço) (Melhoria de Serviço Continuada) Um período de tempo acordado quando um determinado serviço de TI deve estar disponível. Por exemplo, 'Segunda-feira a Sexta-feira 8:00-17:00, exceto feriados. Horas de serviço devem ser definidos em um Acordo de Nível de Serviço.

Plano de Melhoria de Serviço

(Melhoria de Serviço Continuada) um plano formal para implementar melhorias a um processo ou serviço de TI.

Serviço do Sistema de Gestão do Conhecimento

(Transição de Serviço) Um conjunto de ferramentas e bases de dados que são usados para gerenciar conhecimento e informação. Os SKMS inclui o Sistema de Gerenciamento de Configuração, bem como outras ferramentas e bancos de dados. O lojas SKMS, gerencia as atualizações, e apresenta todas as informações de que um provedor

ITIL V3 - Service Design - Página:

469 de 477

de serviço de TI precisa gerenciar o ciclo de vida completo de serviços de TI. Nível de serviço

Medido e relatado conquista contra um ou mais objetivos de nível de serviço. O nível de serviço termo é por vezes usado informalmente para significar objetivo de nível de serviço.

Acordo de Nível de Serviço

(Desenho de Serviço) (Melhoria de Serviço Continuada) um acordo entre um provedor de serviços de TI e um Cliente. O SLA descreve o serviço de TI, objetivos de nível de documentos de serviço, e especifica as responsabilidades do fornecedor de serviços de TI eo cliente. Uma única SLA pode abranger vários serviços de TI ou clientes múltiplos. Veja Acordo de Nível Operacional também.

Gerenciamento de Nível de Serviço

(Desenho de Serviço) (Melhoria de Serviço Continuada) O Processo responsável por negociar Acordos de Nível de Serviço, e garantir que estes sejam cumpridos. SLM é responsável por garantir que todos os processos de TI Service Management, Acordos de Nível Operacional e Contratos de Apoio, são adequadas para os objetivos de nível de serviço acordado. SLM monitores e relatórios sobre os níveis de serviço, e mantém Opiniões regulares.

Pacote de Nível de Serviço

(Estratégia de Serviço) Um nível definido de Utilidade e Garantia para um pacote de serviços específico. Cada SLP é projetado para atender as necessidades de um padrão particular de atividade empresarial. Veja também Linha de Serviço.

Exigência de Nível de Serviço

(Desenho de Serviço) (Melhoria de Serviço Continuada) uma exigência do cliente para um aspecto de um Serviço de TI. SLRs são baseados em objetivos de negócios e são usados para negociar objetivos de nível de serviço acordado.

Meta de nível de serviço

(Desenho de Serviço) (Melhoria de Serviço Continuada) Um compromisso que é documentado em um Acordo de Nível de Serviço. Metas de nível de serviço são baseados em Requisitos de Nível de Serviço, e são necessárias para garantir que o Design de Serviços de TI está apto para o efeito. Metas de nível de serviço devem ser SMART, e normalmente são baseados em KPIs.

Serviço de Gestão de

Service Management é um conjunto de capacidades especializadas organizacionais para o valor aos clientes na forma de serviços.

Serviço de Gestão de ciclo de vida

Uma abordagem para IT Service Management, que enfatiza a importância da coordenação e controle em diversas funções, processos e sistemas necessários para gerenciar o ciclo de vida de serviços de TI. O Serviço de Gerenciamento abordagem de ciclo de vida considera que a estratégia, projeto, transição, operação e melhoria contínua dos serviços de TI.

Service Manager

Um gestor que é responsável por gerenciar o ciclo de vida de ponta a ponta de um ou mais serviços de TI. O Gerenciador de Serviços termo também é usado para significar qualquer gestor dentro do provedor de serviço de TI. Mais comumente usado para se referir a um Gerente de Relacionamento de Negócios, Gerente de Processos, Gerente de Contas ou um gerente sênior com a responsabilidade de Serviços de TI em geral.

ITIL V3 - Service Design - Página:

470 de 477

Operação de Serviço

(Operação de Serviço) Uma fase no Ciclo de Vida de um Serviço de TI. Operação de Serviço inclui uma série de processos e funções e é o título de um dos ITIL Núcleo publicações. Veja também Operação.

Proprietário do serviço

(Melhoria de Serviço Continuada) um papel que é responsável pela entrega de um serviço de TI específica.

Portfólio de Serviços

(Estratégia de Serviço) O conjunto completo de serviços que são gerenciados por um provedor de serviço. O portfólio de serviços é usado para gerenciar o ciclo de vida de todos os Serviços, e inclui três categorias: Serviço de Pipeline (proposto ou em desenvolvimento); Catálogo de Serviço (Live ou disponíveis para implantação) e Serviços de aposentados. Ver também Gestão de Portfólio de Serviços.

Gestão de Portfólio de Serviços

(Estratégia de Serviço) O Processo responsável por gerenciar o portfólio de serviços. Gestão de Portfólio de Serviço considera Serviços em termos de valor de negócios que eles proporcionam.

Provedor de serviços

(Estratégia de Serviço) Uma Organização prestação de serviços a um ou mais clientes internos ou clientes externos. Prestador de serviço é muitas vezes usada como uma abreviação para a TI do provedor de serviço.

Serviço de relatório

(Melhoria de Serviço Continuada) O Processo responsável pela produção e entrega de relatórios de desempenho e as tendências em relação aos níveis de serviço. Relatórios de serviço deve concordar o formato, conteúdo e frequência dos relatórios com os Clientes.

Solicitação de serviço

(Operação de Serviço) Um pedido de um usuário para obter informações ou conselhos, ou para uma mudança de padrão ou de o a um serviço de TI. Por exemplo, para redefinir uma senha, ou a prestação de serviços de TI padrão para um novo usuário. Solicitações de serviços são geralmente tratado por um Service Desk, e não necessitam de uma RFC para ser apresentado. Veja também Pedir Cumprimento.

Estratégia de Serviço

(Estratégia de Serviço) O título de um dos ITIL Núcleo publicações. Estratégia de serviço estabelece uma estratégia global de serviços de TI e de IT Service Management.

Transição de Serviço

(Transição de Serviço) Uma fase no Ciclo de Vida de um Serviço de TI. Transição de Serviço inclui uma série de processos e funções e é o título de um dos ITIL Núcleo publicações. Ver também Transição.

Garantia de serviço

(Estratégia de Serviço) Garantia de que um serviço de TI irá atender aos requisitos acordados. Este pode ser um acordo formal, como um Acordo de Nível de Serviço ou Contrato, ou pode ser uma mensagem de marketing ou imagem de marca. O valor de negócio de um Serviço de TI é criado pela combinação de Service Utility (o que o serviço faz) e garantia de serviço (como ele faz isso). Ver também Garantia.

Manutenção

(Desenho de Serviço) (Melhoria de Serviço Continuada) A capacidade de um terceiro fornecedor de cumprir os termos de seu contrato. Este Contrato incluirá os níveis acordados de Confiabilidade Sustentabilidade, ou disponibilidade para um item de configuração.

ITIL V3 - Service Design - Página:

471 de 477

Deslocar

(Operação de Serviço) Um grupo ou equipe de pessoas que realizam uma função específica, por um período fixo de tempo. Por exemplo, poderia haver quatro turnos de Operações de TI controle de pessoal para ar um serviço de TI que é usado 24 horas por dia.

Modelagem, simulação

(Desenho de Serviço) (Melhoria de Serviço Continuada) Uma técnica que cria um modelo detalhado para prever o comportamento de um item de configuração ou serviço de TI. Modelos de simulação podem ser muito precisos, mas são caro e demorado para criar. Um modelo de simulação é muitas vezes criado usando os itens de configuração reais que estão sendo modelados, com cargas de trabalho artificiais ou transações. Eles são usados em Gestão de Capacidade quando resultados precisos são importantes. Um modelo de simulação é às vezes chamado de Referência de Desempenho.

Ponto único de falha

(Desenho de Serviço) qualquer item de configuração que pode causar um incidente quando falha, e para os quais uma contramedida não foi implementado. A SPOF pode ser uma pessoa, ou um o em um processo ou atividade, bem como um componente da infra-estrutura de TI. Veja também falha.

A SMART

(Desenho de Serviço) (Melhoria de Serviço Continuada) Um acrônimo para ajudar a lembrar que os objectivos em Acordos de Nível de Serviço e Planos de projeto devem ser específicos, mensuráveis, atingíveis, relevantes e oportunas.

Especificação

Uma definição formal de Requisitos. A especificação pode ser usada para definir os requisitos técnicos e operacionais, e pode ser interna ou externa. Muitas normas públicas consistem de um Código de Prática e uma Especificação. A especificação define o padrão contra o qual uma organização pode ser auditado.

Stakeholder

Todas as pessoas que têm interesse em uma Organização do Projeto, Serviços de TI, etc Stakeholders pode estar interessado nas atividades, metas, recursos, ou entregas. As partes interessadas podem incluir clientes, parceiros, funcionários, acionistas, proprietários, etc Veja também RACI.

Padrão

Um requisito obrigatório. Exemplos incluem ISO / IEC 20000 (um padrão internacional), um padrão de segurança interna para a configuração do Unix, ou um padrão do governo para saber como registros financeiros devem ser mantidos. O Standard termo também é usado para se referir a um Código de Prática ou Especificação publicado por uma organização de padrões como ISO ou BSI. Veja também orientação.

Espera

(Desenho de Serviço) Usado para se referir a recursos que não são necessários para entregar os serviços de TI ao vivo, mas estão disponíveis para apoiar TI Planos de Continuidade de Serviço. Por exemplo, um centro de dados de espera pode ser mantido para apoiar Hot Standby, espera aquecido ou frio arranjos de espera.

Declaração de requisitos

(Desenho de Serviço) Um documento contendo todas as exigências para a compra do produto, ou um novo ou alterado Serviço de TI. Ver também Termos de referência.

ITIL V3 - Service Design - Página:

472 de 477

Estado

O nome de um campo obrigatório em muitos tipos de Record. Ele mostra o estágio atual do ciclo de vida do item de configuração associado, incidentes, problemas, etc

Estratégico

(Estratégia de Serviço) O mais alto dos três níveis de Planejamento e de entrega (Estratégico, Tático, Operacional). Atividades Estratégicas incluem definição de objetivo e planejamento de longo prazo para alcançar a visão global.

Estratégia

(Estratégia de Serviço) Um Plano Estratégico concebido para alcançar objetivos definidos.

Fornecedor

(Estratégia de Serviço) (Desenho de Serviço) um terceiro responsável pelo fornecimento de bens ou serviços que são necessários para entregar serviços de TI. Exemplos de fornecedores incluem hardware commodity e fornecedores de software, rede e provedores de telecomunicações e Organizações de terceirização. Ver também Subjacente Contrato,Cadeia de suprimentos.

Fornecedor e Banco de Dados Contrato

(Desenho de Serviço) Um banco de dados de documentos ou estruturado usado para gerenciar contratos de fornecedores ao longo do seu ciclo de vida. O SCD contém atributos-chave de todos os contratos com fornecedores, e devem fazer parte do Sistema de Gerenciamento de Serviços de Conhecimento.

Gestão de Fornecedores

(Desenho de Serviço) O Processo responsável por garantir que todos os contratos com fornecedores de ar as necessidades do negócio, e que todos os fornecedores cumpram os seus compromissos contratuais.

Cadeia de suprimentos

(Estratégia de Serviço) As Atividades em uma Cadeia de Valor realizado por Fornecedores. Uma cadeia de suprimentos normalmente envolve vários fornecedores, cada um agregando valor ao produto ou serviço. Ver também Rede de Valor.

Grupo de apoio

(Operação de Serviço) Um grupo de pessoas com habilidades técnicas. Os grupos de apoio fornecer o apoio técnico necessário a todos os Processos de Gestão de Serviços de TI. Ver também Gestão técnica.

Horas de e

(Desenho de Serviço) (Operação de Serviço) Os tempos ou horas, quando o apoio está disponível para os usuários. Normalmente estas são as horas em que o Service Desk está disponível. Horas de e devem ser definidos em um Acordo de Nível de Serviço, e pode ser diferente da hora de serviço. Por exemplo, as horas de serviço pode ser de 24 horas por dia, mas as horas de e podem ser 7:0019:00.

Serviços de apoio

(Estratégia de Serviço) um serviço que permite ou melhora um serviço essencial. Por exemplo, um serviço de diretório ou um serviço de backup.

A análise SWOT

(Melhoria de Serviço Continuada) Uma técnica que analisa e analisa os pontos fortes e fraquezas internas de uma organização e as oportunidades e ameaças externas que enfrenta SWOT significa Forças, Fraquezas, Oportunidades e Ameaças.

ITIL V3 - Service Design - Página:

473 de 477

Sistema

Uma série de coisas relacionadas que trabalham em conjunto para alcançar um objetivo global. Por exemplo: • •

•

Um sistema de computador, incluindo hardware, software e aplicativos Um sistema de gestão, incluindo vários processos que são planejados e gerenciados em conjunto. Por exemplo, um Sistema de Gestão da Qualidade Um Sistema de Gerenciamento de Banco de Dados ou Sistema Operacional que inclui módulos de software que são projetados para realizar um conjunto de funções relacionadas.

Sistema de Gestão de

A parte da IT Service Management que se concentra na gestão de infraestrutura de TI ao invés de processo.

Tático

O meio de três níveis de Planejamento e de entrega (Estratégico, Tático, Operacional). Atividades táticas incluem os planos de médio prazo necessários para atingir objetivos específicos, normalmente durante um período de semanas a meses.

Gestão técnica

(Operação de Serviço) A Função responsável por fornecer competências técnicas de apoio de serviços de TI e gestão da infraestrutura de TI. Gestão técnica define os papéis dos grupos de apoio, bem como as ferramentas, processos e procedimentos necessários.

Serviço técnico

Veja Serviço de Infra-estrutura.

e técnico

Ver Gestão técnica.

Termos de referência

(Desenho de Serviço) Um documento especificando os requisitos, escopo, entregas, Recursos e cronograma para um projeto ou atividade.

Teste

(Transição de Serviço) Uma Atividade que verifica se um item de configuração, serviço, processo, etc cumpre a sua Especificação Requisitos ou acordado. Veja também Aceitação.

Terceiro

Uma pessoa, grupo ou empresa que não faz parte do Acordo de Nível de Serviço para um serviço de TI, mas é necessário para garantir a entrega bem sucedida do Serviço de TI. Por exemplo, um fornecedor de software, uma empresa de manutenção de hardware, ou um departamento de instalações. Requisitos para terceiros são normalmente especificada na sustentação Contratos ou Acordos de Nível Operacional.

Terceira linha de apoio

(Operação de Serviço) O terceiro nível em uma hierarquia de grupos de apoio envolvidos na resolução de incidentes e investigação de problemas. Cada nível contém habilidades mais especializadas, ou tem mais tempo ou outros recursos.

Ameaça

Qualquer coisa que possa explorar uma vulnerabilidade. Qualquer causa potencial de um incidente pode ser considerado uma ameaça. Por exemplo, um incêndio é uma ameaça que pode explorar a

ITIL V3 - Service Design - Página:

474 de 477

vulnerabilidade de revestimentos inflamáveis. Este termo é comumente usado em Gestão de Segurança da Informação e Gerenciamento de Continuidade do Serviço, mas também se aplica a outras áreas, como Problema e Gerenciamento de Disponibilidade. Limiar

O valor de uma métrica que deve causar um alerta a ser gerado, ou de gestão a adoptar. Por exemplo "Incidente Prioridade 1 não resolvido em quatro horas", "mais de cinco erros de disco moles em uma hora", ou "mais de 10 mudanças não em um mês.

Vazão

(Desenho de Serviço) Uma medida do número de transações, ou outras operações, realizadas em um tempo fixo. Por exemplo, 5.000 emails enviados por hora, ou 200 de disco I / Os por segundo.

Custo Total de Propriedade

(Estratégia de Serviço) Uma metodologia usada para ajudar a tomar decisões de investimento. TCO avalia o Custo do Ciclo de Vida cheia de possuir um item de configuração, não apenas o custo inicial ou preço de compra.

Transação

Uma função discreta realizada por um serviço de TI. Por exemplo transferir dinheiro de uma conta bancária para outra. Uma única operação pode envolver inúmeros acréscimos, supressões e modificações de dados. Ou todos estes completo com êxito ou nenhuma delas é realizada.

Transição

(Transição de Serviço) Uma mudança no estado, o que corresponde a um movimento de um serviço de TI ou Item de Configuração de um outro estado de Ciclo de Vida para a próxima.

Análise de tendências

(Melhoria de Serviço Continuada) Análise de dados para identificar padrões relacionados com o tempo. Análise de tendências é usado em Gerenciamento de Problema para identificar falhas comuns ou itens de configuração frágeis, e em Gerenciamento da Capacidade como uma ferramenta de modelagem para prever o comportamento futuro. Ele também é usado como uma ferramenta de gestão para identificação de deficiências nos processos de Gerenciamento de Serviços.

Afinação

A Atividade responsável por planejar mudanças para tornar o uso mais eficiente dos recursos. Tuning é parte de Gestão de Desempenho, que também inclui o monitoramento de desempenho e implementação das mudanças necessárias.

Subjacente Contrato

(Desenho de Serviço) um contrato entre um fornecedor de serviços de TI e um terceiro. O terceiro fornecer bens ou serviços que am a entrega de um serviço a um cliente. O Contrato Subjacente define metas e responsabilidades que são necessárias para cumprir as metas de serviço acordado em um nível SLA.

Urgência

(Transição de Serviço) (Desenho de Serviço) Uma medida de quanto tempo será até que um incidente, problema ou mudança tem um impacto significativo sobre o negócio. Por exemplo, um incidente de alto impacto podem ter Urgência baixo, se o impacto não afetará o negócio até o final do exercício financeiro. Impacto e Urgência são usados para atribuir prioridade.

Usabilidade

(Desenho de Serviço) A facilidade com que um aplicativo, produto, ou

ITIL V3 - Service Design - Página:

475 de 477

serviço de TI pode ser utilizada. Requisitos de Usabilidade são freqüentemente incluídos em uma declaração de requisitos. Caso de Uso

(Desenho de Serviço) Uma técnica usada para definir funcionalidade e objectivos, e para projetar testes. Casos de Uso definir cenários realistas que descrevem as interações entre usuários e um serviço de TI ou outro sistema.

Usuário

Uma pessoa que usa o serviço de TI em uma base dia-a-dia. Usuários são distintos de clientes, como alguns clientes não usar o serviço diretamente.

Utilidade

(Estratégia de Serviço) Funcionalidade oferecida por um produto ou serviço para atender a uma necessidade específica. Utilidade é muitas vezes resumido como "o que ele faz".

Validação

(Transição de Serviço) Uma Atividade que garante um novo ou alterado Serviço de TI, Processo, Plano, ou Deliverable outro atende às necessidades do negócio. A validação garante que Requisitos de Negócio são atendidas mesmo que estes podem ter mudado desde que o projeto original. Ver também Verificação, Aceitação.

Cadeia de Valor

(Estratégia de Serviço) Uma sequência de processos que cria um produto ou serviço que é de valor para um cliente. Cada o da sequência baseia-se nas etapas anteriores e contribui para o produto final, ou de serviço. Ver também Rede de Valor.

Value for Money

Uma medida informal de rentabilidade. Custo-benefício é muitas vezes baseada em uma comparação com o custo de alternativas. Veja também Análise de Custo-Benefício.

Rede de Valor

(Estratégia de Serviço) Um conjunto complexo de relações entre dois ou mais grupos ou organizações. Valor é gerado por meio do intercâmbio de conhecimentos, informações, produtos ou serviços. Ver também Cadeia de Valor, Parceria.

Variação

A diferença entre o valor previsto e o valor real medido. Comumente usado em Gestão Financeira, Gestão de Capacidade e Gerenciamento de Nível de Serviço, mas pode ser aplicável em qualquer área onde os planos estão no lugar.

Verificação

(Transição de Serviço) Uma Atividade que garante um novo ou alterado Serviço de TI, Processo, Plano, ou qualquer outra prestação é completa, precisa, confiável e corresponde ao seu projeto especificação. Ver também Validação, Aceitação.

Versão

(Transição de Serviço) Uma versão é utilizado para identificar uma linha de base específica de um item de configuração. Versões tipicamente usam uma convenção de nomeação que permite a seqüência ou data de cada linha de base a ser identificado. Por exemplo folha de pagamento 3 Versão aplicativo contém funcionalidade atualizada a partir da versão 2.

Visão

Uma descrição do que a Organização pretende tornar-se no futuro. Uma visão é criado pela alta istração e é usado para ajudar Cultura influência e Planejamento Estratégico.

ITIL V3 - Service Design - Página:

476 de 477

Função de Negócios Vital

(Desenho de Serviço) uma função de um processo de negócio que é fundamental para o sucesso do negócio. Funções vitais para os negócios são uma consideração importante de Gestão de Continuidade de Negócios, Gerenciamento da Continuidade de Serviço e Gerenciamento de Disponibilidade.

Vulnerabilidade

Uma fraqueza que pode ser explorada por uma ameaça. Por exemplo, uma porta de firewall aberto, uma senha que nunca é alterado, ou um tapete inflamável. A falta de controle também é considerado uma vulnerabilidade.

Espera quente

Veja Recuperação Intermediário.

Garantia

(Estratégia de Serviço) Uma promessa ou garantia de que um produto ou serviço irá satisfazer os seus requisitos acordados. Ver também Garantia de serviço.

Instrução de Trabalho

Um documento contendo instruções detalhadas que especificam exatamente o que os os a seguir para realizar uma atividade. A Instrução de Trabalho contém muito mais detalhes do que um Procedimento e é criada apenas se instruções muito detalhadas são necessárias.

Solução

(Operação de Serviço) Reduzir ou eliminar o impacto de um incidente ou problema para o qual uma resolução completa ainda não está disponível. Por exemplo, reiniciando um item de configuração falhou. Soluções alternativas para problemas são documentadas em registros de erro conhecidas. Soluções alternativas para a incidentes que não têm registros de problemas associados estão documentadas no registro de incidentes.

Workload

Os recursos necessários para entregar uma parte identificável de um Serviço de TI. Cargas de trabalho podem ser classificados por usuários, grupos de usuários, ou funções no âmbito do Serviço de TI. Isto é usado para auxiliar na análise e gestão do desempenho, capacidade e utilização de itens de configuração e serviços de TI. A carga de trabalho termo é usado às vezes como sinônimo de throughput.

ITIL V3 - Service Design - Página:

477 de 477